Project Scope Management – The Basic Principles

When a project manager is willing to accept all stakeholders’ scope change requests to the detriment of other project objectives, we call this scope creep. However, if she is too conservative and tends to keep project scope fixed as defined in the original scope statement, she will poorly meet stakeholders’ expectations. How can project managers resolve this dilemma?

Each project manager has her own practice to overcome this issue. What I would like to do in this article is to address some basic principles for effective scope management. Here, by basic principles I mean if you fail to apply them, you will fail to manage your project scope.

Project scope must be based on requirements

The scope statement includes deliverables that the project must produce to fulfill requirements. While requirements are written in business language, project deliverables are written in product-oriented language. Any change request regarding project deliverables must be preceded by a change in requirements.

You cannot add features that do not reflect any requirements. Many people do that just because they want their customers to be happy, or because there is time left until the deadline of a particular deliverable. This practice is referred to as gold plating.

The main reason for not practicing gold plating is that gold plating can increase your project risks in the following ways

Additional features may prevent the required functions to work properly. You may have to spend time for reworks if these additional features do not work. Additional features that are great in your opinion may not be so for other stakeholders.

There must be an integrated control over project scope

There are mostly always changes to scope during project. However, you must have an overall control over project scope. Here, by control we do not necessarily mean you must prevent changes. On the contrary, if changes are needed in order to fulfill current requirements that are more actual than the original requirements, those changes must be implemented. Controlling project scope includes

Understand the root-cause of changes to the project scope.

Identify tendency of changes and the risks associated with them.

Prevent unnecessary changes to the project scope.

Project scope must be regularly verified with project stakeholders

The produced deliverables must be verified with stakeholders to ensure that these deliverables do fulfill requirements. You can verify scope at each project milestone or whenever a key deliverable is completed. It is not necessary to wait until the end of the project to verify all deliverables.

By regularly verifying scope, you can ensure that

You do not produce deliverables that do not fulfill requirements.

Project stakeholders are informed about the project status; as a result they can give you timely feedbacks about deliverables.

Another reason for regular scope verification is that project scope statement includes assumptions and constraints, which may change significantly during project. If you consider scope verification as a way to communicate with project stakeholders about project status, you can verify not only the deliverables, but also the assumptions and constraints. A change in assumptions and constraints may lead to a change in requirements or a change in the way project deliverables can fulfill these requirements.

Do you think that following these principles ensures effective scope management?