Build Versus Buy: Making the Right Decision

Tough Decisions

Many project teams have faced the time when they need to make a major decision. Should one try to custom build a solution or buy an off-the-shelf product and customise it? These solutions can run the gamut of being a full enterprise class package that does nearly everything but feed the dog to small programs or libraries that do something very specialised such as drawing graphs or providing encryption functions. Frequently, a wrong decision can result in cost overruns, project delays, or a solution that does not fit business needs very well.

In my experience, I have seen two extremes of behaviour among teams charged with making the "build vs. buy" decision. One believes that they can build everything needed and that no off-the-shelf solution will fit their needs. The other side of the coin is a belief that an off-the-shelf package will be much cheaper and will be able to fit one's needs. Unfortunately, both paths frequently can lead to disappointments if not carefully considered. At times, going the package route may make sense while at other times, a custom-built solution will be better and more often a hybrid solution that uses both will be the best solution.

Making the Decision

A first step to making the decision is to get an idea of what needs you are trying to satisfy. This involves meeting with customers or business units to find out their specific needs and goals. Try to avoid going to a very detailed requirement level unless they are very crucial and can make or break a project. However, the more information you get, the better. Break them up into long term, medium term, and immediate needs. Also, classify them by priority high, medium, and low. Make sure that stakeholders agree with this assessment.

Now that you have some idea of what needs you must satisfy, you can proceed to the next step. Estimate how much time, effort, and money this will involve, based on different options. A previous article of mine, "Useful Estimation Techniques For Software Projects,"  (Developer.com, August 2002) has some useful hints on cost estimation. Options typically fall within the range of complete packaged solutions to fully custom-built solutions with hybrid solutions in the middle.

Note: An option to consider when looking at custom or hybrid solutions is to work with an external consultant that may already have many parts of the solution you need. Many consulting companies have previously built frameworks that can be used to build a solution at less cost than starting from scratch.

At the end of this process, we may realise that we have found several different options. Based on the costs and risks associated with them, we can rank the different options based on a combination of the priorities of the different needs that have been identified earlier on, the costs involved and the risks associated with each option. Run these by your stakeholders and project team. This is a good way to communicate what you are trying to achieve and the upside and downside of each option. Try to get an agreement on the best option with an alternate option if things do not go as expected. Once a consensus has been reached, you can proceed with working on the chosen option. However, do not be unduly surprised if things change as you move along. This is a typical risk with any software project. A good way to handle this is to use an iterative development style. More about this and other useful techniques are mentioned in a prior article of mine, "Better Management for Software Projects"  (Developer.com, August 2002). If things do not work as expected, the iterative style will help you change a particular decision before too much time & resources are spent. Realising that a particular path is unsuitable before too much time and money has been spent still has value.

Conclusion

Making build vs. buy decisions frequently can be a challenge. Often, we do not have enough information and things can change during the decision-making process. However, it must be remembered that the aim should be to make a "good decision," not necessarily the "best decision." The business is a driver for making this decision and taking too much or too little time to make a decision can have bad long-term effects for the business. This also means that one should be willing to change a decision in terms of new information and changes in the environment.

Sanjay Murthi is President of SMGlobal Inc.  He has over fourteen years of experience in the software industry in a variety of roles and responsibilities. He now helps companies to review and improve their software definition, development and delivery process. He can be contacted at smurthi@smglobal.com.