Here’s the secret! Scope Management is the most crucial knowledge domain for all industries and all sizes of a project. Project management is built around defining project scope.
To create an accurate project budget or schedule, you need to identify 100% of the project scope.
Risk Management will depend on the clarity of the scope of work.
Quality Management is simply a part of the scope.
Work Breakdown Structure is the central piece in project integration.
You got the point. Scope is the King of project management.
Today, I want to explain how to manage scope in a more reliable way AND with a real-life example.
What is the Project Scope?
Project Scope is the description of all the work that needs to be done to create deliverables and achieve the project objective. The best tools to describe project scope are the Project Scope Statement, Work Breakdown Structure, and WBS Dictionary.
Real-Life Project Scope Example
Below is the project scope example for a small real project.
However, the concepts of project scope management will be the same for any project. Even a big one will have all of the same components.
So, don’t overcomplicate scope management.
Example of Project Scope Statement
Many IT project managers don’t write a project scope this way and believe it’s an unneeded bureaucracy. But the fact is this exercise reduces the chances of project failure.
Notice that it’s a simple description of the project scope tailored to the customer’s understanding. We try to spell out project objectives in a narrative way.
Example of the Work Breakdown Structure
I have an in-depth guide on Work Breakdown Structure alone. If you want to dive really deep, read it next:
Ultimate Guide on How to Create a Robust Work Breakdown Structure
It’s a powerful tool that helps define project scope.
Example of the WBS Dictionary
WBS Dictionary contains additional information. In general, it refers to existing tickets and documentation.
As you can see, this project scope document required little effort. A project manager can use the rolling wave planning technique to add more details to deliverables as needed.
Moreover, the project scope statement was created together with the WBS and WBS dictionary in one project management application.
Also, note that it is simplistic. You don’t have to put everything a PMBOK Guide prescribes. Just ensure that the Scope Baseline serves its purpose: help project stakeholders understand the project’s scope.
You don’t want to miss this next part…
In-Depth Guide on Project Scope Management
Here’s the deal:
Before you start defining the project scope, you need to imagine the project END.
Ask yourself how you will hand off the final delivery to the project stakeholders.
Looks easy, doesn’t it?
No! What if stakeholders say it is not what they expected…at all?
So, how do you finish a project successfully and make clients happy?
How do You Define a Project Scope?
Below is the step-by-step guide on Project Scope Management. By the way, don’t forget to get my proven project scope management plan template.
Requirements vs. Project Scope
Just to be sure we are on the same side, let’s clarify the difference:
“Requirement is a condition or capability that is required to be present in a product, service or result to satisfy a contract or other formally imposed specification.” – PMBOK® Guide
And
“Project Scope is the work performed to deliver a product, service, or result with the specified features and functions.” – PMBOK® Guide
What does that mean?
A requirement is what a product should look like, what it should be capable of, what the characteristics, behavior, performance, etc., are.
While the project scope describes what work should be performed to meet those project requirements.
There’s one more critical definition:
”Quality is the degree to which a product complies with the requirements.”
You need to clarify the quality level for your project. It’ll significantly impact the scope of a project and project timeline.
You see, the zero-defects approach is too costly. It requires a lot of effort and a robust project management process.
Therefore, you need to reach an acceptable level of quality. And you must include the efforts to achieve that quality level in your project scope.
How to Create a Scope Management Plan That Works
Scope is the King.
Estimates of durations, costs, risk analysis, procurement – everything starts with the project scope.
A project manager is responsible for delivering what your customers perceive that they asked.
Read it again!
Customers think that they have clearly explained what you need to do. You think that you understood them correctly. That’s almost never the truth.
“The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw
To ensure that you are in line with what was asked of you, you need a scope management plan.
It should cover, at the very least, the following aspects:
Process #1: How to Collect Project Requirements
By this time, you already need to have an approved project charter. It should state project objectives and project requirements on a high level.
Also, you need to identify relevant stakeholders who can dwell on the high-level requirements. They may also have some additional ideas or related experience.
So what does it take?
In short, you need to communicate with all of them to collect project requirements. Here’s an example of how to collect stakeholder requirements from the project manager’s perspective.
Keep in mind that project managers should not collect requirements, especially on large and complex projects.
You need a separate specialist who is trained to collect and describe business requirements. It’s the role of a Business Analyst. BAs know how to tailor requirements to project objectives. Having a BA is a key to project success.
Instead, your role during project planning is to ensure that the business analyst collects requirements in a timely manner according to the project timeline.
For bigger projects, I recommend creating a Requirements Traceability Matrix. Learn more here:
Requirements Traceability Matrix in Project Management (Example+Template)
Process #2: How to Crackdown Requirements and Define Project Scope
Here’s a requirement:
“The pmbasics101.com website should have the capability to collect emails and send out a PDF document in return.”
What does it take to meet this requirement?
Select a mailing service provider.
Create an account.
Design the form to collect emails.
Implement the designed form.
Install the plugin from the mailing service provider.
Upload the PDF document.
Activate the form.
Test the form.
It’s just a list of required actions that a project team needs to do. If I were to put it correctly as a Deliverable and Work Packages, it would end up into this:
Email Opt-in Form 1.1 Report on Mailing Service Providers 1.2 Approved form design 1.3 Opt-in form on the testing environment 1.4 Test Report
So, how do you get from that one-sentence requirement to the actual scope of work?
A) You can find someone who has relevant experience or knowledge
It can be stakeholders, customers, external consultants, subject matter experts, or other parties.
So, your goal is to acquire them from the project team or just get in touch to communicate. They may have a solution already.
Otherwise, you may get directions or advice. It is a basic technique that you will apply widely.
B) Perform the Product Analysis
It is applicable when you need to create a product rather than a service or result.
This technique focuses on decomposing product value. Just like WBS does with the project scope.
Further, you need to analyze the product from ergonomic and functional viewpoints and then make decisions on materials or processes that will comply with performance requirements.
25 Examples of the Product Analysis
A project manager must define tangible deliverables.
C) Use the Alternatives Generation Technique
This technique works well when you have expertise in the nature of the project.
So, you need to find the best solution to meet the requirements. In most cases, you’ll use brainstorming to get the alternatives.
What’s the goal?
You need to clearly define what is and what is not part of the project scope. Likewise, you need to understand the project constraints related to the scope of work.
Process #3: Manage Project Scope with a PM Software
For sure, you can track the project scope in any available app. For example, Google Drive, Evernote, or MS Word will do.
However, there are serious benefits to using integrated project management software to keep everything in one place.
Ideally, you need to be able to link requirements to the project deliverables.
Then, from deliverables to specific tasks with estimates, related risks, and defects.
You can create a Work Breakdown Structure in any PM software. You don’t need a special tool for that!
For example, I can recommend Paymo. It’s one of the best apps for personal use and for small projects. Additionally, it has great time-tracking and invoicing capabilities.
Process #4: How to Control Project Scope
It is not enough to identify 100% of the project scope in the beginning. That 100 % WILL change during the project life cycle. It’s called scope creep.
So, you need a way to monitor, control, and make changes to the project scope.
The cure is well-known to all great project managers. It’s a Work Breakdown Structure.
Well, also, you do need a clear workflow to introduce changes to all areas of the project whenever the amount of work changes.
However, it’s a matter of an integrated change management process
So, what’s the catch?
You need a high-quality WBS. Moreover, you need a non-nerdy way to describe the project scope. Therefore, you also need a Project Scope Statement. We’ll discuss it below.
If you are on an agile project, the clearly defined scope of increment or iteration is even more vital. Do not think that agile saves you from thoroughly documenting the work. Keep your Sprint Backlog and User Stories neat. Apply a simple rule: “A newcomer should understand what needs to be done from the User Story description.”
5. How to Validate Project Scope and Project Deliverables
Once in a while, you need to get a formal sign-off that a deliverable meets stakeholders’ expectations.
It’s crucial to do that continuously throughout the project. Even if you are leading a plan-driven project, nothing should stop you from providing product increments for review.
Why do you need this?
You don’t want to get all the change requests, all the defects, and “minor changes to the project” in the end.
You’ll deprive yourself of the opportunity to actually integrate a change into the project.
The closer you are to the project closure, the less time and resources will be left. Moreover, stakeholders will be less prone to negotiating changes to the project scope, timeline, or project budget. Also, they’ll put more pressure on the project team to get what they need.
Just stating the obvious:
It is highly important to have a clearly described and approved project scope from the start.
When a deliverable does not meet expectations, there will be corrections.
It is your responsibility to prove whether a correction is a change request and therefore, it should be integrated properly. Otherwise, it is a defect, and you must make amends. Sometimes at your own expense.
How do you actually validate project scope with customers?
On any project, you can use Scrum-like Demo Meeting
Just prepare a short demonstration of the deliverable. Explain the current project status and progress. After that, point out known defects and work-in-progress parts.
Also, do collect feedback from the customer. Later, you can provide any supporting documentation and reports required by your policies.
Bottom line:
Collect feedback from stakeholders continuously. Negotiate terms of the introduction of new change requests. Keep the project Scope Baseline up to date.
Why is the Whole Scope Baseline Critical for Your Project?
Usually, a project starts, and we receive requirements in different forms.
For instance, emails, PDFs, meetings, mockups, bug reports, etc.
And, of course, we do not prepare a Project Charter or anything similar. Bad practice!
In most cases, we don’t even discuss the business case for the project.
We do usually create a Work Breakdown Structure.
However, it’s only used internally and never goes to the customer. Then, we decompose the work into the activities and estimate the project. We use a bottom-up estimation technique.
Now comes the first expectations check:
We present estimates for the project.
You see, there’s apparently a lack of transparency here. The customer doesn’t know what work we actually estimated
If the estimate is close to the customer’s expectations, he’ll not dig into the details. This is because he’s ready to spend that amount of money and time already. He doesn’t want to waste their precious time.
Here’s the truth:
A lot of organizations and project managers hide inefficiencies behind such silent agreements.
It is a topic for a separate post, but it is the root cause of many of your problems.
What happens next?
We start project execution! Sooner or later, the customer will ask to add another piece of work.
After that, we’ll find a part of unidentified work. Later, quality problems will appear. They will take up a lot of time.
All in all, we hand off a delivery to find out we did something wrong.
And that’s when the customer informs us that he forgot something and it should be added ASAP.
Believe me, you’ll experience it more than once.
Project Scope Baseline Definition
”Scope baseline is the approved version of a project scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedure and is used as a basis for comparison.” -PMBOK® Guide
What is a Project Scope Statement?
Definition of the Project Scope Statement
Project Scope Statement is a narrative description of a product and project scope.
It is used as a written confirmation of what your project is going to produce and how.
What’s the key to a valuable project scope statement?
I believe you need to use terms and language that any stakeholder understands. The project scope statement is mainly for the customer.
OK, what should be included?
1. Justification of a project
It is a short description of the needs of the business. Sometimes, one sentence is enough. The rest should stay in the Project Charter.
2. Product Scope in Project Management
It’s a description of the characteristics, traits, and functionality of a product or a service that you will produce.
Keep in mind that you collected requirements from different stakeholders. So, do not assume that all of them keep track of each requirement. Also, it’s not always clear how much work is required to deliver a requirement.
It’s the primary place to align the expectations of key stakeholders.
You need to show the amount and complexity of the work required to meet different requirements. Therefore, put the most effort into this section.
3. Acceptance criteria
It’s the conditions that must be met before deliverables are accepted.
You can include an acceptable level and the number of defects here as well.
4. Deliverables
It’s a description of all deliverables your project will produce.
It may include the product or service, project documentation, product manuals, educational materials for your product, etc.
5. Project Exclusions
Here, you need to specify what is out of the project scope.
Quite often, some of the stakeholders want something specific. The other part of stakeholders or a customer does not support it.
Therefore, it’s a conflict situation. Once the conflict is resolved and it is decided to remove something from the project scope, put it here.
Be specific and very clear about it. It saves time in the future.
Firstly, you won’t have to revisit these project exclusions again. Stakeholders may try to include them later during project execution.
However, unless something dramatically changes, you should not waste time reviewing exclusions.
Secondly, unless it’s clearly stated, someone may still expect you to deliver it. Don’t feed false expectations. It’ll be easier to hand off the project at the end.
6. Constraints
Anything that limits your ability to deliver the product efficiently should be stated here.
7. Assumptions
It’s the uncertainties that cannot be clarified at this moment.
You need to accept some of them during project planning and throughout the project life cycle. In case an assumption proves to be invalid, you will have a right to modify the project plan.
A customer should approve the project scope statement. In fact, it is a formal and mutual agreement.
Also, it states that you are committed to delivering the described results under definite assumptions and with clear constraints. On the other hand, the customer agrees to accept the specified result.
It does not mean that we cannot change the project scope. No. It means that to make a change – we need to amend the agreement.
Conclusion on Project Scope Management
Unfortunately, this article was just one piece of a complex project scope management framework: Many other processes happen before and after this one.
If one part doesn’t work, the whole system breaks.
My Scope Management Plan Template connects all processes and tools into one cohesive system. It also provides access to other articles and videos on scope management.
Don’t put your projects and reputation at risk. Ensure you know how scope management works in the real world.
All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). Tap into my 12 years of practical IT experience and get the Scope Management Plan Template.