You got the budget approved, purchased the right Web Content Management (WCM) system, and the implementation team is ready to go. Now it's easy, right? Not so much. Here are 10 mistakes frequently made by business stakeholders during a WCM implementation. These are human issues. No vendor or product can prevent them (though some make them much worse). By my count, we made six of these mistakes ourselves on Percussion.com last year. We're correcting them of course. But remember, perfection is a goal.

10. The Field of Dreams assumption:
"if you build it, they will come."



You built a kick-ass WCM and website. That doesn't mean anyone is going to show up. Since you sold this system on actual business results, you need more than a beautiful site. The fun, but also hard part -- getting people to come back again and again -- requires you to USE the system you just built. Plan in a coordinated effort to create new content, update pages, and promote them socially through blogs, Twitter, comments and responses and so on all to happen consistently AFTER the launch.

9. Forgetting the content budget.
It's easy to get an initial WCM implementation project approved. Any "project" has a start and an end, making it a one time expense that's easy for management to predict and control. A commitment for continued investment is a much higher bar to get over. Success on the Web demands a steady flow of new content and customer interaction. By securing the ongoing commitment of resources first, be it creative, technical, budget, or just editorial time, you'll have the continued forces needed to ensure success.

8. Not making it personal.

Project managers preach this everywhere, and it's particularly important for Web projects. The website is a classic "tragedy of the commons" for most organizations - everyone has a stake in it, but no one seems to own it. It's easy to list out "marketing" for approval or assign responsibilities to "the front end team." None of these general purpose designations can be held accountable, nor will they answer your call when needed. Make it personal and watch the difference in meetings when you start listing out "I'm going to need this much time from Mike, Susan and Wendy," instead of Marketing, Sales and Web Development.

7. Features don't replace people.
With more power available at less cost than ever before, today's WCM systems can solve many problems. That doesn't mean it should all be implemented from the start. There are only so many people to write content, create new art and rich media, cull through external content, moderate comments, review polls, and otherwise utilize all the new capabilities that the WCM can provide. Features that are "on" the site but not used actively can send a bad signal, making your organization appear less responsive that if they were not there at all. Anything you're not ready to use , postpone.

6. Manual is not a sin.
When implementing a WCMS there's a lot of focus on "elegant" solutions that avoid any "manual" steps required. For any. Users. Ever. But managers must remember that all implementation comes with some cost that must be justified. Manual may be the better choice in many areas. Here's a use case: implementers built a reusable address and contact form look-up feature so that users would not have to manually enter in addresses for branch offices. This particular customer had exactly one branch office, and no plans to add another, and did all their real work online. Cut and paste may seem like a "hack" but if done only twice a year, it's probably ok.

5. "Peter, did you um, see the MEMO about this?"



During the WCMS planning stage, everyone thinks notification is a good idea. Stale content? Sure, send me a reminder! Approval needed? Yes, every time. AFTER the system is on, the complaints will roll in. Turns out the only thing worse than getting emails from seven different bosses is getting emails from an automated WCM server. No one wants a deluge of reminder emails. Even if they're packaged up in a digest, anything truly important is lost in the noise. Try a collaborative process first. If your WCM supports a universal link of some kind, just email it, IM it, or even Tweet it, to the person who needs to approve your content. The ones that become a pain after a while are the ones to automate. Leave the rest. The personal touch is more effective and besides, being more social is a good thing.

4. The solution to "garbage in, garbage out" is... improving the flow of garbage?
Streamlining existing tasks is tempting and a WCM has a lot to offer here. But if your company is producing dull static press releases that generate no interest, chances are that generating lots more of them won't help improve the site. Every part of the implementation -- including a strategy for quality content -- should be prioritized based of how much it improves your Web presence. Even if you have the spare cycles to automate things (and you don't), the new "wheat" of your site will get lost in the "chaff" of the automated garbage still streaming out.

3. The Stonehenge scenario:
"the real one will be just like this, right?"



In Spinal Tap, a band manager reviews what he thinks is a prototype of a stage prop for his band's performance. As he looks at an 18 inch stone monolith on a coffee table, he raves about the detail and wraps up the approvals by saying "great, and the real one will look just like this?" The designer replies "This IS the real one!" The ensuing scene where the band attempts to perform as the tiny model descends is comedy gold. You won't feel like laughing, however, when this happens with your design. All too often design mock ups do not hold up when real content is used. Will that navigation panel on the left work with only one sub section? Or when it grows to ten? Good design agencies avoid problems like this by plotting out your "real" content, but with WCM the whole point is to frequently change your content. Today's Web designs have to be robust enough to expand and contract with the changing content. Few will actually "break," but the design you liked best may not hold up as well when things change. When doing design reviews, run the same design mock-up for the same page but with at least two additional content scenarios; "filled up" and "nearly empty." Now decide which design you like best on average. Don't make Spinal Tap's mistake.

2. Stifling creativity uncertainty.
Creativity has been described as the ability to be ok with "not being certain" for as long as possible. Uncertainty annoys developers and managers alike, but you must embrace it at some level. "You folks have to tell us what you want" is one line I hear over and over directed at marketing and the creative team (usually when the design changes, again.) Instead of attempting to reign in creative freedom, implementers can plan for it. Every system should build the "outs" needed to allow creative change points. At least one set of templates or pages or content objects should have almost complete freedom to mix and match and make last minute decisions on the fly. That choice of template may require more work by the user, but they'll be happy to have the freedom. Now you can identify pages and areas on the site where marketing is certain to want to do the same thing over and over again, and impose structure there. 

1. "Finishing" the project.
Good managers drive to completion dates above all else, making this the number one pitfall in a WCM implementation. Web sites are not typical business applications, they are a living, breathing communication channel between you and your customers. In order to stay relevant, draw traffic and inbounds, organizations need to change far more than content. Interactivity features, templates, and designs need to be refined as tastes and usage dictate, while policy and process changes are needed to support any of these new interaction modes. These are changes go beyond content. WCM project managers must keep a vigorous backlog of "next." The moment you declare the implementation "done" it starts to die.

Well that's my take. Did I leave some out, get some wrong? Let me know in the comments!