There is always a lot at stake, when you are starting a new project, and several questions often arise quite naturally. Is the team structure right? On the client side as well as on the vendor side? Have we clearly defined the project, what about the budget and scope?
In my experience, it’s often completely different questions that need answering, when embarking on a new project
Read moreBy Janus Boye
Nobody likes it, but too many IT projects cannot deliver on budget. Frequently additional funds need to be allocated to meet the agreed deliverables and even then, features are often slashed in the final weeks to meet the budget or deadline.
Many articles have been written on reasons why IT projects in general are often more expensive than expected. See for example:
"Average IT project still overruns its budget by about 43 percent" (Network Computing)
Nicholas Carr: Spend Less on IT (Harvard Business Review)
"It seems as if government IT projects are doomed to fail" (InformationWeek)
Common reasons? You'll recognize the litany: weak project management, bad planning, communication shortfalls, excessive focus on technology at the expense of business processes, and organizational problems.
Of course, these shortfalls also apply to CMS projects. But in this article I'll focus on the origins of CMS-specific cost overruns. I believe at the root of these overruns lies a few common myths:
"It is just a website / intranet / portal project – how hard can it be?"
"Our recent search and imaging projects went smoothly, so why shouldn't this one?"
"We know .NET, so we can easily implement any .NET-based CMS."
"The CMS has WYSIWYG editing, so our smart colleagues in the communications department don't need to be trained how to use the system."
"Our application developers understand our network and security infrastructure."
Still today many senior level executives do not think a website or intranet is something special. To them, applying a CMS is just another project. It's about getting started, getting it over with, and then moving on to another project.
Many executives have family members, often younger ones, who publish their own personal website or blog and happily talk about how easy it is to maintain. When consultants and experts then arrive and claim that it is not so easy after all, it seems strange and hard to understand.
Introducing a content management system is far from an easy process. It causes many changes throughout the organization and affects nearly every department. A new CMS typically needs to be integrated with the existing IT landscape and even with "out-of-the-box" tools, implementation times rarely come in under 6 months.
Other additional important aspects are also often underestimated. These include:
Hardware requirements. This applies especially to content delivery (i.e. consumption) environments, which are often under-equipped, especially for dynamic page generation. And of course, the machines used by your content contributors need to perform speedily for famously impatient editors. In most enterprises it's not easy to procure additional or more powerful hardware at the last minute. Moreover, more hardware typically means more software licensing as well.
Additional modules might actually be needed after the initial deal is struck. CMS vendor salespeople are just as candid or opaque as other software salespeople. They'll do what it takes to close the deal, and they may ink a contract without telling you that additional modules will be required for your project. Sometimes these modules can be both expensive to buy and complex to implement.
There are constant requirements to patch, upgrade, revise, and improve almost any content management system. Your initial deployment rarely makes people happy; expect to really hit the mark on version 2 or 3. This leads to consistent implementation costs over the lifetime of the system, which is one of the biggest hidden expenses, and potentially a major resource drain.
Varied IT support is needed. Integration with the existing IT landscape entails content and application integration, but also working within the existing network and security infrastructure. To do this well, you need diverse IT talents on your CMS team, including system and network administrators. Particularly in a major enterprise, experienced application developers alone will rarely cut it.
The discipline is new and complex. Content management -- especially Web content management -- is a relatively new discipline with a wide variety of approaches for solving basic problems. Vendor techniques and established operational patterns are much more diverse than in, say, the document imaging community, where technical and organizational norms have ruled for some time now. As Enterprise Search Report readers know, search technologies are also deceptively complicated, but amazingly easy to test: just install, index, and show query results. The results are good, or not. No CMS project of any meaningful size ever works that way.
The lack of norms and patterns cited above gets compounded by inexperience. In most CMS projects almost nobody on the project team -- from IT to management -- has actually implemented such a tool before. Here's where an outside integrator can certainly lend expertise, but your implementation partner might solely have experience with another vendor, or an older and quite different version of the vendor's product you chose. As readers of The CMS Report know, even dot-releases can bring major changes.
This is the background for one of my old rule of thumbs: A system integrator rarely makes a profit until the 3rd project with the same version from the same vendor. Changes introduced in new versions -- or a loyal customer selecting a CMS that its favored SI does not know -- often causes the faithful partner to make an overambitious proposal, forcing them to charge high rates on any change request to break even on the project.
It is thus a potentially expensive proposition to become among the first customers deploying a new version. Nicholas Carr asks whether that "IT matters," since it does not offer any competitive advantages; I'll simply just say that there is a first-mover disadvantage in fast-evolving technology markets, most notably CMS.
I've written previously on selecting the right implementation partner. For this article I'll just say: make sure your partner has good references, with at least 3 of them using the same version as yours from the same vendor.
Many systems integrators are very technically skilled, with strong competences in Microsoft technologies, Java, or the LAMP platform. Same probably goes for your own IT group. Don't be naïve and think that this translates into a capacity to successfully implement any Microsoft, Java, or LAMP-based CMS without significant problems. The reality is unfortunately not that simple, since developers still need to learn how the system works with specific content types, its interfaces and methods, and in many cases also a proprietary development environment.
Training matters. The majority of enterprise employees might be familiar with completing simple tasks inside a browser, but rarely so for editing text and images over the web. Your marketing and communication people may be used to writing for paper, but not for the online medium. The fact that most content management systems are rarely as easy as they seemed in the sales demo compounds the problem.
On the one side the vendor claims that very little training is required. On the other side your loyal colleagues are frustrated. They are doing the best they can, but it is very hard for them to grok a CMS and how it works. To get the new tasks, capabilities, and responsibilities properly anchored you'll need a significant investment in training. Most vendor documentation is not really geared towards business managers, and you have customized your CMS in any case.
Inasmuch as getting up to speed takes time for contributors, it's quite risky to get started with the training just a week before going live. This is late in the process to discover that the training needs were underestimated. You may cross the finish line with a couple of technology-enthusiastic colleagues, but after a while these staffers will become your new webmaster bottleneck. More funding will be required to develop and organize effective training sessions if you want to decentralize some of the tasks.
Remember that the necessary organizational changes can’t be "trained" and will take time to settle. You should also realize that the most significant aspect of the training, in particular for your non-technical business users, is not tied to a specific tool, but rather in getting them used to writing suitable text for the Web, applying metadata, and generally understanding how to use the new medium.
Indeed, many enterprises face a rude shock when the 2nd year of their CMS project finds costs approximating the 1st year expenses. Experience from more mature markets (e.g. ERP, CRM) suggests that the majority of costs occur after an initial systems deployment. Be realistic, exchange experience with other companies, and avoid the surprise.
Methods such as Total Cost of Ownership (TCO) or Return on Investment (ROI) might be employed by your vendor or your implementation partner to justify the significant expense here. These models, simplistic or advanced, may not take into account all cost factors, and as such, a narrow focus on TCO or ROI can get you into all sorts of trouble if you use them as justification and then blow your budget.
Instead I urge you to focus on the value drivers in the project. What is the value for the organization to have a well run website? What is the value of higher quality content or better online customer service? What drives this value and how can it be optimized?
Costs are important, and a smart manager will estimate them properly and contain them carefully, but a visionary manager will take a wider focus on value.
About | Blog | Contact | Impact | Newsletter