Tech & Work

Consider these points when making the build vs. buy decision

The start of a project often involves an analysis of whether the solution should be built from scratch or purchased off the shelf. Here's a rundown of some of the issues you'll need to consider before you make this call.


With every new project comes the big question: Should you develop a solution from scratch or buy something off the shelf? For most projects, both camps will be represented, arguing in favor of one approach or the other. But it's important that the final decision be made after a careful evaluation of the alternatives and not as a result of naïve assumptions about either the development team's abilities or the capabilities of a packaged solution. Here's a look at some of the issues associated with the typical build vs. buy decision.

Let’s reinvent the wheel
Okay, you need to get the sales department set up with a new order-entry system. Since computers have never been used for this purpose before, it will be necessary for your team to build this from scratch, right? Of course not. However, maybe because development shops are in the habit of building things, or perhaps because building things is more fun, or possibly because they think job security is involved, the first reaction is usually: Build it.

Sometimes, good reasons exist for favoring an in-house solution. Here are some of the arguments in favor of building:
  • The business need is unique. It may be order entry, but your orders are nothing like the world has ever seen before.
  • No off-the-shelf product exists for this business function. Maybe the problem is not order entry but predicting order quantities for raw materials based on projected weather patterns for the next 30 days. This certainly would not be your mainstream application.
  • The interface is complex. By the time you integrate a packaged solution into your process control system, you could have written everything from scratch three times.

Some of these issues can be valid. It really boils down to being honest about the needs of the business and what it will take to meet that need. Obviously, if you are trying to come up with a solution for a business function that is just so specialized that no one has marketed software for it, your choice becomes simple. On the other hand, if you are thinking that no one enters orders quite like you do, maybe you need to give the situation a closer look.

Honest assessment
Here is where careful analysis comes in. Your users may truly believe that their needs are unique, but you have to step in as a professional and objectively determine what their needs really are, not just record how they do things today.

There are dangers to automatically building a system from scratch instead of selecting a packaged solution. These dangers include the following:
  • You may be paving the cow path. Sure they do things this way, and you can program the system to accommodate that. But why do they do it that way? Do they even know? (And by the way, “Because we have always done it this way” is not a valid answer.) Just because the business processes have evolved over time does not mean they have been refined over time.
  • It may be expensive to develop. No check was written, so it didn’t cost anything, right? After all, the programmer’s time is already paid for. First, if your company’s management is actually using this type of thinking, you are (or will be) in a world of hurt that package selection can’t begin to solve. Second, development can be much more expensive than you might think. Don’t let a single large package price tag scare you. The cost of your development team, the time taken from the user departments during all phases of development, and the opportunity cost of the work not done on some other project is the dollar amount that should scare you.
  • It may be expensive to maintain. Maintaining an application and keeping it running on the current platform (which may mean dealing with a succession of platforms) can be an expensive proposition.

Finding an off-the-shelf fit
One size rarely fits all, so you know that a packaged solution probably won't be perfect. But how close does it come? Does the software perform 90 percent of the required functions? Does it hit 80 percent of them? The only way you can even begin to consider this question is if you've analyzed what the actual needs are. (I know I mentioned this already, but it is worth repeating.) Then, you need to consider the cost of the package and factor in what it will cost to fill in the missing functionality.

Choosing a packaged solution can provide very real benefits, including:
  • The package can add structure to a poor business process. If the solution represents best or common practices, adopting some of those for the sake of using the new software may not be all bad.
  • The package may cost less than an in-house solution. The costs of development and maintenance are spread over many users.
  • The package may be of higher quality. Obviously, this is not a given. However, with more users banging on the system, errors may have been found and corrected before you install it.
  • You may be able to implement faster. Since the coding has already been done, you may be able to go live sooner than if you developed a solution from scratch.

A key choice
The build vs. buy decision is an important part of the development process. Either choice can be valid depending on the situation. In future articles, we'll look more closely at aspects of custom development and package evaluation.

Build vs. buy: Have you had to choose?
Have you been a part of a project where careful consideration was given to the build vs. buy decision? What are your thoughts on the process your group used? Send us an e-mail with your thoughts and experiences or post a comment below.

 

Editor's Picks