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.