A scope statement is about producing a project that delivers. The statement itself is designed to be a best reflection of that. It exists as our practice to provide focus in a more detailed way than a SOW ever could. 

The problem I have with project scope is that it actually exists to guide change and as a change document, it sucks. Change is inevitable and scoping your project well in the beginning does nothing to prevent changes from happening on your project. Stopping change is fruitless. It is INEVITABLE. 

Many project managers believe that a well written scope statement helps them decide if changes are out of scope. In my experience, it can be used as a north star to the overall project delivery and wielded towards key stakeholders to prove ‘rightness’ in managing the planned project work.

The problem? Holding on to work being right. Who says the work and the tasks are right? By what measure do we determine the right-est way to deliver in scope, on time and in budget?

The project sponsor and/or key stakeholders ultimately decide if the project's successful. Their viewpoint is all that really matters as they underwrite the journey to its completion. I see scope that is clearly defined as the north star of one's collaboration with them. 

A poorly constructed scope statement can create problems and lead to scope creep which most project managers have been indoctrinated to fear. Like the ‘hob-goblin’ of our profession, we are loath to experience it and have been told that and the lack of clarity around scope is the reason it happens. I would argue that the real risk of scope creep is that it indicates we are misaligned with our stakeholders.

Effective scope management requires good communication so everyone understands the project and agrees upon how the project’s goals will be met. Remaining agile to change is a fundamental requirement which means keeping your stakeholders close and your project sponsor even closer. A detailed and well defined scope statement cannot be used as a change management plan. That needs to be rooted in relationship and collaboration with your project team and created alongside scope but not entirely within it.

The change manager in me recognizes that scope, as a tool, is an effective way to capture project focus. But, that same part of me knows that scope is rigid and nothing about the project management I practice is rigid anymore. 

When the chips are down, it’s always the relationships and collaborations that I’ve built within the project team that defines the overall success of the project. So, I will not fear scope creep AND I will hold my scope statements loosely. Leveraging them when they help me focus and letting them go when the ‘you know what’ hits the fan. Because, the worst thing that can happen is that we start another project. . .

(a.k.a.) The Feisty PM