Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Categories: scope
It’s time for part 3 of our journey through the Scope Management Knowledge Area from the PMBOK Guide®-- Sixth Edition. Today, we’re looking at the Define Scope process.
Check out the previous parts:
The Define Scope process happens early in the project so that everyone has clarity on what the project is supposed to deliver. Unclear scope means unclear expectations. And that nearly always leads to confusion, dissatisfaction and conflict on the team.
So take the time to actually define what is in and out of scope – that’s what this process is all about.
Define Scope Process
This is the third process in the Knowledge Area. We are still in the Planning process group.
Inputs
The inputs have changed slightly from the Fifth Edition, but it doesn’t feel major. The inputs to this process are:
- Project management plan – instead of the scope management plan.
- Project charter – which was there before.
- Project documents – again we see the generic terminology that can basically include anything about the project. In this case, we’re talking really about the assumptions log, requirements documentation and the risk registers, as there can be useful things included in there that need to be transferred to the project scope.
- Enterprise environmental factors – this wasn’t there before and covers things like infrastructure that might affect what systems you can install, marketplace conditions, staffing and culture.
- Organisational process assets – this was previously on the list so is not a change. It refers to items like historical information and lessons learned that could shape the scope, along with any internal relevant policies and procedures.
The objective of this process is to create the scope statement. You are trying to take the requirements from the previous process, prioritise and review them and make a final list of what you will actually be delivering as part of this process.
It is different from the Collect Requirements process because you may have collected requirements that you cannot deliver (or choose not to deliver) in this phase. The work that you are currently doing may not extend to all the requirements that were discussed and documented. You may have to prioritise what you can deliver.
It’s the final list of requirements, plus anything else that needs to be considered and included, that ends up as your scope statement.
Tools & Techniques
Not much has changed with tools and techniques. We have:
- Expert judgment
- Data analysis
- Decision making
- Interpersonal and team skills
- Product analysis.
Alternatives generation and facilitated workshops have dropped off the list. However, interpersonal and team skills is pretty broad and would cover running a workshop, or any kind of meeting.
Data analysis is also a broader technique than what was there before. Alternatives generation is one way of analysing data, but not the only the option. We’re seeing throughout this refresh that the terminology, tools and techniques have got broader to allow for more tailoring and personalising. I’m of the opinion that’s a good thing.
Outputs
There are no new or changed outputs to this process.
We still have the project scope statement and the project document updates.
The objective at the end of the process is to have a statement of scope. It should include what’s in scope, what’s specifically excluded from scope, and anything else you feel the need to document to ensure everyone is on the same page about what is going to be delivered.
Scope statements come in various formats, and while you’ll be able to find templates, and may even have one from your PMO, feel free to tweak and amend the document so it suits the needs of your project.
Aim for your scope statement to be really detailed, so that people can’t misinterpret what is going to be delivered. Think about what users, processes, tools, technologies, policies and so on are going to be impacted or changed as a result – and which ones won’t.
You can also include items for the scope of future phases (useful so they don’t get forgotten). However, these should be reviewed and revised at the point that the future phase is initiated, just in case the business has moved on and the scope items are no longer relevant.
Next time I’ll be looking at the fourth process in this Knowledge Area: Create WBS.
Pin for later reading:
Posted on: September 10, 2019 08:59 AM |
Permalink