Why is a CMS project different?

Four major reasons why CMS Projects are different from typical Web Application Development projects:

1. Two websites
2. Content loading and/or migration
3. Training of business
4. High User involvement

TWO SITES

When you do a CMS, you are actually doing 2 websites. You are doing the External facing site for the end users of your system and you are doing an internal website for the content authors. No matter the CMS package that you use, there is always work to do on the internal site. Both websites require good UI Design and thoughtful navigation. The internal website requires in addition: groups, workflows, content permissions. The external site includes as you'd expect:  branding, user personas, usability testing, integrations, etc., etc.

Creation of the Content Authoring environments is often one of the most underestimated things in a CMS project and if it's not done well, your Content Authors won't adopt the new CMS and the entire system is a failure.

CONTENT LOADING / MIGRATION

This is a phase that has no counterpart in normal web application building (except for data migration possibly).  There are 2 efforts that can be undergone here:

1.  Attempt to automate content loading via the CMS's API. This only works if the source content is structured (either in an old CMS, relational database or well-tagged HTML).  Typically the amount you can automatically load is very small and overestimated by managers.

2. Manual content loading either by our team (typically PM and BA and IA) or if we are smart, by the content authors themselves.  The issue with letting the content authors do it is they require training AND they require the CMS Input Screens (see Internal Site above) to be functional and TESTED! This usually presents a large scheduling problem with CMS projects right from the get-go.

This step is FURTHER complicated b/c clients typically want to take this opportunity to re-write their content for the new site presenting a Project Management nightmare given all the departments and people involved in rewriting an entire corporate website.

The tasks we typically end up doing during this phase is coming up with a content deck that itemizes each piece of content in the new system, a mapping to the old system typically including which person or group owns the content. Then it's a matter of wrangling everyone to assign someone to re-write and herding the content as it comes back. If we have scoped enough effort to do this correctly, we can let the content authors do their work in Word while the Content Authoring/Internal Site development is being done, thereby removing a major project dependency.

TRAINING OF BUSINESS USERS

Yes, this can be a real pain, but typically, we need to take this on.  The CMS solution vendor can provide training for their tools, but b/c CMS's are usually a toolkit for providing the authoring environment, the system we end up building is significantly different from the OOB (out of the box) functionality. This means we need to create training manuals and run training sessions for the content authors further complicating the scheduling difficulties.

This is addition to what we typically do for IT teams of training them on how the system was developed and how to maintain it after we are gone.

HIGH USER INVOLVEMENT

This seems obvious, but it can cause huge headaches for PMs. This basically means lots of management time being spent dealing with all the different departments and stakeholders. It's really a symptom of numbers 1, 2 & 3 put together. It all just equals more time managing client stakeholders for both sites including Content Migration/Loading and Training.

Let me know if you think of other things that make a CMS project unique!