Risk Management - Key Risks in Content Management

The majority of the information in this chapter could apply to most projects. For CMS projects there are two main risks to be aware of.


The most important is the experience level of the production team. Despite the level of documentation and the ease of installation, a CMS is a sophisticated application and not something that can be installed and configured in a week. It takes time to get a full understanding of the application and how it operates to then be able to effectively use it to deliver quality solutions.

If you're starting on your first project with a CMS and you don't have an experienced programmer, at least double the amount of time you think it will take. The official technical training course takes 4 days. That's for a developer with code and db skills. Then allow another 2 – 3 months of working with the chosen CMS for that developer to be proficient enough to be able to develop sites with any level of interactivity.

The same goes for clients, if this is the first content management based site that they are embarking on, there will be a learning curve for them to understand how eZ publish based solutions differ from a static website. It will definitely increase the time taken to get the specification right and ensure that there's a full understanding of how the end result will be implemented and work.

Finally, the experience of the end user of the system is important to ensure it achieves the benefits expected. Part of this can be managed by training but there is still a factor that relies on the people using the system. They have to be proficient with the web and at the same time have an understanding of content. Naturally, people that understand the business domain and have worked with content management systems are at an advantage but it's the understanding of content and how it works with eZ publish, differing views, different locations…etc that really matters.


Over five years and 50projects, I've only had one client that had all the content written, in the right format and ready to be entered into the site when production had finished. The worst example was a site that sat for 6 months as the client got their content together, and that was after I offered to enter it for them for free!

When it comes to content, expect the worst. Mostly likely it will be incomplete, poorly written or in some cases, non existent. And that's even with the best intentions! Getting the content and getting it into the system is the single largest risk for project delays. Allow plenty of time for this task, if you can, take control of this and get your team to enter the content, leaving it to the client is a huge risk and puts the schedule out of your control. Naturally, if the content doesn't exist, there's not much you can do but there are techniques that can help to mitigate this risk.