The question of whether to outsource software development is reflexive from Business Management whenever a new project is considered. It is the classic business question of "make or buy". At many companies with existing development resources, the typical objections raised deal with quality and maintainability. At companies without development resources, there is concern about the lack expertise to properly specify and manage the project. These are valid and real concerns. The potential pitfalls of outsourcing are significant and real. They are also solvable.
The goal of this article is not to imply that outsourcing software projects is always the best choice. The author's industry experience would be contrary to that assertion. The goal of this article is to show that it can be a great choice, provided significant provisions and constraints are met. Cybron's business model is about providing those provisions and constraints. This article is written under the assumption that such provisions and constraints are met.
Most of the benefits of outsourcing are derived from an enforceable contract with corresponding pay schedules and deliverables. The leverage this provides is very significant. Another source of benefit is gained by the outsourcer being a separate legal business entity. The benefits listed should apply to a typical outsourcer.
Software outsourcers have readily available resources. The time and effort required to build up an Internal Development Group is substantial. This cost of recruiting and training can be deferred to the outsourcer. This is especially significant if the project requires specialize expertise.
Software outsourcers are subject to enforceable legal agreements. Costs, schedules, and penalties can be readily enforced and understood. Similar penalties are not applicable to Internal Development Groups. The result is that outsourcers are very motivated to meet the terms of an agreement. The ability of Outsourcers to more readily mobilize resources allows them to avoid schedule overruns.
Software outsourcers can readily accept additional features and increased project scope. Internal Software Groups have difficulty absorbing additional features. Additional features equates to additional personnel, which when feasible, costs the team in terms of recruiting and interviewing. Outsourcers can mobilize additional resources more readily. Additional features and scope equate to increased revenue for the Outsourcer. Whereas for Internal Software Groups, additional features equate to an increased workload.
When outsourcing a Software Project, Clients do not need to hire and maintain new employees and organizations. An influx of new employees can be quite disruptive for the entire business organization. New employees need offices, machines, software licenses, training, reviews, and benefits. Once the project is over, these employees will be looking for continued employment.
The Outsourcer must provide the deliverables as prescribed in the contract. Internal Development Groups are paid regardless of the state of the deliverables. There is lack of leverage to drive less significant deliverables to be complete and accurate. Design and Support documentation are the most likely to suffer. The Outsourcer is motivated to provide the deliverables that can be quickly verified as complete.
Internal Development Groups still get paid regardless of the timeliness and state of their deliverables. The typical worst case scenario for an Internal Development Group is that the project is cancelled, and they will need to find other positions. The worst case scenario for an Outsourcer is that they lose the contract and don't get paid. Cash flow concerns are paramount for Outsourcers given their typical business model. Outsourcers are very motivated to please the Client.
Software development is a risky proposition. The worst case scenario is a failed project. For an internal development, the company is out the costs of recruiting, hiring, training, equipping and providing benefits for the Development Group members. Laying off employees will mean increased Unemployment Insurance and some continued benefits coverage. For an outsourced project, the contract is cancelled.
Outsourcers bidding on a project will provide additional review and cost containment solutions. In order to rigorously bid a project, the completeness of the Project Specifications is crucial. As Outsourcers estimate costs, they will uncover additional issues that need resolution prior to producing a final bid. Reductions of unresolved issues greatly increase the probability that the project will be successful. It increases costing confidence.
Generally, during the Planning Phase of a project, the Development and Testing teams while somewhat busy, are basically unproductive. These two teams can comprise 70% of a Product Group's ongoing expenses. The Planning Phase is often rushed in order to minimize this inefficiency. Yet Planning is crucial to a Software Project's success. Efforts to keep Development and Testing busy during the Planning Phase can be counter-productive. Proper planning takes time. Customer feedback, market reaction, usage profiles, "what-if" scenarios, and competitor's reactions need analysis. The impetus to keep the Development and Testing Teams busy may push the Development Group to create features and updates which only serve to frustrate the Customer in terms of upgrade and training costs.
By utilizing Outsourcing, the Product Group can be reduced significantly. The Development Team can be reduced to a size necessary to technically advise Program Management in terms of cost and feasibility, and handle maintenance issues. The Testing Team can be reduced somewhat, and may be better utilized assisting with Product Support and Maintenance issues. Decreasing the expense of and increasing the productive use of the Development Group during Planning provides an environment conducive to effective planning.
It is interesting to note, that while Development Groups try to conform to an ideal scenario, it is usually necessary extensions of the Planning Phase which contribute to the inefficiencies of the typical scenario.
When the idea of outsourcing is raised, there will be reflexive objections made. The typical objections are:
A real problem with these objections is that they are essentially valid. However, their basis may not be entirely the responsibility of the outsourcers. It is important to note the potential bias of those raising the objections. While the general substance of the objection may be sound, the advocacy of its frequency or consequence should be suspect.
In order to advance the case for outsourcing, these objections must be assumed as resolvable. I will concede, that the failure to adequately resolve these objections is a reasonable consideration not to outsource. Cybron's business model is focused on resolving these objections.
Managing an outsourced software project presents more potential down-side than up-side potential for the employees involved. My industry experience is that those who have managed an outsourced project, swear them off completely. Even when it is an unmitigated success for the organization, it does little to advance the career of the people managing it.
The successful conclusion of an outsourced project is counter to the interests of a Development Team. The reflexive question from Business Management will be whether more work could have been outsourced. It certainly promotes the idea for the next product cycle and for other projects. Basically, a successful outsourcing undermines the demand for internal Development Teams, and they can be expected to respond accordingly.
An outsourced project requires fewer Program Managers. It reduces their ability to tweak their feature designs during Implementation. It requires them to produce more robust Feature Specifications which will receive greater scrutiny. The Outsourcer will likely require complete and detailed Feature Specifications in order to provide a firm bid. Tasks typically done by Program Managers will be handled by the Outsourcer. This reduces the demand for Program Managers, potentially reducing team size and influence.
Successful outsourcing is in the Program Managers interest as long as it can be qualified that an internal Development Team could have done better. So, while failure is not in the interest of Program Management, neither is complete success.
Testing is often less affected by outsourcing. While there will be less work for them to do, they are typically overburdened anyway. Their roles can remain largely intact. They are still needed to validate and verify the deliverables. They will still be needed to create Test Plans and review Feature Specifications. They may gain leverage to enforce that the deliverables meet the required specifications. They should benefit from the increased specificity and rigor of an enforceable process.
Finally, outsourcing of any kind is generally regarded as counter to the interests of employees. This is generally true in a somewhat localized scope. Promoting outsourcing may create resentment within an organization. It should certainly be approached carefully. However, Outsourcing is generally in the interests of the Client's business. It can provide cost containment, less overhead, and greater leverage.
Certainly, not all software projects are equally suitable for outsourcing. Proprietary and highly technical components are unlikely candidates. Projects tightly coupled to internal systems are also not good candidates. While outsourcing is often considered to augment projects under development by Internal Development Groups, it can be quite problematic. Often a better solution is to hire on-site temporary contractors.
The primarily attributes of ideal software project for outsourcing are:
Generally, Outsourcing should be applicable to most Software Projects. The inability of a Project to be outsourced may be indicative of a deficient design or architecture. A well designed Software Project should at least be composed of some easily outsourced components.
A significant basis for outsourcing Software Projects is cost and schedule containment, as compared to Internal Development Groups. If Internal Development Groups experienced no lapse between projects, and executed projects on an ideal schedule, the relative utilization inefficiencies are probably not significant enough to warrant displacement with outsourcing. However, the reality is that features are cut and/or schedules are slipped, creating significant inefficiency.
While there are various development models in industry, I use a generalized model derived from my industry experience. In this model, there are three teams. They are Testing, Development, and Program Management. A project is broken up in to many phases, which may be repeated, but follow the same sequence. In order of occurrance, they are Requirements Gathering, Feature Planning, Feature Specifying, Implementation Design, Implementation, and Testing.
Rarely are the utilization efficiencies of the various teams equal during a phase. While they may all be quite busy, the actual value of what they are producing varies. 'Relative Portion' relates to the time of the phase relative to the project. 'Relative Cost' relates to the individual teams cost as a portion of the whole. It does not reflect the team size, but the cost of the team relative to the other teams. My industry experience is that the 'Relative Cost' of a team remains constant throughout the project. That is, team size remains constant.
The following table represents my view of an ideal project scenario for a medium sized Internal Development Group given this model and its constraints.
| Ideal Internal Project Scenario | ||||
|
|
Relative Portion |
Program Management |
Development |
Test |
|
Relative Cost |
|
28% |
33% |
39% |
|
Requirements Gathering |
10% |
100% |
25% |
25% |
|
Feature Planning |
10% |
100% |
50% |
25% |
|
Feature Specifying |
20% |
100% |
75% |
50% |
|
Implementation Design |
20% |
50% |
100% |
75% |
|
Implementation |
30% |
50% |
100% |
50% |
|
Testing |
10% |
25% |
75% |
100% |
Given a medium sized (three Program Managers, three Developers, five Testers) perfectly executed project over the period of one year, the overall project cost is $980,000, with a employee utilization efficiency of 66% and an approximate project cost efficiency of 66%. So, under near ideal circumstances, $326,000 was lost on basic inefficiency. Realistically, that isn't that bad. Had the teams known that the project was going to go so smoothly, they could have likely increased their utilization somewhat. The end result is $980K spent on $653K worth of value.
Now consider this same medium sized team, following a more typical development scenario, where the schedule was slipped by three months. (Note that the sum of the 'Relative Portion' totals 125% reflecting the increased duration of the project)
| Typical Internal Project Scenario | ||||
|
|
Relative Portion | Program Management | Development | Test |
| Relative Cost | 28% | 33% | 39% | |
| Requirements Gathering | 20% | 100% | 25% | 25% |
| Feature Planning | 20% | 100% | 50% | 25% |
| Feature Specification | 15% | 100% | 75% | 50% |
| Implementation Design | 10% | 50% | 100% | 75% |
| Implementation | 30% | 50% | 100% | 50% |
| Testing | 30% | 25% | 75% | 100% |
The overall cost of this project was $1,223,750 with an employee usage efficiency averaging 64% but an actual project cost efficiency of approximately 51%. The end result here is that $1,224K was spent on $653K worth of value. Most likely, the value is optimistic considering the likely degraded quality of the deliverables.
Should this project have been of a fixed length, features would be cut, degrading the value of the final deliverables. The end result would be $980K spent on approximately $500K worth of value. This would equate the same inefficiency. Usually, features are not cut until after Planning. So the Planning phase would not be proportionally scaled, which further degrades the cost-value ratio.
A key advantage of Outsourcers over Internal Development Groups is that they can more readily increase the utilization efficiencies of their employees. They generally have pools of employees to utilize instead of fixed Development Groups. A significant portion of an Outsourcers profit is tied to this increased utilization.
This same project utilizing Outsourcing would allow the associated Internal Development Group to decrease its size by two Program Managers, three Developers, and two Testers*. The project cost of the Internal Development Group is approximately $320K. Utilizing the same employee costs, the Outsourcer could reasonably bid the project at $600K. The savings to the Client would be $60K compared to the ideal scenario, and $300K compared to the typical scenario.
Additional savings are realized by reducing the costs associated with lapse time between projects. Slack time between projects may be one to three months. A medium sized Internal Development Group may easily cost upwards of $80K a month. The reduced Development Group used in the Outsourcing scenario costs about $28K a month.
[* This scenario assumes that Planning is not Outsourced, which would further reduce staffing requirements.]
Outsourcing can be a very attractive option for any business considering a Software Project. Using the right model, it can reduce cost and schedule risks, while providing greater flexibility in planning. The key is proper utilization.