Software development outsourcing has been around for many years. Still, it is worth starting with the basics—service models. There are different models you can use to outsource the development, testing, or maintenance of a software product, but they are all based on the three primary approaches: staff augmentation, dedicated teams, and project-based outsourcing. These models are like the rock-paper-scissors (or healer-DPS-tank of the MMO world, if we consider more modern on-line games) of outsourcing: There is no “best” model. Depending on your needs, one beats the other, and we need them all to reach a balance in outsourcing software development tasks.
Model 1. Staff Augmentation
Staff augmentation is the simplest form of software development outsourcing. It involves transferring the task of building the software development team and providing the place for it to work to the outsourcing provider. At the same time, all other aspects (e.g., defining and controlling the work process, managing the projects the team works on) remain on the client’s side. Even people management is mostly the client’s responsibility. The provider makes sure that the people are in place, correctly use their vacations and PTO, are paid, and report the time they spend working for the client. Hiring and firing decisions, motivation, team building, distributing responsibilities and tasks among team members, and promotion inside the team—that’s all the client’s headache.
Model 2. Dedicated Team
In a dedicated team model, in addition to building the team, the provider also takes care of people management, low-level task management, and process quality. What you get is not a pack of engineers working on low-level tasks, but a team working on a pipeline of projects or providing a certain complete service. The hiring/firing decisions are passed from the client to the provider. The provider works out the best process to be used by the team and then ensures it is followed. The micro-management and project monitoring functions also move to the provider side. The provider becomes aware of the projects that the team works on. There are team leaders, project management assistants, and team managers who make sure that if one team member falls behind schedule or gets sick, the task assignments are re-arranged so that the project is back on track. They manage requirements, control project status, report it to the client, and make suggestions on project management.
Still, the project/product management decisions are typically made by the client. The level of those decisions may vary: Some clients control all projects individually; some manage the products and let the outsourced team run their own internal projects. In certain cases, a software product is passed entirely for maintenance to the provider. In that case, a great deal of project and product decisions may also be passed to the provider, but the client usually wants to keep control over the product roadmap at least at a high level.
Model 3. Project-Based
The third model, project-based outsourcing, is better understood than the dedicated team approach. Instead of a team providing a service or working on projects, you mostly care about the result, not the means that stand behind it. The model assumes that there is a pre-defined goal that the provider must reach within a defined timeframe. The goal is typically a more or less well-defined set of requirements that the developed software must meet. However, with the rise of agile methodologies, the line between dedicated teams and projects became blurred. If you put together a fixed-size team for a fixed period of time with a task of developing the best possible software product in that timeframe based on a backlog that will be significantly altered in the course of the project—is that a dedicated team or a project?
An agile team is typically paid for using a per-person/team per-month approach, but that doesn’t automatically make it an example of the dedicated team model. Note that I deliberately didn’t talk about the payment terms and models when describing the various service models. The payment and service models are independent. The same simple per-engineer per-hour/month rate-based approach is most often used both for staff augmentation and dedicated team options, and it is also a frequent choice for projects. At the same time, for example, a product maintenance dedicated team may work using a fixed-price, time-and-materials, profit-sharing, or service-level-based approach. Describing possible payment models deserves a separate post. But here, I just intended to highlight the fact that it is often not possible to decide what service model is used knowing only the business model. The set of provided services doesn’t directly correlate with the way it is billed (especially given the tendency of purchasing departments to choose from the very basic options—fixed-price vs. time-and-materials—only). Just mention the risk-reward for the project, and they run away scared (or rather disqualify your bid for the project).
Going Deeper: Comparison Of The Outsourcing Models
I’d like to start comparing the models with one exception to the rule of separating payment terms from the service model. It is actually the simple observation that there’s no free lunch in our universe. Whenever you push some responsibility to the provider’s side, you push all the risks associated with that as well. And nobody is ready to cover the risks for free. The biggest risks in software development typically lie in the area of project underestimation due to incomplete or inaccurate requirements. That means the more you make the provider responsible for the product or for the project results—and that responsibility increases from staff augmentation (zero) to dedicated team (partial) to project (complete)—the more you pay for the same task done in the same timeframe. They could all use time-and-material with a flat monthly rate per engineer, but that rate will increase from staff augmentation through dedicated team to project. That’s important to keep in mind whenever you are dealing with software outsourcing contracts.
Other pros and cons of different service models are natural extensions of their definitions. With staff augmentation, you get the best control over the engineers that work for you on the provider’s side. If you wish, you may freeze the project they are working on and move them all to the top-priority task that was suddenly dumped on you by top management today. You may choose who you want to make a team leader, or if you want to have those leaders on the provider side at all, or manually manage each engineer from your side. You may decide whom to hire and build an ultimate guru squad from the most experienced engineers the provider was able to find. You may define what procedures they should use for change tracking or if they should care about that at all (don’t try neglecting change management in real life). But with those nice rights comes the price—if some engineer doesn’t like your style, it’s up to you to motivate him or her. If your ultra-seniors are bored of doing the stuff that every engineer with less than a year of experience could do, that’s your problem. If the project fails, it’s your problem. The provider doesn’t even know what the project was about or what the deadlines were.
The dedicated team model moves a big part of this burden off your shoulders. Team cohesion, healthy rotation and attrition, juggling team members’ interests to build a true team—that’s now the provider’s responsibility. This is in addition to ensuring proper requirements management, defect tracking, change control, continuous integration, risk management, status monitoring, and other sanitary processes that prevent the software development project from becoming a mess with time. And if the project fails, it’s your joint responsibility. You can’t make it entirely a provider’s responsibility, since you are making the ultimate project and product decisions. But the higher this decision level is, the more responsibility lies on the provider’s shoulders. And you can make it a part of business terms, if you wish. But, of course, there are gotchas: While you can and will influence people and process decisions, the last word belongs to the provider. Also, while the transparency of the team operation is still high, you learn some news only post-factum—such as that a particular engineer was moved from task A to task B by the provider-side manager decision or that the team decided to implement feature A first, leaving the same-priority feature B for the next month. Besides, you can no longer insist on an all-seniors team. Since the provider is now responsible for building a successful team and reaching the intended result, it will talk you to death but insist on building a more sensible and healthy balanced team structure, with seniors, standards, juniors, etc.
With the project approach, you offload your responsibilities further. Now, the provider is fully responsible for reaching the intended result. But the price for that is also significant: You lose control over the team internals and transparency and the flexibility of its operation. You can no longer question the hiring decisions inside the team (and, in the case of a fixed-price project, you would sooner not even know the entire team and its structure than be aware of such details). And you cannot just move it to the new project, or significantly change the requirements for the ongoing project, unless you are willing to significantly increase the budget as well. That also means that the project requirements must be significantly well defined and fixed at the beginning of the project, or else you’ll face the need to change the course and introduce new requirements, all at your expense.
In A Nutshell: How To Choose The Right Outsourcing Model
All that means that rule #1 of outsourcing (and, I believe, of any activity as well) is “First, understand what your actual needs are. Then choose the right approach and implement it.” By needs here, I don’t mean the details of project/product requirements, but meta-project (which is actually what service is—it all makes sense) requirements: how flexible you need to be, what risks you are ready to pay for to be moved to the provider’s side, what you want to control yourself, and what you’ll be happy to make the provider responsible for.
In software development outsourcing, that means that one of the first questions you ask yourself should be, Do I choose rock, paper, or scissors (i.e., the staff augmentation, dedicated team, or standalone project approach for my task)? In short:
- If you want fine-grained control and all you are looking to do is to get talent quicker and cheaper somewhere offshore, go with staff augmentation.
- If you don’t want to micromanage and have a long roadmap to develop, or you know that your requirements will frequently change, or you need a continuous service like maintenance without the headache of managing the employees and other implementation details, go with the dedicated team.
- If you have well-defined project requirements, expect a short development time, or don’t want to be responsible for the project underestimation risks, pick the project model.
Just keep in mind that this list is obviously an oversimplification. In your case, other considerations may play a significant role in choosing the right service model.
