Build Versus Buy-Making the Right Decision
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 customize 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 specialized 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 behavior 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
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.
||Packaged Solution(s)||Custom-Built Solution(s)||Hybrid Solution(s)|
|What it means||A complete or nearly complete solution provided by a vendor; for example, ERP packages, CRM packages, and so on.||A solution that is custom built from scratch with few external components.||An intermediate solution that uses different packaged components from different vendors as well as custom code to integrate them into a solution.|
|Some potential benefits||Can be cheaper. Software quality can be better if it is a widely used package. May be easier to migrate to newer options in the future.||Will better fit business needs. Much more control over the solution. Can be customized for maximum business advantage.||Can provide the best of custom-built solutions and packaged solutions. More customization to business needs possible. Usually cheaper than a custom-built solution.|
|Potential risks||Vendor is financially unsound, product is immature, additional expensive customization needed to meet business needs, requires major changes in existing business processes, and so forth.||The technology platform to be used may be immature, skills with the platform are hard to find, bug fixes & enhancements can become very expensive, and so on.||Vendor is financially unsound, technology platform is immature, people with the skills needed are hard to find, integration issues, and the like.|
|Costs to consider||Ongoing licensing costs, infrastructure costs (servers, databases, networks, and so forth), support costs, training and customization required, quality assurance, and so on.||Infrastructure costs (development, testing, and operations), development costs, training if the team is using new technology, quality assurance, and so on.||Ongoing licensing, infrastructure costs (development, testing, and operations), support, development costs, and training if the team is using new technology, quality assurance, and so on.|
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 realize 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. Realizing that a particular path is unsuitable before too much time and money has been spent still has value.
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.Copyright © 2002 Sanjay Murthi
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 firstname.lastname@example.org.