Define Scope

00:01 This module looks at the defined scope process from the PMBOK guide, the exam importance is very high, and this is because the project scope is obviously absolutely essential to successful project delivery.

00:15 And before we can deliver it, we've got to define it.

00:19 The difficulty is rated as medium, because there may be some things we introduce to you that you don't currently do in your normal scope, definition work and memorization is low.

00:30 There's not a lot of new concepts we're introducing in this module.

00:36 So scope management, the knowledge area contains the defined scope process, and it's one of the four Planning processes in this particular knowledge area. The others being the plan scope management process, which gives us our Scope Management Plan, the Click Requirements process, which gives us our requirement, documentation and requirements.

00:56 Traceability Matrix.

00:57 And once we've defined the scope, we can then go on to create our work breakdown structure. What gives us our work breakdown structure, or WBS and our WBS dictionary and ultimately our scope baseline? There are also two monitoring and controlling processes in the scope management knowledge area, and they are the validate scope process and also the control scope process.

01:23 The particular domain task that this process delivers is the planning task 2.

01:29 And this task also accounts for the development of the Scope Management Plan, collecting the requirements and the creation of the WBS.

01:37 And it says.

01:39 Develop a scope management plan based on the approved project scope and using scope management techniques in order to define, maintain and manage the scope of the project.

01:52 The key themes of this process are we take the approved requirements that the documentation that we've already gathered in the collect requirements process, and we build on those to develop the approved project scope statement. But it's also very careful that we differentiate between product scope and project scope.

02:14 The product scope relates to a description of the product that we're delivering or the service in the project, whereas the project scope has all the additional work we have to deliver all the communications work, the risk management work, the quality management work, the team development work, that's all part of the project scope.

02:32 And my experience has been that many project managers are very good at defining the product scope, but not quite so good at defining the project scope.

02:41 And remember, if we don't define it in our scope, we can't communicate it to stakeholders. We can't allocate time and cost and resources to it.

02:51 So it's very important for the purposes of the exam that you understand that you will define the entire project scope, which includes the product scope.

03:01 The inputs that we may go looking for in order to help us define the scope.

03:06 Well, first and foremost, it's going to be our scope management plan because that's going to provide the guidance on how we do scope definition.

03:15 So we need we need that, and that, of course, is a subsidiary from our project management plan. And the scope management plan is an output from the plan, scope management process.

03:27 We may also want our project charter, because as we define our project scope, we may look to the project Charter for the preliminary information it contains about the project scope that was known at the time of project initiation.

03:44 Now, if our project charter was a summary project charter, it may only contain a high level project statement of work description.

03:53 But some product charters are very, very, very detailed, and it may contain an exhaustive description of the project scope.

04:01 So that's why the project charter may be very useful to us in this process.

04:06 Will also want the requirements documentation, which is an output from the collect requirements process, because this lists all of the requirements that we're agreed to deliver and we have to turn those requirements into our product and our project scope.

04:22 We may also go looking for useful and relevant organizational process assets, things like our project management methodology and blank scope statements as well. Once we have these inputs, then we may choose to use, if appropriate, the following tools and techniques to help us define the scope. The first is expert judgment.

04:46 Remember that you are an expert, your project team are experts about the people doing the work, so they should always be consulted about defining the scope.

04:55 The client is probably one of the more important experts to consult with during this period, because that's who you're delivering the product for.

05:03 And of course, they will want to have some input into defining the scope.

05:07 You may also choose to do some product analysis.

05:10 Now, this is particularly important where your project is delivering a product rather than a service or result.

05:18 And product analysis is the technique of taking the overall product and breaking it down into its component parts and analyzing each of these component parts to make sure that you've properly accounted for the entire product scope. You may also choose to use alternatives generation. This is the great technique for recognizing that there are many ways to deliver the same product or the same outcome.

05:46 So don't be afraid to look at different ways, different alternatives to deliver the same project or product scope.

05:55 You may choose to use facilitated workshops where you bring together those stakeholders with information about the scope and get that information out of them and document it, and that becomes part of your scope.

06:09 You may also choose to use facilitated workshops to feed back information to the stakeholders about early iterations of the project scope to get their feedback. Ask them Are we on the right track with defining the scope? What else do we need to do? What have we missed? And that's the value of facilitated workshops.

06:30 So remember, product analysis is where you break the product down into its component parts and look at those individually alternatives generation as that technique where you identify all of the possible and potential ways to build or deliver any part of the project scope.

06:49 As a result of doing this work and applying those particular tools and techniques to those particular inputs, you will develop a project scope statement. Even though I may have described it in a discreet and linear fashion, it's not defining the project scope statement is a highly iterative process. It involves having an early first scope statement and taking that back to project stakeholders and looking for their feedback.

07:17 Have you got it right? But at the end of the day, we want a complete project scope statement.

07:22 We may also choose to have some project document updates, feedback, the information about the scope back into our requirements or to our scope management plan or any other part of our project management methodology relating to the definition of scope.

07:39 Now, I've already mentioned it, but it's worth emphasizing this when it comes to defining the product and project scope in the exam, read the question very carefully.

07:52 Sometimes you'll think the words is project scope when it says product scope.

07:57 It's also a tip here.

07:59 If you see the word project life cycle and product life cycle, just make sure in the exam you read those two terms correctly.

08:06 So you understand where the question is talking about the project lifecycle or the product life cycle.

08:11 Here, though, we can see that the product scope is a subset of the overall project scope.

08:18 Now, the product scope relates to the technical specifications and the requirements of the product service or result that our project is delivering.

08:27 The project scope, though, includes all of that other work that we're going to do on the project. All of the communications work, all of the risk management work, the quality management work, the change control work, the closure work, all of that work must be included in our project scope.

08:44 Now the client is most most likely interested in the product scope, and you may actually have to see different scope statements, a product scope statement and a project scope statement.

08:56 But the key thing here is when it comes to producing time and cost estimates, we're going to use our WBS to do that at WBS reflects our project scope statement.

09:08 So if we don't include the work in our project scope statement, it won't make its way into our work breakdown structure if it doesn't make its way into our work breakdown structure.

09:18 We can't allocate cost or time to it.

09:22 And the other little tip that I have is if you do take the time to include all of that extra work into your project scope statement, it's a great way to communicate with stakeholders.

09:33 All the work that you're doing on the project, not just the product based work.

09:38 Here are some terms that you're going to come across in the exam.

09:43 That different ways of describing different iterations of the project scope.

09:48 Now, keep in mind for the for the exam.

09:52 One terminology is used throughout the entire exam, and this may be different from the terminology you use in your day to day job.

10:02 Now remember that the PMBOK guide says very clearly whatever words you use.

10:07 Keep using them.

10:08 But on the day of the exam, you have to use these terms.

10:12 So let's go through them to make sure we all understand what we're talking about.

10:17 The first one is the project statement of work.

10:21 This is a high level description.

10:25 Of the work to be done, it has very low level of detail in it, though.

10:30 We will use the statement of work that high level narrative description of the work to be done to help us develop our project charter.

10:39 And the project Chat or is the next iteration of this, and it contains a little more information than the statement of work, and we can then use our Project Charter to go out and collect our project requirements and we produce our requirements, documentation and our requirements.

10:55 Traceability Matrix.

10:58 Once we have those, we may issue a preliminary scope statement.

11:04 We may offer this up to the stakeholders for their feedback and comment, and they may give us some feedback, which means we have to go back and redo collecting requirements in order to get a better scope statement.

11:16 So this process is highly iterative as well.

11:20 Once we've got a preliminary scope statement agreed, we can then turn that into a scope statement. But once again, it's completely normal to take this particular scope statement back to our stakeholders and check with them.

11:34 They may want some changes, and we may take it back to preliminary scope statement level so we can see that it's highly iterative throughout the whole process and the final and most complete description of all, the work to be done on the project is the work breakdown structure.

11:50 As we'll see in a following module, the work breakdown structure is often referred to as the backbone of the project.

11:57 Without it, we can't do good time and cost estimates.

12:01 And that's why we need it.

12:03 But as you can see, we can't develop a work breakdown structure if we don't have a scope statement.

12:10 We can't have a scope statement if we don't have a preliminary scope statement.

12:13 We can't have a preliminary scope statement.

12:15 We don't have requirements.

12:16 We can't have requirements.

12:18 If we don't have a project charter and we can't have a project Chat if we don't have a preliminary statement of work.

12:24 So look out for those terms in the exam and knowing what each one is will help you understand the scenario that's being presented in the exam question.

12:37 So in summary, the defined scope process, it uses the scope management plan to guide the definition, the collection, the documentation, the feedback and the iterations of the entire project scope. And remember, the entire project scope also includes the product scope is an important subset of it.

13:00 The defined scope process builds on the work already done and the collect requirements, process and requirements that are gathered to continue the iterative definition of the project scope.

13:14 So this has been the defined scope process from the PMBOK guide.