Define Scope is one of the 47 process defined in the PMBOK Guide, Sixth Edition, by PMI. It belongs to the Scope Management knowledge area, and the Planning process group.
Define Scope is focused on getting a clear understanding of the project scope, and clarifying on what exactly will be delivered at the end of the project.
This process starts after the initial requirements from the Project Charter have been progressively elaborated and expanded, using the predecessor process, Collect Requirements, also from Scope Management knowledge area.
You must understand what happens before the Define Scope process in order to get a complete picture of the exact scope, inputs, tools and techniques and outputs of the process.
Collect Requirements Process:
In Collect Requirements, we communicate with the identified stakeholders, apply several techniques to gather their needs, wants, expectations, said and unsaid requirements and come up with a huge list of raw requirements. During the Collect Requirements process, we do not exclude any requirements for being too big, too small, too outlandish or too ridiculous. It is just like creating a laundry list of all requirements.
When you look at the long list of requirements, you may begin to feel overwhelmed. You may not have enough time, or money or even the resources to deliver so many requirements.
Do not panic or worry. It is not necessary that we will do all of these requirements. In Collect Requirements, we simply collect requirements. Period.
All collected requirements are written in the Requirements Documentation.
Once this is done, we are ready to move to the Define Scope process.
Define Scope Process:
Define Scope is concerned with selecting the requirements that will be part of the final deliverable. Once the requirements have been sifted through, the selected ones make it to the project scope statement.
The scope statement is not a one line statement. Do not confuse this with the English language meaning of statement, as a one liner…
Instead, it really means to state the objective, the scope of the project in greater detail. It should be more than one line…. more like 20-50 pages, and for larger projects, it is quite common to have the scope statement anywhere from 100 to 500 pages or more of the detailed scope statement.
How is the Scope Refined?
Define scope can be thought as a way to refine the scope. From the laundry list of all requirements, we sift and select the ones that are to be included and discard the ones that are not be included, for whatever reason.
One of the most common techniques is to call for meetings, ask the key stakeholders, along with the subject matter experts and evaluate the requirements based on their urgency, impact, need and usefulness for the project and its final product.
Mo: Must Have / Most Important / Critical
S: Should Have / Important
Co: Could Have / Nice to Have / Wish List
W: Won’t Have / Excluded / Discarded / Out of Scope
As you can see, MoSCow is really an abbreviation. You could use Critical, Important, Nice to have, and Won’t have as a way to include or exclude each requirement.
Output of Define Scope
In the end, you get a clear list of deliverables – what is included, and what is excluded. This is absolutely essential before you can move to the next processes of creating the WBS, estimating time, resources, cost, risk etc.
Clarity Is The Key!
Spend as much time to write down clearly about the selected requirements and the deliverable scope. Without clarity, there is room for scope creep.
The customer could easily add in things to the scope if the scope statement is vague, in the guise of:
- It is implied that this “extra” is actually part of the project.
- It is so obvious to me.
- I thought it is part of the scope.
- I assumed it meant that it was already included
- I presumed you would take care of this.
- We don’t have to spell it out in so much detail. We thought you guys were experienced enough to understand it!
Therefore, when we write about what is included, we take extra care to write about what is excluded. The more you write under the Project Exclusions clause, the more clarity you provide to the “what is included”. Without the Exclusions, the scope can be ambiguous and subject to different ways of interpretation.
I can’t stress how important this step is. I have seen countless projects suffer because the scope was not clearly defined. And it becomes the major cause of missed deadlines, over budget and poor quality of the delivered product.
That’s it. With a clearly defined scope, you are now ready to take on the next step – Create WBS, also from the Scope Management knowledge area. Together with the output of the Create WBS, we get the Required Componets of the Scope Baseline.
Scope Management For the PMP Exam
There are several questions on the PMP Exam, related to Scope:
- Who defines the Scope?
- What are the components of Scope Baseline?
- Output of Collect Requirements?
- Output of Define Scope
- Output of Create WBS
- What happens during Control Scope?
- What in the input to Validate Scope?
- What is the output of Validate Scope?
- What’s the relationship between Control Quality and Validate Scope?
- What is the purpose of Define Scope?
- What is the correct order of the Scope planning processes?
Make sure you understand and can answer these questions. Scope management is generally easier than Time and Cost Management, as there are no formulas to memorize, and no calculation questions. Just some basic, common sense theory of managing scope from the beginning of the project to the project closure.
If you do not know all the answers to the Scope Management questions above, you can join the Online PMP Training at PMCHAMP.com, and prepare properly for the PMP exam. We have 7 Detailed videos on Scope Management alone.
Hope you enjoyed this article. You could post a comment below and let me know 😀 I read each and every comment and reply personally.