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 the sixth and final part of our look at the Scope Management Knowledge Area from the PMBOK® Guide-- Sixth Edition. We made it! Thanks for sticking with me to the end on this one. It’s a process with a lot of moving parts!
You can find the previous parts of this series here:
The Control Scope Process
As we’ve just seen, this is the final process in the Knowledge Area. We are still in the Monitoring and Controlling process group.
The point of this process is to manage changes to the scope baseline as you go through the project. The purpose is to ensure you’ve got clarity about what the project is going to deliver. You’ll do this process as you go, at various points through the project life cycle. Basically, whenever there is a possible change to scope. In fact, you might not need it at all, on a simple project where the scope doesn’t change.
That’s possible, but unlikely! I don’t think I’ve ever worked on a project where the scope at completion has been identical to the signed off scope as part of the Project Charter… but I’m sure it does happen.
You have to use this process in conjunction with the Perform Integrated Change Control process. This process ensures the changes and actions go through that process. Plus, Control Scope is also used to manage the changes once they’ve been approved, and because of that it’s got links to all the other Control processes.
Inputs
We’ve got the same changes to this process as we saw in Validate Scope. Basically that means requirements documentation and the traceability matrix is out, and the generic ‘project documents’ is in. Therefore, the inputs to this process are:
- Project management plan
- Project documents
- Work performance data (e.g. documentation about the number of changes received and processed – reporting your PMO might find useful about how the project is handling change, as the frequency and type of change can tell you quite a lot about the stakeholders and how the project is being managed)
- Organisational process assets.
In this context, project documents could include the lessons learned register (because at every point in the project you can learn from what’s gone on before), requirements documentation (obviously) and the traceability matrix.
Tools & Techniques
There was only Tool and Technique in the Fifth Edition: variance analysis.
That’s gone. And now we have the broader term, data analysis. Which includes, surprise surprise!, variance analysis. And also trend analysis which looks at project performance over time. If a project is getting more and more changes as it progresses, that can provide useful information about the quality of requirements or how under control the work actually is.
Outputs
There’s a tiny change to the outputs of this process.
The outputs are:
- Work performance information
- Change requests
- Project management plan updates
- Project document updates.
Organisational process assets has dropped off the list.
The thing with scope changes is that they affect so much. Anything that goes through change control can have a fundamental impact on the project so you’ll want to update all the records to make sure you’ve got accurate notes about what you’re now doing and why.
So you might update the scope management plan, the baseline, the schedule baseline and cost baseline. On top of that, you could be updating the lessons learned register, requirements documentation and that traceability matrix.
Frankly, it’s easier if the scope doesn’t change! But as it is almost guaranteed to change at some point, you need to be prepared to put the work in to update all the documentation and tell everyone what’s now going to be the new approved scope.
And that brings us to the end of this process, and our trip through the world of Scope Management.
Pin for later reading:
Posted on: December 04, 2019 12:33 PM |
Permalink