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.
The inputs have changed slightly from the Fifth Edition, but it doesn’t feel major. The inputs to this process are:
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:
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.
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:
It’s time for part 2 of our journey through the Scope Management Knowledge Area from the PMBOK Guide®-- Sixth Edition. Today, it’s the turn of the Collect Requirements process. This process happens early in the project so that everyone has clarity on what the project is supposed to deliver. It also has the output of the requirements traceability matrix, which, if you are working on a project with many requirements and moving parts, is really helpful.
I’ve only used the matrix properly on one project – much of what I do doesn’t require a full traceability matrix. So don’t feel you have to use one if it will not make your life easier and add value to the whole process.
Collect Requirements Process
This is the second process in the Knowledge Area. The term ‘collect’ doesn’t sit very well with me. I know, from talking to business analyst friends, that the language has moved towards ‘eliciting’ requirements.
Requirements aren’t simply lying around waiting to be collected. There needs to be some active involvement in finding them, understanding them and collating them into a format and structure that can be used by the project team. You could argue that elicitation is only part of this process, but personally, I prefer to talk in the round about eliciting requirements.
The inputs have changed from the Fifth Edition, but not substantively. The inputs to this process are:
The objective of this process is to create the requirements documentation – in other words, to arrive at a position whereby everyone has a clear understanding of the agreed project scope.
Tools & Techniques
While the list of tools and techniques looks quite different, I don’t think they are substantively different.
The new tools and techniques for the Sixth Edition are:
Tools that have dropped off the list include:
You can see why I think the lists are different, and yet… not really that different.
These are all things you can do to elicit requirements and gain consensus on what really should be in the scope of the project. You wouldn’t want to use them all, but you would pick and choose different tools and techniques to ensure you were making progress towards getting that final list.
There is nothing new in the outputs to this process.
At the end of working through this process, you’ll have the requirements documentation and the requirements traceability matrix prepared and written (and approved). There’s nothing formal that defines what format your requirements documentation should be in. I tend to use work package description documents, product breakdown structure documentation, and sometimes simply a list of bullet points. You could use user stories.
Your requirements paperwork can be as detailed and formal as you like. Do what’s required based on the level of commitment you seek to get and the need to be specific at this point in the project. Trends and tailoring is something we’ll come to at the end of this process, but remember it applies the whole way through – you can make the process as big or small, as simple or involved as you want to.
Next time I’ll be looking at the third process in this Knowledge Area: Define Scope.
Pin for later reading: