The Code Whisperer

Outsourcing any part of a project to a third party is a risk, but one that can be minimised. By careful planning and management. for example having good quality technical design documents and continual communication with the third party, it’s possible to benefit from the use of a third party software, whether bespoke or readily available software.

Outsourcing allows projects to have more personnel working on it than the company has. Outsourcing is sometimes used as a way of reducing the cost of a project, although, for a variety of reasons some of which are outlined below, the lower cost of development staff doesn’t always result in a lower overall cost. Generally outsourcing is carried out away from your office, so you need to plan for more time spent communicating that you would if the development team were in your office, simply because you will probably have one point of contact and your request for information may require a return call.

Personally I think it’s vital that outsourcing isn’t used as a scapegoat for a high risk project. I have seen this happen or more than one occasion and whilst a large consultancy firm was brought in that could absorb any financial penalties, the consultancy’s staff were under immense stress to deliver the undeliverable.

Managing third party development isn’t an area I’ve had a great deal of experience of, so I’ve dug out a few tips from various books as well as my own.

• Top quality design documents are key. The documents need to be well written, detailed and correct. Peer review all documents sent out and make sure the outsourcing company understand the work required sufficiently to estimate and plan the work. One major point of failure is the outsourcing company not appreciating the complexity of the work required. This can be the fault of either party. This is of particular importance if the work is carried out away from your office as the ability to communicate face to face over small items is greatly reduced. If you are receiving the source code and planning to maintain it yourself then you must supply your coding standards and consider performing a code review on the delivered code.
• Constant communication. Make sure you are aware of real progress against your plan, not just the time taken, and have clarification that the stated progress is correct.
• Risk assessment. You will need to include the outsourcing in your risk assessment, and possibly have a backup plan
• Frequent code drops. By having points in the development where code can be delivered and tested, you will have a measurable sense of progress, or slippage. Sometimes the code drop is combined with payment to the third party an incentive for working code to be delivered on the agreed dates.

I don’t want to give the impression that outsourcing is a bad thing, it’s not, provided it’s approached sensibly and managed correctly. Having said that a number of high profile public projects, for example the NHS patient record system, have been delayed due to contractual issues with the third party developers. The same issues that cause delays and problems with an internal project seem to be magnified when a third party is involved.