Pitfalls Arising When Outsourcing Code: Underspecification

The success of a project largely depends on the communication and commitment from the client. Many projects have exceeded budget or have been delivered late when the project requirements were underspecified. If you don't know clearly what you want, don't hire an outside group to develop the wrong system for you. This is the first rule. However, we see here another problem - how to carry these specifications to the development team. Having a 100-pages plus specification document is a must but it is not enough. Exert as much effort as possible to help the offshore team understand your requirements. (See also our previous "Pitfalls Arising When Outsourcing Code: Communications" article in this series) Below we offer you a list of simple rules and tips which, we hope, will be of assistance both when developing specifications and when giving it to the offshore team.

Tips that may help

• Design your application to the last detail. As has been said, good specs are a must. Outline everything you want done and how you'd like it done. Don't leave things to guesswork or to some outside programming manager
  
  
• Let the development company help you with the specs. If they know the business, hammering out specs should be part of the project. In addition, they will better understand what you want because the specs will be written in the language everybody understands.
  
  
• Start with a pilot project or a small part of the project. Do the architecture and initial builds with a small pioneering team. This way, when you scale up the development team, the new people are starting with something that works.
  
  
• Develop a prototype. If you are worried that the outside group won't understand what you want, developing a prototype in-house and giving this to the outside team can be very helpful. Be wary though. Prototypes sometimes are used as a foundation for production code. This can be bad as prototypes are often developed in a loose manner. Provide a prototype for improved requirements definition, but also insist on a fresh write of the system in order to have a clean foundation.
  
  
• Offer your sample code. If you plan to use some rather complicated technologies, or you have some specific coding standards, you should share samples with the team. This will help make the source for the project understandable by your group.
  
  
• Provide your own experts in the domain if needed, especially when developing end-user application. However, make sure that the team understands this and is not insulted by this fact. This is also helpful for overcoming cultural differences (e.g. when developing GUI the offshore developer can hardly understand or know the standards in your country).
  
  
• Require code reviews and try to conduct them jointly in order to understand that something has gone wrong way at the earliest stage.
  
  
• Send people over there to keep tabs on progress, and answer technical questions and clarify specifications.
  
  
• Be flexible when it doesn't matter. If you don't specify whether to use tables or frames in web pages, don't get upset because they guessed wrong. The developers can not read your mind.
  
  
• Set the RIGHT priorities. Let them know when things REALLY matter. If you have a presentation coming up for Venture Capitalists, don't wait until the day before to mention it, even if that's already a deadline day. Most deadlines are actually a bit flexible, but those that are brick walls need to be flagged early.
  
  
• And last but not least - stop moving the target! Keep changes or additions few and far between. If this has happened, keep in synch with the outside team, make changes as well documented as everything else and get those revisions to the outside people ASAP.

What is often forgotten

• Demand scalability, flexibility and openness of the code and design architecture.
  
  
• Include performance requirements in the project requirements document. Develop test cases if you can and exact and simple quantitative performance measures.
  
  
• Requirements analysis and integration testing should be done onsite. The contractors should be responsible for coding, unit testing, and detail design documentation.
  
  
• Demand detailed documentation so if you ever need to work on the code in-house you won't be left in the dark as to how things are working or how things were done.

Conclusion

And remember that any specification even if excellently written contains vagaries and some ambiguity that will result in increased time and budget. However, the more exact your specifications are, the less the overhead.