Scope Change Control

This topic has already been discussed at length in Chapter 4, "Execution and Control." The parts of scope change control that are listed in PMBOK are: "a) influencing the factors that create scope changes to ensure that changes are agreed upon, b) determining that a scope change has occurred, and c) controlling the impact of the actual changes when and if they occur." A large part of getting agreement on scope changes is implementing a scope change control system to which all stakeholders agree and will adhere during the execution of the project.

To determine that a scope change has occurred, you must have done careful planning, and you must have documents that are agreed upon in scope verification. If this has happened, you should have a rather easy time of determining that a scope change has occurred. If the documents are sloppy or nonexistent, there is a good chance that you will go through a lot of scope change without having much control over what is being done. Planning well and documenting the plan is a key to good scope control.

Finally, the project manager must manage the changes that are finally accepted. Keeping track of the changes and managing them throughout the project should be the job of every professional project manager. Again, it starts with documentation and planning.

Q.	The tool that defines the procedures by which project scope may be changed is ________.
		A.	The project plan
		B.	Scope change control
		C.	WBS
		D.	Scope methodology

The answer is B. This procedure defines how project scope can be changed.

Q.	The process that includes managing the actual changes if and when they occur is known as:
		A.	The project plan
		B.	Scope change control
		C.	WBS
		D.	Scope methodology

The answer here is also B. Both the tool within the process and the process itself are called the same thing according to the PMBOK.

The inputs to scope change control are: WBS, WBS dictionary, an updated scope baseline, change requests, recommended corrective action, updated organizational process assets, and an updated project management plan. All of these have been mentioned several times. The key to thinking about these various inputs is that all of them give you a baseline from which to work.

The changing of scope in a project always affects the time and cost and may also affect the quality of the final product or service of the project. If the project scope is enlarged, it is almost certain to add cost and often time. There are certain types of projects, for instance in construction, where it is possible to add costs by adding more shifts of crews and getting a better timeline. In these types, cost is traded for time. In IT projects, it is often impossible to trade cost for time because getting fifteen coders doing the same thing as three coders does not give a five-fold return on investment. Actually, having too many people work on a particular set of tasks in a project is as problematical as not having enough to do the work.

The opposite of enlarging scope is called descoping. This can occur as you get nearer to a deadline that must be met. Y2K was an example of this. As the new year approached, many projects were descoped because of the deadline that was impossible to either ignore or miss. When you make the project smaller in scope, it does not guarantee that you will be able to hit deadlines any better than you had before descoping it. All changes in projects change the project timeline. Making a project smaller in scope is not necessarily the same as making it easier.

Q.	If you change the scope of a project to make the final output less than the original baseline, you have ________ the project.
		A.	Rewritten
		B.	Crashed
		C.	Truncated
		D.	Descoped

The answer is D. When you change the project plan by removing parts of the final deliverable, you have descoped the project.

The performance measurements that you use will measure variance between the original approved plan and the actual execution of that plan. These measurements will be your tool for scope control. Your job as a project manager is to decide what is causing the variances and to decide whether the variance is significant enough to warrant taking corrective action. One of the questions I am most often asked is, "How large a variation is actually significant?" One of the standard answers is that there can be a 10% tolerance in variation between execution and plan. However, I believe that you should look at all variations. It is difficult to give an exact answer to this question.

A final tool is additional planning or replanning. If you work on a complex project, there will almost always be some additional planning. If you are doing iterative processes, such as you would see in most IT projects, it is likely that you will have to do more than just one-time planning to construct the original plan. Additional planning is a way of life in project management. I have not met anyone who wrote out a complete project plan and managed it perfectly from the beginning to the end unless the project only took a day or two.

Q.	As a project manager, one of your jobs is to determine whether variances between the plan and the actual execution are large enough to take ________.
		A.	Extra time
		B.	Time off
		C.	Corrective action
		D.	A vacation

The answer is C. The project manager is the one who determines whether corrective action is taken. During the planning of the project, it is a good idea to get agreement on how much variance is acceptable. This is particularly true of the sponsor.

The outputs of scope change control are an updated project Scope Statement, the updated WBS, the updated WBS dictionary, the updated scope baseline, change requests, recommended corrective actions for the change requests, updates on organizational process assets, and updates to the project management plan. As you can see, except for the recommended corrective actions, all of these outputs are updates of topics covered before.