How to Plan a CMS Project - Project Scope

In the project brief, we establish the project purpose and objectives. That's just the starting point; it doesn't necessarily mean the objectives are reasonable or achievable, but tackling that at the point of drafting the project brief is difficult. It's easier once you have established the success factors and then can reconsider the project objectives and establish what is in and out of scope for this project. This part of the planning workshop is to achieve the following tasks: Take the project objectives to work out the project scope.

  • State what's in scope.

  • State what's out of scope.

  • State what might be in scope.

The outcome is a clear statement of the boundaries of the project.

As with the success sliders, a visual representation is a great way to show what's in and out of scope. For each of the objectives, we decide if they are in or out of scope for this project. That doesn't mean they aren't done ever, just in this project. I often use "Stage 2" as a way of calming clients who get worried when they see features in the "out of scope" column. Another way to consider these features is that they are done by someone else. With the "to be decided" row at the bottom of the table, we can put objectives that the client would like to achieve but hasn't yet confirmed if they are absolutely necessary.

In Scope

Events Calendar Product Catalogue Distributed Authoring 2-Level Authoring Workflow Site Search

Out of Scope

Content Population Real-time payments Integration with ERP system

To be decided Supplier extranet

In the example above, we have a number of project objectives that are to be implemented and are considered in scope. The right column shows what is NOT in scope. In the case of content population, it's actually required for the project but will be outsourced so it's not in scope for our project team. It's important to explicitly state what's out of scope so that assumptions don't creep in later down the track. A typical example, I've learned the hard way, is you get to the point of data entry and the client says "I thought you were going to do that". At this point, unless you've stated clearly upfront that it's not in scope, you have a situation that you need to manage delicately.

When deciding what's in scope and out of scope, you can refer back to success factors to help with the decision-making process. If the client has already stated that budget is of primary importance, you can use this as leverage to move objectives to "might be" or "out of scope". Conversely, if budget is not an issue, you can have more objectives in scope and know that if more money is required, the client will be accepting of this.