Why do CMS projects fail?

A (prospect) client asked me this morning why 85% of enterprise content management implementations fail. Well, here is the long answer:

There are numerous reasons for this high rate. For one, web architectures are complex implementation projects. Requirements are often not well understood, leading to bad software purchase decisions (”putting the cart before the horse”) and architectural choices. The largest group of in-house stakeholders, the content editing community, is often ignored and set to deal with unusable user front-ends and complex publishing workflows, preventing necessary user adoption. Content is often stored in presentation-heavy formats, content re-use across channels and applications is time-consuming or even impossible, the resulting duplication of content leads to inconsistent web experiences.

The remedy for these problems on the one hand lies in the definition sound processes and establishing clear channels of communication between stakeholders. On the other hand, building a solid technology foundation is another vital aspect. Not only must this foundation be flexible, stable, and easy to use, but the defining principles must be upheld while the system is in operation and undergoing maintenance and feature release cycles. I have seen large-scale implementations that had to be replaced after only 2 years of being in operation because the software got unmaintainable, slow, and the site feature-set was locked in by technology reasons only (”maintained to hell”). On the other hand, I have built sites that serve over a billion page impressions a month, that have gone through multiple visual redesigns, all on a technology platform that has been in place for 5+ years now.

So, in summary

1. Heavily involve the business stakeholders throughout the project
2. Build the system to enable the content editors to efficiently maintain the site content and structure themselves. Any reliance on IT to maintain the content is technically a failure of the project.
3. Separate content and presentation
4. Build it to be flexible and customizable, embrace open formats
5. Establish a clear governance process for content and software release cycles
6. Establish (and document) clear architectural guidelines and patterns which need to be upheld for maintenance and enhancement after go-live

Comments