Control Project Scope

00:01 This module looks at the control scope process from the PMBOK guide.

00:07 It has a very high exam importance, because controlling the scope and understanding if there's a variance between what you plan to do and what you're actually doing is a key component of successful project management.

00:20 Both the difficulty and memorization are regarded as low because you probably do this in your current jobs.

00:30 The control scope process is part of the project scope management knowledge area. It is one of two monitoring and controlling processes in that knowledge area. The other being the validate scope process, where we take a look at those verified deliverables, present them to the customer and see if they've become accepted deliverables. The control scope process, on the other hand, takes a look at what we think we should be doing with our scope represented by a scope baseline and take a look at what's actually happening and looking for variance between what we planned and what's actually happening.

01:08 The domain task.

01:09 This process helps us understand better is the monitoring controlling domain task one, which says measure project performance using appropriate tools and techniques in order to identify and quantify any variances and corrective actions.

01:30 The key themes of the control scope process are.

01:33 We're going to use the scope baseline and we're going to compare that to what's actually going on with the project scope.

01:41 Remember our scope baseline as our description of what we expect to happen and then we go on and do some work to reduce the scope and we compare what we're actually doing against what we plan to do.

01:54 And if variance between those two things is detected, then we must look to realign them at all times in a project.

02:02 What you plan to do and what you're actually doing must match.

02:06 And when this case, if we detect variance between those two, we would process a change request and submit it through our Perform Integrated Change Control process to decide whether we accept it or not.

02:20 The key inputs that we would go looking for.

02:22 To help us control the scope are the project management plan and all of its subsidiary plans.

02:29 The parts of the project management plan that we would find most useful for controlling the scope would be the scope management plan because it would set out what we expect to happen when we come to control the scope and the way in which we are going to control the scope.

02:44 Another part of the project management plan that we may find useful or that would be our scope baseline.

02:50 Also, the change management plan as well.

02:54 Even our requirements management plan may be useful here.

02:57 So those are the elements of the project management plan that we would probably find most useful as inputs into the control scope process.

03:05 Another input that we may find useful is the requirements documentation.

03:10 This outlines all of the requirements that we expect to get and deliver on our project the Requirements Traceability Matrix, which just gives us additional information about the requirements and how they can be met back to business objectives.

03:24 We want some raw work performance data about what's actually going on and that way we can control it.

03:31 And there may be some useful organizational process assets, such as our project management methodology to help us out controlling the scope.

03:41 The single tool and technique that we're going to use is simply called variance analysis.

03:48 And variance analysis is simply looking for a difference between what we plan to do and what's actually happening.

03:57 So remember, what we plan to do is represented by our scope baseline and remember our scope baseline is composed of three elements the scope statement, the work breakdown structure and the work breakdown structure dictionary.

04:13 So those three elements together represent our scope baseline or what we plan to do in terms of scope on this project.

04:21 Now we're going to take a look at what's actually happening with the scope.

04:25 What are we actually delivering with the scope now? If they're not equal, that's called variance.

04:32 And a key component of project management is to ensure at all times in your project that what you plan to do and what's actually occurring are equal.

04:42 If they're not equal and you do detective variance, you must act.

04:45 You must change either what you plan to do or what's actually happening, usually through raising a change request and considering it through your appropriate change control process.

05:00 Watch out for scope creep.

05:02 One of the key reasons we undertake the control scope process is to manage scope creep.

05:09 Now, in my opinion, scope creep happens because we're all really nice people.

05:14 Scope creep is those undocumented small changes.

05:19 What happens is somebody asks us for very small change on the project and we just simply think, Well, there's no problems with that and we simply approve it verbally.

05:28 The key thing is we don't write it down.

05:31 Scope creep is about documented scope change.

05:35 Whatever happens, all changes to the scope must be documented.

05:41 Some of them will have to go through a formal change control process involving the Change Control Board.

05:46 Others can be approved by your project team or even approved by the project manager, depending on the level of delegated authority that the project manager has.

05:54 But remember, at all times on the project, you must be delivering only what is documented for your project and product scope.

06:02 So don't let scope creep occur.

06:05 Change is going to occur, that's for certain.

06:08 It's how you manage change, which is important.

06:11 So this means you should consider all changes no matter how small or large, and if the change is accepted.

06:17 You document this and incorporate this into your scope statement, thereby stopping scope creep.

06:25 The flip side, the scope creep is gold-plating.

06:29 Now, gold plating occurs when you see the opportunity to deliver greater quality for less cost and in less time to the client and decide to proceed without documenting it.

06:41 So once again, the key thing is not that change is occurring and that it's small change. The key thing is proceeding without documenting it.

06:50 So just like scope creep.

06:53 Make sure you take time to document it.

06:55 Put it into your change register because there is nothing wrong with seeking to deliver better quality and exceeding customer expectations.

07:04 But once again, and I emphasize this at all times, you must only be producing what is documented on your project.

07:13 So with both scope creep and gold plating.

07:17 Document the changes.

07:21 If you do all of this with the control scope, the types of outputs that you may produce include relevant and important work performance information about how well you are meeting your scope baseline and if you do detect variance between your scope baseline and what is actually going on, you may raise a change request, which of course goes on to be an input into the perform integrated change control process as a result of controlling the scope.

07:49 You may also choose to make some updates to your project management plan in terms of how it instructs you to do these things if they weren't relevant.

07:57 You may also choose to update project documents and relevant organizational processes such things like your project management methodology.

08:08 Now, as part of controlling the scope, you may come into dispute with the customer about the scope, and it's important to understand what happens when you do get disputes. Disputes can be one of the most challenging concepts of scope control.

08:25 The customer thinks they wanted one thing.

08:27 You think they wanted another thing? Often it's a symptom of poor scope definition, particularly not accurately defining the exclusions of the scope.

08:37 So remember, for the purposes of the exam, if you come into a dispute about what is in the scope and what's not in the scope, the customer is not always right. So this is a little bit different from if you work in the retail industry where the customer is always right.

08:55 The contract is right, but all other things being equal, disputes should be resolved in favor of the customer.

09:02 So remember that if you get a question in the exam which indicates you're in dispute with the customer first and foremost, if you have a well defined scope, that is what's right.

09:14 But if there is some ambiguity in the scope because of poor requirements, gathering scope definition, then all other things being equal.

09:21 Resolve the dispute in favour of the customer.

09:28 The scope baseline, remember that if you do find changes that need to be made to your scope baseline that they will create a new baseline, remember that any baseline, whether it's the scope, the cost or the time baseline means the original approved baseline, plus all approved changes to that baseline.

09:50 So if we do find variance with our scope baseline and we change it, the new baseline is created and that's what we measure our performance upon going forward in the project.

10:01 So in summary, the control scope process is where we compare the actual scope work to the scope baseline and we look for variance between the two. If variance is detected, then we act to change either what we plan to do or what we're actually doing.

10:19 And finally, watch out for scope creep.

10:23 Make sure that whether it's scope creep or gold-plating at all times on the project, you're documenting all of the changes and only delivering what is documented. This has been an overview of the control scope process from the PMBOK guide.