Four major reasons why CMS Projects are different than 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 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 teh 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 teh 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 #s
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!