How do we control the additional scope?


Everyone hates changing goalposts, yet most of us experience scope creep in projects. Customers ask for additional features, modules, and digital capabilities throughout the project.

The vital question is:

Is the addition of more scope a bad thing?

Absolutely not – as long as you are fully aware of your baseline, and there are rational reasons for additional scope.

The problem is that often there is no agreed baseline for the project’s scope. Further, the additional scope is proposed based on emotion and unsolicited pressure. As a result, the project timeline expands, and the cost increases.

So, what we can do about it? How to control the additional scope?

Simple, by clearly defining the project’s baseline scope and objective.

The baseline project scope defines the minimum set of business functions that must be delivered for Go-Live acceptance.

The Project Objective is the guiding statement to remind all stakeholders of the project’s objective. In addition, the Project Objective acts as a guide to vet all new additional scope requests. Every new request must satisfy the objective of the project.

The key is to have a process to state mutually agreed scope boundaries. When the scope changes, it must comply with the overarching Project Objective. This formality and rigour help us to be more intentional in our decisions. In addition, it allows us to remain focused and stop continuous drifting on the project timeline.