Our Sites

Build it or buy it?

How to perform a cost-benefit analysis for IT projects

One of the biggest decisions any modern fabricating business will make is implementing and maintaining its information technology (IT) infrastructure. Whether installing a new payroll system or creating a whole new parts inventory database system, it is imperative for a company to study a system before installing it to make sure it will be able to meet its present and future needs.

Of course, computer systems and software seem to go out of date as soon as they hit the store shelves. This brings up the inevitable question of whether it makes more sense to design and build a custom system or buy a packaged solution.

When building or buying a new IT system, you need to take a look at a number of obvious things. For a custom system design, you have to deal with hard costs such as development, testing, and implementation. For packages, you have the initial package cost; ongoing licensing costs; costs to customize; and possibly costs to configure and modify the package and then test it.

It's a difficult decision, but you can use some techniques to help make the picture clearer.

Preliminary Steps

First, complete an "envisioning phase," during which company managers decide what the system requirements will be, based on its ultimate use. These requirements will dictate the points to look at during the build-versus-buy analysis.

The next step is to research the types of products on the market that may be able to do the job. Once you have compiled a group of possible candidates, you need to analyze their strengths and weaknesses versus your requirements and how they compare to the design and implementation of a custom-built system.

Decision Analysis Spreadsheet

The easiest way to compare strengths and weaknesses is to develop a decision analysis spreadsheet (see Figure 1). This simple system lets you weigh scores to make your most important requirements apparent.

Scoring Legend:
1.0 = Alternative fully satisfies business requirement or decision criterion.
0.5 = Alternative partially satisfies business requirement or decision criterion.
0.0 = Unknown or Null/Balanced (the alternative neither satisfies nor dissatisfies business requirement or decision criterion).
-0.5 = Alternative partially dissatisfies business requirement or decision criterion.
-1.0 = Alternative fully dissatisfies business requirement or decision criterion.
Figure 1
The easiest way to compare strengths and weaknesses of an IT system is to develop a decision analysis spreadsheet. This simple system lets you weigh scores to make your most important requirements apparent.


First, line up the candidates horizontally across the spreadsheet. Then vertically list the requirements, such as low cost, personalization, and time factor. Give each of these requirements a percentage score with the total equal to 100 percent.

Then give each candidate a number to show how well you think it achieves each requirement on a scale ranging from +1, meaning it fully satisfies the business requirement or decision criterion, to -1, meaning it doesn't meet the requirement or criterion.

Then multiply the requirement's weighted percentage by the individual score and add up the numbers to get a score for each option. The candidate with the highest number is, theoretically, the best choice.

However, you can easily sway the formulas by changing the weights. This means that, even though you may be trying to be unbiased, it's easy to skew the formula inadvertently so that the candidate you liked best before the analysis is the one that gets the highest score. You have to be diligent to make sure that you approach the process impartially to get the best IT system for the company's needs.

Facing Intangibles

However, the build-buy cost analysis isn't finished once you've completed the decision analysis spreadsheet. The chart is just the first step in choosing the right solution.

Most of the decisions also depend on intangibles that are hard to quantify. You can identify some costs up-front, but others—the ones you need to worry about for the long term—are hidden.

Following are some of the intangibles that companies should consider during the build-buy decision process.

Can People Work on It? If your system needs repair or modification, it's easier to find a developer to support generic languages such as Microsoft Visual Basic or Oracle than specialty programming languages.

Additionally, it's helpful if you own the source code so developers can work on the system. With a custom system, you can own the code if your contract is written correctly. With a packaged system, you have to pay licensing fees and might not get access to key parts of the code.

Are You Going to Change? Three years from now your business environment might change, creating new software or system needs. To prepare for this, you can configure your system to be easily expandable to include new part numbers. This way, you won't have to buy a whole new system or custom develop yours.

What Is the Scope? With a custom system, developers usually can design in the features you need. This can be both good and bad news. If the project is well-managed, the development and final product can work. But if you let everyone weigh in with an opinion, the result could become a huge mess. Just like too many cooks can spoil the broth, too many end users can spoil the code.

Is It Overkill? Many packaged software systems have a lot of bells and whistles, and you may be getting more from the package than you really need. If you're using only a quarter of the features in a software package, chances are you paid for more capability than you need.

Remember the End User. Many older computer systems have a DOS look to them, while newer Windows®-based systems are mouse-driven. While the functionality may be there with a newer system, sometimes people have a hard time adjusting to change. Choosing a program that is a major deviation from the old system could turn off employees, and the usability factor might be low.

Time Isn't on Your Side. Time can be one of the biggest intangibles. Many companies fail to realize how long it takes to implement a new system.

Your company might say it needs X number of features in six months. If this is the case, time is the most critical factor in the build-buy analysis. If you're building a system, you will get incremental features along the way. But if you're buying a package, the features can come online very quickly. With buying, you'll have a steep functionality slope, but then you have to factor in the time it takes to learn those functions.

Don't Overanalyze

As if there weren't enough factors to investigate when deciding what system to choose, you need to make sure you don't let the process of investigating those factors result in project failure. While there may be dozens of factors to investigate, companies run the risk of "paralysis by analysis." You need to keep the big picture in mind and not get stymied by the microlevel review.

Fabricators are in the business of making money, and the least expensive solution to the problem always has the upper hand. But doing a build-buy analysis helps companies discover that spending a bit more on a system may save money in the long run. You really have to evaluate the functions of the proposed systems, and a build-buy analysis is an effective way to do that.

Christian Litke is an engagement manager and Michael Pelletier an emerging technology specialist with Pinnacle Decision Systems, 100 Roscommon Drive, Suite 310, Middletown, CT 06457, phone 860-632-7766, fax 860-632-8811, e-mail info@pinndec.com, Web site www.pinndec.com. Pinnacle Decision Systems is a computer consulting and software development company with additional offices in Boston and New York City.