Why Getting Laid Off Is Better Than Building a Proprietary CMS?

by Barry Bealer

Aug 2001

From CMSWatch.com, August 2001

So there you are, called into the Vice President’s office. Immediately your mind is racing with “what the heck did I do?” Then your VP hits you with it – you are now in charge of a very strategic project. “Build me a content management system in 4 months or less,” says your VP, who happens to be from the “we can build anything in our IT department” mentality. At this point you wish he had laid you off.

Companies today continue to wrestle with whether to build or buy a content management system (CMS). Five years ago, the CM product market was limited, and building a proprietary solution was the only way to truly get the functionality you wanted. Today, while the 100% solution is elusive, there are products that satisfy 80% of most organizations’ needs. Such products make the decision to build a proprietary CMS that much more difficult to justify. Unfortunately, that concept could still be hard sell to your VP.

So, a piece of advice: Proceed slowly. As you begin your “career building” CMS project, consider the following:

Why Buy?

There are a number of good reasons to buy a CMS. You get to benefit from all the lessons learned by other companies whose needs have already been incorporated into the software. You get regular upgrades with new functionality and technology.

Perhaps best of all, someone else is responsible for most of the work of installing and maintaining the system. If something breaks, or if you need new functions, you call another company. This lets you and your staff focus on your real business.

Why (not to) Build?

Let’s face it: If you buy a system, your users will find at least one “essential” function that the software can’t perform. They might find several. Sometimes there are ways to add the needed functionality. Sometimes there aren’t. Either way, you’ll need to determine whether that missing functionality justifies the risk of building a system yourself. Such circumstances are rare.

Why? First, the needed functions can often be redefined in way that makes them fit more closely into the available software, or turn out not to be business-critical.

Second, the risks of building on your own are much greater than you think. Some of these risks have specific and obvious price tags (e.g. less scalability and automation). Some of them represent lost opportunity (e.g. the difficulty of quickly modifying your Web site). Some of them are hard to predict (e.g. your key developer gets another job in the middle of the project).

Let’s take a look at each of these issues in turn.

Scalability and Automation

Home-grown CMS’s vary even more widely than their product counterparts, but they typically share two common and important flaws: they lack automation, and they are not scalable.

Automation: Internally developed systems often include manual steps for tasks that could be automated. Such manual processes often result in the wrong person performing the wrong task (e.g. a programmer posting content to the Web rather than an editor) or in people being distracted from their real work by having to perform repetitive tasks over and over again. Usually, this automation isn’t missing because no one thought of it. It’s missing because developing it takes time and skill, and most organizations run out of both before finishing their systems. When you buy a system, automation for many common tasks is built in or can be easily added.
Scalability: If your “career building” project is focused on one collection of not-so-complex content and the goal is to only manage that content, then building an open application or a series of components with a small database may be an appropriate CMS solution.

A word of caution: If this type of solution is successful, don’t be surprised if management comes back to you in the future to “fit” other products into the system. What the heck, all content is the same – right? Whether you build or buy, don’t be shortsighted with regard to scalability. Understand how much content (and how many related products) will be managed over a period of three years at a minimum. Don’t underestimate the growth of content. Whatever you estimate, add on 75–100%.

The “not built here” Mentality

Some company cultures dictate, “if it wasn’t built here, it can’t be any good.” This can be extraordinarily difficult to overcome, especially when the message is reinforced from above. If you decide that buying is better than building, you need to identify the approach that will work best in your situation. Here are a few ideas:

Find a way to rally the troops and overcome their concerns
Impose change as a dictator
Marginalize the naysayers
Bring in consultants and blame the choice on them

None of these is easy (well, maybe the last one is), but it’s possible to spend a lot of effort on the first option and still not convince your staff that you’re right.

Resource Independence

How many times have you heard of a company being terrified that a key IT staff member will leave the company? (Can you say, “single point of failure?”) Well, when you build a system internally, you very often will end up dependent on the few geniuses that made it work. Sometimes these folks even work themselves into the daily workflow. (At one company I know of, no content can be published to the Web without the CIO first performing some black magic.)

Obviously, it’s possible to build your own system and remain free of this type of resource dependence. The more open the solution, the better able you are to complete system maintenance and upgrades and the less tied to a resource you are. The key is to be sure your system is built using industry standards and is well documented. To be blunt: Becoming captive to an IT resource because they have all the knowledge is just poor management.

Cost and Schedule

So you get some estimates from CMS companies. They are way higher than you expected or can afford. Plus, your schedule appears to be blown. Your lead developer comes to you and says he can build it in half the time for a quarter of the money. You are vulnerable. You want to believe him. But is it true?

The answer: Unless your requirements are extremely simplistic, it’s almost never true. And don’t even consider believing him unless he has built applications of this complexity, using the required technology, and living and dying by a tight schedule and budget.

If you buy a system, you might end up feeling like you spent more money than you wanted. But, if you build a system, you will live daily with the compromises you made and with the need to maintain the system yourself. In the end, there’s a reason these products are expensive: they are complicated and difficult to develop.

Conclusion

Is it better to build or buy a CMS? Only you and your team can answer that question. If your content is simple in structure, you fully understand and document the system requirements, you have a talented and professional technical team (or vendor), and you are going to follow industry standards to develop the solution, then building a CMS might be appropriate. Of course, you could also license a low-cost CM product that would provide the same modest feature set.

If you have a need to store and manage complex content or to publish it in unusual ways, then building a proprietary CMS is not out of the picture, but you should first recognize that CMS products have come a long way over the past few years. Why reinvent the wheel? If you decide to procure a CMS, be sure to do your due diligence to verify the specific vendor solution is appropriate for your requirements. In short, do you homework before spending six figures for a CMS.

When you look at your “career building” project, understand the build or buy options you have in front of you and don’t worry about being laid off. Look at it this way: if the project fails, you may be fired instead. Good luck!