Buy, Build, and Beyond

Posted by Robert Merrill on November 22, 2008 under Uncategorized | Be the First to Comment

Understand both approaches

There are better lists of pros and cons than I could make. But here are three things I think get overlooked or ignored.

It’s harder to get the requirements right than you think

First, “Prediction is really hard, especially about the future” (thanks, Yogi). Your competition does something, or senior management has a change in strategy. This probably won’t affect your email, it may affect your CRM and ERP, and it will almost certainly affect your ecommerce site.

Second, you don’t control all of your requirements. Regulations, new partnerships, and mergers and acquisitions can all invalidate what really was the best choice of software at the time..

Customization of purchased software is usually a bad idea

Everybody knows this, but it’s oh-so tempting. And the vendor’s margins are better on services than products anyway.

The rule of thumb I’ve heard and followed is, “If you need to modify more than 20% of a software product, it’s probably cheaper to build.” This is especially true when you consider rolling those changes forward across upgrade cycles.

The best way to succeed with commercial software is “don’t fight it.” Use it the way it comes, or with common configurations and extensions only.
And accept that “It’s harder to get the requirements right than you think.”

Either way, it’s all about the people

When it comes to the crunch—new requirement request, problem, or upgrade—you are going to need a person who knows the software, as you‘re using it. Failing that, someone needs to become that person. That will take access to information, and time. Neither is guaranteed to be available.

If the software is critical or complex, you need a vendor or channel partner with competent and trustworthy people who are allowed to talk to you. If you built, the same is true of your development organization, whether internal or external.

See past the immediate decision

The object of the game is deceptively simple. Maximize total value across all of your spending on software. That means making individual choices that solve the problem at hand, without reducing the value of your whole environment.

TCO, not just initial cost

Most people seem to have grasped this. The TCO (Total Cost of Ownership) concept is valuable because it looks beyond the initial purchase or development effort. Before a buy, consider maintenance fees and upgrade path. Before (and during) a build, focus on software quality and maintainability in addition to time-to-market and development costs

TVO, not TCO

But TCO is only one side of the value equation. There’s also a benefit side, and you need consider which is most important when it comes to a particular system. With reason, companies tend to think differently about their email than they do about their retail ecommerce site, even though they’re both “software.” Think Total Value of Ownership, not just TCO.

Know thyself

Know your own firm’s ability to execute either strategy.

Either can be executed well or badly. The choice is never between the ideal buy and the ideal build. It’s between

• the software on the market and how well it can be deployed in your environment, and
• the software your organization is actually able to build with the people you have to work with.

The “wrong” strategy, executed well, may yield better results for your company than the “right” strategy, executed badly.

If the product and vendor market is weak, that may favor a build.
If your procurement organization is good at buying durable goods, not software, or is easily dazzled by a demo and a fancy lunch, that may favor a build. (I’ve heard that software vendors typically spend over half of their budget on sales and marketing).

If your organization’s track record at building applications of this size is poor, or unknown, that favors a buy. Notice the phrase “of this size.” Big projects are different—and riskier—than smaller ones.

Over time, you will probably be doing both building and buying, so it’s worthwhile looking at how you do both, and getting better at each.

Beyond Buy versus Build

Done right, building gives you flexibility and control, now and in the future.

Done right, buying gives you cost savings and reduced time-to-value.

In the last five years, a third way has begun to emerge—customized open-source applications.

If you face uncertain requirements and have access to an effective software team, this “custom where it counts” approach can tip the scales back towards building.

eCommerce experience

From 1997-2006, I worked for a Madison-area eCommerce firm. We started out building, because the market was so new, and because we sought (and were sought by) clients that were “up to something.”

By the late 1990s, there were many eCommerce packages and services available. We used two of the larger ones and were frustrated by their complexity and limitations. Ecommerce clients want, and need, fine-grained control over their requirements, and it was frustrating to run into one of these “brick walls in the fog.”

After the crash, we returned to market with a new offer—“custom where it counts” based on either osCommerce (LAMP-based) or Open For Business (Java-based). Clients could spend their development dollars on what mattered most to them. For one, it was cutting-edge design. For another, it was a complex pricing structure. For a third, it was configurable product kits.

Open-source application availability

There are now open-source applications in categories besides eCommerce. For example:

• ERP–Open For Business (the first end-user application to be brought under the umbrella of the respected Apache Group), and Compiere
• Web Content Management: Joomla! and OpenCMS
• CRM—Sugar CRM

Compared to building, customized open source:

• Speeds time to deployment
• Reduces development effort
• Reduces risk of a completely failed project
• Offers support resources outside your own team

Compared to buying, customized open source

• Is easier to evaluate—there are no secrets
• Gives you requirements and integration flexibility, now and in the future
• Offers support resources outside of a controlled vendor-partner ecosystem

The market is moving to address some of the weaknesses in documentation and training materials for users and developers.
As with building and buying, having access to trustworthy and competent people who know the software, and know how you are using it, is key.

But developing “custom where it counts” software from an open-source application combines many of the advantages of both building and buying. The drawbacks are that your developers don’t get to code up user login screens, and there’s no sales person to take you to lunch.