Table of Contents

Scope Management

This is more usually referred to as Change Control. Changes to specification or scope can potentially ruin any project unless they are carefully controlled. Change is, however, unavoidable. The control of change means the assessment of the impact of potential changes, their importance, their cost and a decision by the project management on whether to include them or not. Any approved changes must be reflected in any necessary corresponding change to schedule and budget.

Change Control steps

A change can be initiated by;

What ever its type, every request needs to be logged, allocated a unique number and capture essential details such as originator, date etc. Where possible, an indication of the changes priority should be recorded such as:

Every change should go through the 3 basic steps of a change management process:

1. The client defines the business value of the change.

2. The project manager (or project team) determines the impact to the project. An impact analysis is carried out to identify:

The priority should be re-evaluated after the impact analysis.

3. The project manager takes both the impact and the benefit to the sponsor for resolution.

The change is then authorised, deferred or rejected. The Project Manager decides which Requests For Change, if any, should be implemented within the current Stage Plan constraints. Even for those which the Project Manager is prepared to implement without extra funds or time, there should be discussion with the key Stakeholders. This is particularly important in circumstances involving an external Supplier. Without the approval of the Project Board, the Project Manager should not authorise any work which would change a product which has already been approved by the Project Board.

Where the Project Manager does not wish to personally take the decision on whether or not to implement the changes, the relevant Request for Change are passed to the key Stakeholders. They can decide to accept, reject the change. The Request for Change should be updated to reflect any decisions made.

Factors that affect scope change

Effort. The first place to look is whether there will be more effort required as a result of the change. Almost all scope change requests result in more effort, unless the change actually implies a reduction of features and functions.

Cost. The scope change request may require additional labor and/or non-labor costs. In many organizations, the internal employees do not have an hourly chargeback to the client so there is no additional cost (from an accounting standpoint) unless the work is done by contract resources. There may also be non-labor charges. For instance, you may have to buy additional hardware as a result of a scope change.

Duration. It is an over-generalization to say that all scope changes result in a longer project. The question to ask is whether the additional effort for the scope change is in the critical path. If it is, the project may indeed take longer. If the change is off the critical path, it may take more effort but it may not effect the overall project duration.

Focus / morale. Some scope changes result in more than additional effort, cost, and duration. They can result in the team losing focus or experiencing decreased morale. This is especially true if the changes come late in the project or if there are many, many changes that result in project drift.

Deferred benefits A project will result in a benefit to the company. The benefit usually starts immediately after (or soon after) the solution is implemented. If a scope change request results in the project being delayed, the impact of the scope change should also include the cost of the delayed benefit.

Look at the following example. Let's say your project will result in a business benefit of $5,000 per month in increased revenue. As the project is progressing, the client makes a change request that will cost $5,000 and add one more month to the project. The change has an estimated payback value of $500 per month.

You could go to the sponsor with a change request that states that there is a $5,000 cost, a one month project delay, and an estimated benefit of $500 per month. The sponsor might reason that the change will pay for itself in 10 months.

However, the part that is missing is the deferred benefit cost associated with implementing one month late. In this case, implementing one month later than planned also costs the company $5,000 in lost revenue, making the total cost of the scope change request $10,000, and requiring 20 months to receive a payback. The sponsor may still approve the change. However, taking into account the deferred benefit associated with a project delay should be a part of the scope change impact estimate for the sponsor to evaluate.

Hints and tips

Evaluating the impact of potential changes can be erroneously taken to mean only the impact on the Customer. Impact analysis must cover the three areas of Business, User and Supplier. The impact on the Supplier must be known, eg the cost and effort required, and what products would have to be changed.

Where the project is partially or fully funded by the Supplier, this may change the decision-making authority within the Project Board about changes. It may become more of a joint decision based on the contract terms or including contract modification.

Where the project is part of a programme, is the project in a position to judge the impact on other projects? Does it have the authority to make decisions? There are two potential approaches:

Where a change budget is given to a project manager, the project sponsor may wish to put a limit on (a) the cost of any single change and (b) the amount spent on any change in any one Stage - without reference to the Project Board.

25 January 2009 (10)