Over the past couple of years, I have been seeing this recurring theme of companies redesigning their websites (internal and external) according to aspirations based other websites with a lot more content than they have. During the design, stakeholders envision a user experience rich with information that is personalized and interrelated. The problem is not so great with static websites because identification and production of content happens when the website is developed. If the content does not exist, it is not in the design. The presence of a CMS shifts responsibility for this content away from the project team (often consultants) and to the business users whose eyes are often larger than their bandwidth. The time of this effort is pushed later - after the project budget has been spent. The capability to change content can turn into a burden if the expectation of fresh content is communicated to the audience but effort was not budgeted for.
Sometimes no matter how much these facts are communicated, there is a level of disappointment when the site does not look like the mockup because the content is just not there or because of the extra workload that the "labor saving" CMS starts to impose. At all costs, we need to avert this letdown. Otherwise the project will not be considered a success even if the implementation was executed flawlessly. Rather than talk at the abstract level, my recommendation is to point to very specific responsibilities and get commitment and ownership at design time. Here are some good questions to ask when you hear stakeholders over-committing...
- "We want the site to have lots of graphs and charts."
Who in the organization has the tools, skills, and time to generate images? Give them an assignment to create a weeks worth of images for dummy data and see if it gets done or if other tasks are delayed.
- "We need the text to be in this special (non-standard) font. It's our brand."
This means that someone without graphics production capabilities will not be able to update the site. You will now have the same bottleneck as you had with your static site.
- "We only want to show relevant information to the visitor. Every page needs to be personalized."
What do you show a visitor if you don't have anything relevant to show them? How will content producers preview and QA the site if it will look different to everyone?
- "We want the site to look different every day with new and interesting content"
Who is going to make the site look different? The potential to aggregate syndicated content will make this goal much easier to deliver on. However, you might ask the question why it needs to look different every day. It is unrealistic to want someone (who is not an employee) visit a corporate brochure site every day. Those sites are generally designed to educate, not be a news source.
- "The reason why no one contributes content is that the system is so unusable"
That may be the case. One way to test this is to stand up a wiki (or if you have article based content, a blog or Drupal) as a temporary site to stage content for the new site. Do everything you can to get people to contribute. If something as simple as a wiki stands in the way of people contributing, maybe you have an organizational problem, not a technology problem. This is especially the case for intranet based sites which have an alarming failure rate. Very seldom are people rewarded for their intranet contributions like other job responsibilities.
The big point here is that, in addition to making sure that your CMS is usable, you also need to think about manageability issues. Is the design something that can be maintained? Is there enough value in the site to justify an ongoing investment in managing it? Each category of content on the site must have an owner who is motivated (either because it is his job or his passion) to be responsible for the quality and usefulness of the content. Otherwise no amount of design or technology is going to lead to success.