Scope definition is one issue most projects struggle with. If you don’t pin down the scope early in the project’s life cycle, it can come back to bite you later. Every project manager knows that scope is one side of the iron triangle of project management. It is definitely impacted by changes in the schedule and cost. If the scope is changed unilaterally, it will certainly impact the schedule or cost or both.
If you want the project to complete as planned within the allocated time and cost, it is therefore very important to not only keep scope creep in check, but also to get the scope right the first time.
“But my project’s scope keeps changing all the time,” you say. It can certainly feel that way, almost like you are trying to hit a moving target. It feels that way because you are going about it the wrong way. You are in the thick of things already. You need to step back, and you need to step higher – much higher if you want to define the scope.
Product Scope and Project Scope Are Different Beasts
Product scope determines the features and functions that are to be included in a product or service. The project scope is the work that must be done to deliver a product with the specified features and functions.
If your project is to “build a car”, then when your project is complete, your car will have four wheels, an engine, seats, a steering wheel, doors and windows, an air-conditioner, and an attractive coat of paint. You will be able to drive it on the freeway like a normal car. To get to that stage you would have bought the tires, doors, seats, etc., assembled the components of the car, painted it, tuned the engine, and test driven it.
The features of the car – wheels, gears, AC; and the functioning of the car – drivable and stoppable – describe the product scope for the car. The work done to build the car from the components (or Bill of Materials) describes the project scope.
Now that we have understood what the scope of the project is – let’s look at some of the challenges faced when defining and managing the scope. Understanding that will help us get moving along the right path to defining the project scope correctly.
Problems with Scope
People make assumptions
When the scope is not written down clearly or is incomplete, people tend to make assumptions. Often these assumptions are subjective and not know to anyone else. This leads to a lot of confusion later. If assumptions are made, they must be written down in the scope document. This will give everyone an opportunity to refute them or accept them.
Some key individuals are left out
It is often difficult to get all the key stakeholders together in a room. As a result some of them are left out of discussions. This must be avoided. The PM must ensure that all stakeholders get to participate in defining the scope – even if it takes multiple partial meetings complemented by emails and a final scope signoff.
Lack of change management
You have heard of projects that never end. This is because the scope keeps increasing as the project progresses. This is called scope creep. The way to avoid this is to have strict change management processes in place. Once a scope is defined, it must not be changed without the appropriate change management functions.
The Right Process to Define Scope Correctly
Pin down the product scope
Before you determine what will be in the project’s scope, you must be very clear about what is in the product’s scope. In other words, what are the functions and features that will be available when the project completes successfully. This is also called the objective.
Involve the right stakeholders right from the start
The whole purpose of the project is to meet a need (the product scope). The Business that is paying to meet this need must be involved very intimately in defining the need, and determining what is in-scope and what is out-of-scope. In addition to the Business that benefits from the project there are many other stakeholders that you need to get involved. Stakeholders include:
- people and teams who are impacted by the project – beneficially or adversely
- people and teams who need to contribute to the project – by buying, selling, building, destroying, etc.
- vendors, end users, etc.
Identify the limitations
Perhaps even more important than what is in-scope for the project is what is out-of-scope for the project. It is crucial to document what will not be done – otherwise people will assume that certain things will be done. It is also better to exclude these limitations right at the start, so that you don’t waste time talking about them when you are determining the project scope.
Meet stakeholders individually before meeting them as a group
Meet with the stakeholders and ask them simple questions that start with “what, why, how, etc.” This will give you an opportunity to get a lot of information and differing opinions before you approach the group with a streamlined initial draft of the scope. It is easier for people to review a list of items than it is to build one. The list of limitations in the right forum can easily generate sufficient discussions to clearly remove unnecessary things from the project scope.
Review, review, review. Then sign off
After multiple rounds of discussion, when the scope is very clear, all the stakeholders must review it by and sign off on it. Once signed off, no changes can be made without the proper change control mechanism defined for the project. All stakeholders must aware of this condition. Give them a final opportunity to finalize the scope before you build the schedule and the budget.
If new stakeholders join the project midway – educate them on what has happened so far
I reiterate – everyone needs to be on the same page and understand the constraints that will be placed on them by the project.
Conclusion
Understand the need that the project will satisfy. Identify all the stakeholders. Make sure all stakeholders are involved from the beginning. Make sure they all understand the need that the project will satisfy and that they are on board. Ensure everyone understands the change management process. Review the scope document and sign it off.
If you have any questions, comments, rants, or disagreements, feel free to post a comment. I will definitely try to respond to your comment.
