7 Buy Vs. Build Considerations for it Managers

Information Technology managers lucky enough to have developers at their disposal sometimes face the decision of whether to buy a software product off-the-shelf, or to have their engineers create the needed functionality.  This classic, “buy versus build” decision can cause more consternation than one might imagine because making the wrong decision can be costly or even disastrous. 

For some products, the decision is obvious: few IT managers proposing to write their own core accounting or payroll system would be taken seriously.  On the other hand, if the needed functionality is so unique to company requirements that it can’t possibly exist as a commercial product, then building from the ground up is the only option, but there may be quite a few gray areas.  As the CEO of a software company whose flagship product is an emerging technology, I can offer a unique perspective here: IT managers often misunderstand the depth and breadth of a new technology (like new employee onboarding) and embark upon a build-our-own project that is doomed from the start. 

One of our customers had pursued a project to build their own paperless onboarding system for new employees, and when we met them, they characterized their project as 80% complete.  After just a few meetings they realized they were—at best—only 20% complete and wound up buying our onboarding product.  Valuable time and resources were lost as they pursued a development project.

How did we convince that client to switch from build to buy?  We simply took them through a more thorough analysis of the buy versus build (or is it build versus buy?) decision.  The process is simply to evaluate the following seven considerations regarding buy vs. build.

1. What is the availability of resources and how fast is the functionality needed?

Even if the only choice is to develop your own solution because a suitable product doesn’t exist, or can’t possibly exist, building a product might not be an option if resources are in short supply.  Programmers are a scarce resource, even during a slow economy (and expensive, though I’ll cover that below).  Considering the build option requires an examination of your programmers’ outstanding projects, prioritizing the new build project among the existing project backlog, and comparing the estimated delivery date with the date the functionality is required.  If there are plenty of resources available, it’s obvious that even low priority build projects might be tackled sooner.  If resources are short and the project backlog is long, only the highest priority projects will (and should) get quick attention.  If the functionality is needed (or desired because of the potential return on investment—ROI) more rapidly, then buying is the best option.

2. Is subject matter expertise needed?

A principle reason to buy an off-the-shelf application is that it encapsulates some sort of subject matter expertise, or what I like to characterize as “depth”.  For example, a payroll system is a pretty “deep” system in that it encapsulates a great deal of subject matter expertise; a timekeeping system, on the other hand, is considerably more “shallow.”  The depth of expertise explains why there are far fewer payroll systems than there are timekeeping systems; products with deep subject matter expertise are more difficult to develop so there will be fewer of them.  For your project, you must thoroughly evaluate the depth of subject matter expertise.  Projects in regulated functions and long-term strategic functions, such as human resources and corporate governance, almost always require deep subject matter expertise and are better suited with the buy option.  Projects in unregulated functions or projects that are short-term in nature—such as sales and marketing and certain aspects of operations—may prove to be shallower in their need for subject matter expertise and are likely better suited for building.

3. Is company-specific functionality important?

Some desired functionality may be so specific to your company that buying an off-the-shelf product isn’t possible.  This situation is most likely to exist in those areas of the business that aren’t regulated or that are particularly unique to your business.  For example, finance, human resources, and corporate governance are all regulated functions (GAAP, SOX, tax and HR law, etc.), but processes that are truly unique—like operations derived from company patents and intellectual property—are only going to be implemented through building a solution.  Similar to topic number 2 regarding depth of subject matter expertise, this is more like “sequestered” subject matter expertise: regardless of how deep or shallow the expertise is, if it doesn’t exist in the wild, you’ll have to build it.

4. Are there product lifecycle issues to consider?

Some products might be constructed, deployed, and never touched again.  This is most likely to be true if the product’s life span is expected to be short.  Other products might need constant tweaking and maintenance for indefinite periods of time; these products are likely associated with outside influences like regulation.  For example, employment law (being the government domain)is highly susceptible to change, and new regulations will appear (unfortunately, old regulations never seem to go away).  If a long or permanent product lifecycle is anticipated or if the product is associated with regulatory compliance, buying is preferable to building.  Don’t get caught in the temporary project trap, though; temporary projects have a propensity for turning into permanent deployments.

5. Which is cheaper: buying or building?

Answering this question is always challenging.  The costs of buying are pretty clear cut and relatively predictable: licenses or SaaS startup costs, implementation service costs, ongoing maintenance or usage fees.  Building projects require accurate estimation of the project length and its costs, labor and benefits (programmers are relatively expensive), general and administrative costs, as well as the costs—sometimes allocated—of the infrastructure needed to support the system.  While the trick to evaluating the cost of buy versus build comes down to figuring out the long term maintenance costs of a home-grown solution, there’s no clear cut rule of thumb.  One obvious benefit is that the costs of buying a solution should be more predictable than building: use this to your advantage if pursuing the buy option by pressing for fixed prices or not-to-exceed prices for implementation service costs, or consider taking on much of the implementation yourselves (but be aware that the provider of the product will almost certainly have have a better understanding of their own product and therefore should be more efficient at its implementation).

6. How “standards-sensitive” is the product?

If the product is sensitive to an industry or business standard, even if the standard has nothing to do with regulatory requirements or depth of subject matter expertise, then buying will be advisable over building.  For example, there are generally accepted practices and processes for project management; even if you don’t need to hire a professional project manager today, you might in the future.  An off-the-shelf product will usually better and more fully represent the standard and therefore would be preferable to building.

7. Are there unique business dynamics to consider?

There might be unusual business dynamics at play that influence the decision, such as transfer of license issues.  Some commercial software end user license agreements, or “EULAs,” may prohibit the transfer of the license, preventing the company from moving the license to an assignee, say in the event that a division is sold or the company goes through any kind of M&A activity.  Similarly, an evaluation of assets may be able to regard commercial software licenses as quantifiable assets, which may prove difficult for software products that were built.  There may also be privacy or security issues, such as dealing with healthcare data or employee benefits information, which, for liability reasons, may be better served by an off-the-shelf product; on the other hand, the company may have highly proprietary and guarded data (think Coca-Cola formula) that they would prefer not to embed in a commercial application that is maintained by an outside vendor.

The buy versus build decision is a classic technology management decision.  Armed with the ”7 Considerations of Buy Vs. Build”, start in a room with plenty of white boards and draw seven “T’s” with buy on one side and build on the other.  List the pros and cons of each and thoroughly weigh each benefit.  Make the most informed decision possible because making the wrong decision can prove to be incredibly costly.