Sunday, March 9, 2008

Speak Nicely About Your New WCMS System - Even if You Hate It

As a Web content professional, when you get a nice, shiny, new version 1.0 of a new WCMS system, I promise you will have a long list of things you hate. Absolutely hate. It’s too slow, workflow is buggy, it’s too hard to use, HTML generation takes forever, where did my changes go, and on and on. Once you start to use it, you will find a hundred things you wish were implemented differently. Be very, very careful about how you talk about this new, and admittedly, ugly baby. You will be living with it for a long time.

I learned this one the hard way. To get all the benefit out of a WCMS, you will need a lot of people throughout the organization to play a part. We made the mistake of being very vocal about early problems. We complained for hours about how painful it was to get even a small amount of work done. So much so that now, years later, I still get a huge pushback every time I try to pull an outside department into the WCMS development process. They heard so much bad news about the system when it first launched that now when they hear the term ‘WCMS’ used, they run the other way. Suddenly they are swamped and have no time to participate as a reviewer in WCMS workflow. “Can you just send us a hardcopy that we can mark up?” No, we can’t. That causes all kinds of problems. That’s why we have workflow.

One by one, we have addressed the problems and limitations of our early system. It is light years better than when we started, but THAT message is not very interesting and no one hears it. All they remember is how the content team had to work until midnight every night to get a meager amount of content through the system and generated and they run the other way. It’s too late for us. I’ll be fighting this battle for years. Don’t make the same mistake.

Wednesday, March 5, 2008

Content Reviews in the WCMS and Scope Creep

My WCMS lets me send anything out for review and comment through a system controlled workflow; complete pages, individual modules, or images. Logically, most reviewers prefer to see an entire content page rather than just a module, so they can view the change in context. The problem with sending the entire page out for review is that they then want to make changes to the entire page, instead of just reviewing and approving a small change.

Everyone thinks they are a writer and wants to reword and re-write content that is factually correct. In my experience it’s about a 50-50 chance that they will actually make the content better with out-of-scope edits.

Sure, a few extra CMS changes to a content page should not be a big problem. But we are working on dozens of projects at any one time and they are all tightly scoped and staffed. Even a minor change to all of them would blow up our project plans, not to mention the impacts on translation word counts and schedules.

I try to manage this process by:
  • Regularly contacting subject matter experts and asking them to review site content while we are not working on that part of the site. If they find changes they can submit them for regular maintenance (non project) work.
  • If a content page is very large (an FAQ page for example), I send only the CMS module that changed out for review.
  • When I send content out for review, I send a detailed manifest to each reviewer that lists, in detail, exactly what changed on each page.
  • If I get comments back on existing content that was unchanged as part of the current project, I tell them it is out of scope and tell them how to submit the change as a maintenance request.

The thing I find most helpful is the detailed change manifest. If I can show a reviewer that the content he wants to change has nothing to do with the current project, and has also been live out on the site for some time, and that they could have submitted a maintenance request at any time if they had only looked at their content, they usually back down and agree to defer the change to maintenance. Often, the maintenance team is able to get the change out earlier than if it had been tied up with a non-related project.

Saturday, March 1, 2008

Site Re-design = Site Re-write = Lots of Time

I like to keep up with my friends in the Web agency world to see how life is back on that side of the fence. Everyone I talk to these days is doing a site re-design of one kind or another. The opportunities to build a brand new big, enterprise Web site have passed. So now it’s all about re-design and re-launch.

The thing that they all seem to be having trouble with is forgetting they also have to re-write. A typical re-design is not just a graphical facelift; it’s a fresh look at customer needs and a changing competitive environment. So a great deal of time is spent on analysis and figuring out how to best address a complex series of user needs. And rightly so. But what frequently gets lost in the project plan is adequate time to re-write the entire site.

As you change design, page layout, and information architecture, you insure that it will be impossible to have any kind of automated script run to migrate existing content into the new design. Content will be chunked in new ways, with new pages, and new WCSM content templates (or even a completely new content management system). This is not a cut-and-paste exercise.
In every case I’ve been exposed to, the content re-loading has completely blown out the project plan. What was planned to take two weeks takes two months and twice as many writes/editors as planned.

Think about how long it took to write all the content in an existing site, it’s probably years. You simply can’t re-do all that work in a few weeks. Every piece of content will have to be looked at and restructured to fit in the new page layout and templates. New pages will have to be created, new messaging will need to be written, and new index pages will have to link all this together so that new navigation systems can be coded and generated.

Add to this new content management functionality, that may or may not work properly at first, and you are looking at project plan nightmare.

I see this all the time and the solution is really simple math. Take the new CMS, figure out how long it takes to build a new module, estimate the number of modules on an average page, figure out how many pages have to be generated and start multiplying. It’s not difficult, but the numbers are so terrifying that planners and managers just don’t want to think about it.

I speak from experience here as I was involved in a complete site re-design that was completely derailed by the time it took to re-write all the site content in a new WCMS. In the end, it took a full year get the new content written in the new WCMS, translated, and generated out to working HTML.

If you are in this kind of project, step up and talk about the 900 pound gorilla in the room. I know it’s big and scary, but feed it now or feed it later. Either way, it’s going to eat a ton of time and money.