To Build or Buy? That is the Question

by Barry Bealer

Feb 2003

Yogi Berra once said, "When you come to a fork in the road, take it." We all know you can't go down two paths at once, but choosing can be hard, especially if you're a publisher deciding whether to buy or to build a content management system. Most of the publishers who end up building a solution say to themselves more than once, "I know other publishers have done this before, why do we have to build from the ground up?" And most publishers that buy a product at some point say, "We're doing so much customization, we may as well have started from scratch - and we still won't be able to do everything we wanted to do!"

But, there's no avoiding it, you have to choose. And when you (or your boss) inevitably question the path you went down, you want to have some good answers. In our experience, many of those answers lay as much in the characteristics of your organization as in the nature of your content management needs. So, when choosing your approach, don't simply limit your thinking to a review of whether the available products meet your requirements. You also need to weigh whether you as a business are better equipped to build or buy.

For publishers, the buy or build conundrum is more crucial for content management projects than for many other system development projects. A content management system strongly influences how quickly and how well a publisher is able to react to market pressures. Picking the approach not only determines the ease which your system is developed or deployed, but could positively or negatively affect your revenue stream for years to come.

To Build or Not to Build?

So, could you be successful in building a content management system? Answer: It depends. Deciding whether you should you build a content management solution in-house is as much about how projects get done in your organization as it is about the system itself. The following are success factors of in-house content management system development.

Clearly defined project and system goals that are directly tied to your organization's broader goals
Open communication channels up and down the organizational chain
An actively involved executive level sponsor
A gifted project manager - someone comfortable with business goals, technology, and editorial and production processes, and who can balance the needs of the many groups that will be involved
Organizational experience in software development and maintenance
Well-established project and software management methodologies, and a culture that is receptive to a structured approach to projects (ideally including editorial and production staff with experience in supporting the requirements development process)
Technical depth
A commitment to making key technical, editorial, and production staff available for a significant period of time
Involvement by end users during the design of the system
Realistic expectations for the time and budget needed to develop the system
A commitment to continued budgeting and staffing of system maintenance and improvements after initial deployment

Most organizations would admit to weakness in at least some of these areas. Bottom line, if an organization has the discipline of established project management and a clear vision of how the system supports business objectives, then other areas of weakness can be overcome.

If you don't have those two factors working in your favor, then if at all possible you should buy a solution rather than build one. This is not to say that managing a vendor's implementation is easy, but it is usually easier to put pressure on an external company to perform than on internal staff with multiple responsibilities.

Finally, publishers with complex and rapidly evolving requirements often prefer a custom solution because they feel it is easier to incorporate new functionality needed for new product development. For these publishers, the certainty of knowing they have almost limitless flexibility to extend their system, which is not the case with purchased solutions, is worth the extra effort and staff required to maintain the system. They tend to view such flexibility as a competitive advantage.

To Buy or Not to Buy?

So, are you more likely to be successful if you buy a content management system? See the answer in the previous section - it depends. All of the items listed under the previous section are helpful in implementing a product as well as for building a custom solution. However, the key success factor for building a solution - experience in software development - is much less important if you buy, because today most of the product vendors (or their recommended integrators) are able to bring that discipline and knowledge to the table. In that case, having the right partner and the right in-house project management team become the key success factors.

So, the organizational characteristics that make the buy decision a good option include:

A project manager with a track record for successful vendor management
A vendor/integrator with a track record of successful projects and long-term client satisfaction
A good match between the product and your corporate environment. This includes both technical aspects (e.g., support for your preferred operating systems and databases) and cultural aspects (e.g., customer service available when you are likely to need it)
Commitment to train and potentially hire technical staff for system maintenance or to budget for ongoing enhancements by the vendor/integrator. Depending on the solution you purchase, training your staff could require significant effort
Willingness to be flexible in how or whether some of your requirements are implemented and in the workflow processes supported by the new system. (Most organizations analyze the gap between what they want and what is available "out of the box," but with content management systems, it's also appropriate to determine the gap between what is desired and what is feasible or possible given budget and technical constraints. Almost inevitably, product-based content management systems involve some type of compromise.)
It is acceptable to receive product upgrades on the schedule on which they are made available by the vendor

Organizations frequently spend a lot of effort evaluating their requirements, but spend limited time evaluating the product's vendor or integrator. This is an enormous mistake. None of the product's capabilities matter until they have been successfully deployed in your environment.

Mixing and Matching

So far, we've talked about buying and building as if there are only two clear alternatives: buy a solution and have all the work by a vendor or integrator or build a solution using internal staff. There are, of course, several variations of these options. You can buy a solution but implement internally, or have the vendor perform only a small portion of the effort (such as development for only the content loaded into the system). You can choose to build a custom system but have your team augmented by contractors/consultants, or even have an outside software development firm develop the entire system. These choices are excellent options for mitigating risks you might see in your preferred approach.

It's Déjà vu All Over Again

Finally, if you feel like your organization has been through the build or buy decision several times, you are not alone. Many projects - whether for a content management system, a financial system, a fulfillment system, or so on - fail in their first incarnation. Understanding the impact of your organization's characteristics on build or buy scenarios is an important step in avoiding repeated failures.