4squareviews

If a project scope keeps expanding without any adjustments to the other constraints such as the time, cost, and resources, you have a situation referred to as scope creep.   That is why you have this process called Control Scope.   Now, a change in the scope is probably inevitable, but the key here is to make sure that it is done in a controlled way that takes the other constraints into account.

The inputs you will need for this process are covered in this post.

5.6.1  Control Scope:  Inputs

5.6.1.1 Project Management Plan

Here are the components that may be needed as inputs to this process.

Remember that the project management plan consists of

a) 9 knowledge area management plans, (one plan for each of the knowledge areas besides Integration, which integrates all of them into the overall project management plan)

b) 3 subsidiary management plans

• for requirements, related to the Scope management knowledge area,
• for change, related to the Integration management knowledge area (this covers the contents of the changes)
• for configuration, also related to the Integration management knowledge area (this covers the structure of the changes, so that everybody is working off the same version of the project and/or product)

c) 4 baselines, covering the 3 major constraints of scope, schedule and cost, plus the performance measurement baseline, which uses earned value analysis to combine measures of all three of these constraints

PLUS

d) A description of the project life cycle (will it be split up into phases) and development approach (traditional or predictive, also known as waterfall, incremental/iterative, agile, or hybrid)

and a lot of project documents.

In the inputs for this process, we have examples from all of the first three categories of elements from the project management plan.    They can be divided into three groups, based on what question they answer:

• “what’s the plan?”
• “is the project going according to the plan?” and
• “how can we get the project back to the plan?”

A.  What’s the plan?

Here are the elements of the project management plan related to the scope, which should give a measure of what the scope is according to plan.

• Scope management plan–remember that the scope management plan, developed in process 5.1 Plan Scope Management, contains guidelines on how to do all of the other processes of scope management, including this one 5.6 Control Scope.
• Requirements management plan–this shows specifically how the project requirements will be managed.
• Scope baseline–contains the project scope statement, the WBS and WBS dictionary.
• Requirements documentation (including the requirements traceability index)

Remember that the scope comes in three levels of detail:

• the requirements, which are set forth by the customer or sponsor of the project (located in the Project Charter at a higher level and then in the Requirements Documentation at a more detailed level)
• the deliverables, which are the products of the project which fulfill the requirements (located in the Project Scope Statement, a part of the Scope baseline) and
• the Work Breakdown Structure (or WBS) which breaks down the deliverables into manageable, “bite-size” chunks called “work packages”, accompanied by the WBS dictionary, which gives additional information on each work package (who it is to be done by, cost and time estimates, etc.).

B.   Is the project going according to the plan?

Okay, what if the monitoring process shows that the work is somehow NOT being done according to plan?   For that you need the following:

• Performance measurement baseline:   the three major constraints on a project are scope, schedule and cost.   Earned value analysis combines measures of each of these constraints to get a measurement of the overall performance of the project.  (Details about earned value analysis are contained in chapter 7 on Cost Management.)    The important point here is that earned value analysis tells you whether you are ahead of schedule or behind schedule, and whether you are within your budget or exceeding your budget.

Based on the answer to question B, you may find that the project is NOT going to plan, and so you now have to go to question C:

C.   How can we get the project back to the plan?

This is where change requests come in.   For the guidelines on how to handle these, you need the following:

• Change management plan (one of the three subsidiary management plans)–shows how to handle the change control process.   Will it be done by the project team as a whole?   Will it be done by a special Change Control Board?   If so, who will be on the Board, and how will decisions be reached?
• Configuration management plan (if there is a change request that is accepted, how will the documents related to the project be designated so that everybody is working on the current version of the project and not an earlier version)
• Lessons learned register (lessons learned earlier on in the project with regard to change requests may help the process go more smoothly as the project progresses)

5.6.1.3 Work Performance Data

The actual work done on the scope of the project in the last reporting period goes into the work performance data.   This is important because the tools and techniques in this process will compare the work planned to be done to the actual work done.   Data on the number of change requests received, and the number of requests accepted can be obtained from the change log.

5.6.1.4 Organizational Process Assets

The OPAs that can influence this process include:

• Templates and reporting methods to be used for monitoring the scope

• Existing  policies, procedures, and guidelines to control the scope

All of these should be included in the Scope Management Plan.

The next post will deal with the tools/techniques used in this process–the main one is change requests, to bring a project back to the plan (or if necessary, to change the plan to be more realistic).

 

Filed under: Uncategorized |