4 CHANGE CONTROL AND MANAGEMENT

LEARNING OUTCOMES

When you have completed this chapter you should be able to demonstrate an understanding of the following:

4.1 INTRODUCTION

Change management is a major concern to organisations: business changes have many implications outside the narrow confines of IT development, including their impact on staffing levels and on the skills and responsibilities required of employees. The particular focus in this chapter, however, is on the many events during a project that result in alterations to the planned work. The project manager’s skill lies in controlling those changes so that minimal disruption is caused to the planned objectives of time, cost and quality. Change management ensures modifications to any aspect of the project are only accepted after a formal review of their impact upon the project as a whole.

The procedures for managing change should be established at the beginning of the project. Organisations which have kept responsibility for the maintenance of IT systems rather than outsourcing this will need some way to keep track of changes to their systems as they evolve over time in response to user and business needs. The Canal Dreams ebooking enhancement project will create new software components, change some existing software components and expand IT infrastructure: the effect of this on existing systems needs to be tracked. As well as the changes to the existing system, the planned functionality to be implemented in the ebooking enhancement may be modified during the project as the needs of the users and the business are clarified. A change control system needs to be devised and implemented, especially if outside contractors are writing the software.

Allowances need to be made within the project plans for the possibility of additional work caused by requested changes. These allowances could be part of the tolerances delegated to the project manager (see Chapter 3). The project manager needs to ensure that the effect of any change on the plan does not exceed these allowances. Where the allowance for changes is exceeded, a new project plan (the exception plan mentioned in Section 3.6) would need to be drafted and approved by the steering committee or project board.

Change management, at some level, should be applied to all changes, whether they arise from a change to user requirements or are due to design modifications. It requires participation by the users and the developers, guided by the project manager. The user must decide whether a change is essential, desirable or optional. The project manager must identify the cost, time and quality impact, and assess the feasibility of the change. Once account has been taken of users’ and developers’ advice, if it is decided to go ahead with the change, it is the responsibility of the project manager to implement the change.

4.2 DEFINITION OF CHANGE

In Chapters 2 and 3, we introduced the idea of the project as a sequence of activities, each of which take certain inputs and use them to produce outputs. The outputs from one process may be inputs to other processes. For example, a specification could be an input to a process that creates a system design (that is, the format of the user interfaces with the system) which will then be implemented as code. During the process, the proposed interface designs may change rapidly as the designers try out different designs and the users give feedback on them. This does not need a formal change process. At some point, however, a decision needs to be taken that the design is now in a satisfactory state to be used as a basis for constructing the system. At this point the design will need to be frozen; in other words, the design is baselined. If changes are made to the application after it has been baselined, then rigorous change control is needed because of the potential impact on subsequent phases.

The idea of baselines was introduced in Chapter 3 with regard to project plans. A baselined plan may be regarded as an agreed plan against which variations will be measured. Any change can also be seen as a potential change to a baselined plan. For projects, the baselines include:

As noted in Chapter 3, these will tend to be interdependent. For example, if the scope of the work is expanded, then the cost will also have to be increased. Cost or scheduled duration could be reduced by decreasing the functionality in the IT application that is to be delivered.

Variations on these baselines can be categorised as follows:

Some discretion will be exercised in accepting or rejecting scope and development changes but changes due to design errors will normally be obligatory, since the system may not work satisfactorily unless they are corrected.

4.3 CHANGE MANAGEMENT ROLES AND RESPONSIBILITIES

It is important to clarify the various roles and responsibilities within change management. We are going to use a very specific set of terms here to identify and explain the various roles and responsibilities. In a real project environment, it is very unlikely that these precise terms will be used. However, there should be people who carry out the following roles, whatever they may be called.

4.4 THE CHANGE MANAGEMENT PROCESS

We have already outlined some of the processes involved in implementing a change:

It is likely that there will be a change register which is used to track the progress of an RFC through the change management process.

4.4.1 Submit request for change

In the Canal Dreams ebooking enhancement project, the project manager has been allocated the role of change manager. The office manager of the current bookings call centre is selected to act as change requestor. Requests for change can come from anyone but are all passed to the change requestor, who, in consultation with colleagues, decides whether the requested change is desirable from the users’ point of view. If they decide that there is a genuine need, a request for a change is submitted to the change manager. The RFC provides a summary of the change required, including:

4.4.2 Review request for change

The change manager reviews the RFC and decides the nature and scope of the feasibility study/impact analysis required for the CCB to assess the full impact of the change. In the Canal Dreams ebooking enhancement project, one request was to add the sale of holiday insurance to the online booking system. On receiving the RFC, the change manager sees that it is difficult to assess the scope of the change as some of the details of the requirement are still unclear. The impact of the change on the existing design also needs to be carefully considered. The change manager opens an RFC entry in the change register and records that a feasibility study is required.

4.4.3 Assess feasibility of change

Once the change has been logged, an assessment must be made of its feasibility and impact upon the project in terms of time, cost and quality. For small changes, a team member may assess the impact of the change in a relatively informal manner. For major changes, the feasibility study could involve several people and last for some time. Different change options will be investigated and reported on. The change feasibility study will culminate in definition of the:

A quality review of the feasibility study is then performed in order to ensure that it has been conducted as requested and the final deliverable is approved, ready for release to the CCB. All change documentation is then collated by the change manager and submitted to the CCB for final review.

The feasibility study itself carries a cost and sometimes the project manager records these costs in the change register. These costs may well increase the budget. For external client projects, the feasibility study may be an additional service which has to be paid for by the customer.

In the Canal Dreams ebooking enhancement project, two staff are assigned to look at the requested change for a facility to purchase holiday insurance online. One is a business analyst who should understand the nature of the business and the other is an experienced developer who will be able to judge the technical impact of the requested change. After discussing the matter with the user representatives they find that the change requires two additional input fields on the booking screen, two additional data items on one of the tables in the database and some minor changes to some of the printed outputs from the system. They estimate that the changes will require three additional staff days of effort.

4.4.4 Approve request for change

A project may have a range of levels at which changes can be reviewed and approved:

Whatever the level of review, the change needs to be recorded and reported.

The CCB will do one of the following:

The CCB will need to take account of the overall profile of possible changes. A large number of minor changes could have an overall effect that is out of all proportion to their individual significance. Approved changes will necessitate revisions to the schedule and cost plan. The CCB should prioritise changes so that those which are essential are carried out first, while non-essential changes are delayed until they can be made with the least impact on work schedules.

In the Canal Dreams ebooking enhancement project, the holiday insurance change is only one of several changes that have been requested. The CCB has a budget of only 10 staff days left to allocate, but has requests that need a total of 15 days. The CCB may accept changes requiring up to six days’ effort, including the change to incorporate the holiday insurance requirements.

4.4.5 Implement request for change

This involves the complete implementation of the change, including any additional testing that may be required. On completion, the change will be signed off in the change register. Where the additional work has been carried out by an external supplier, additional invoices for the additional work will be raised by the supplier. Additional payments would not be made, however, where the change was to correct an error made by the supplier.

4.5 CONFIGURATION MANAGEMENT

The change control system described above is needed to ensure that an endless sequence of changes does not undermine the business case for the project – for example, by increasing costs so that they exceed the value of the benefits that the project will produce or by extending the time needed for development and implementation and thus reducing the benefits. Once a change has been agreed, there are further problems, such as ensuring that all documents and other products of the project are modified to reflect the change.

A project has a wealth of documents that relate to each phase of the project, along with software objects such as database structures and code segments. A very basic need is therefore for a central project repository or library where master copies of all documents and software objects are stored. Another basic requirement is that there should be a system of version numbers for all products so that successive baselines can be identified. These requirements mean that it is essential for one or more people involved in the project to take up a role variously called project or configuration librarian or configuration manager. Part of that role is to make sure that all project products are controlled, so that, for example, we can make sure that all software developers working on components that exchange information are working from the latest specifications for those components.

Configuration management has three major elements:

4.5.1 Configuration item identification

The items which will be subject to the configuration management system (CMS) need to be identified. Typically these are baselined specifications, design documents, software components, operational and support documentation, and key planning documents such as schedules and budgets. Other items, such as IT equipment, may also be subject to configuration management. These items will be defined as configuration items (CIs) and their details will be recorded in a configuration management database (CMDB). Among the details recorded in the CMDB for a configuration item are:

4.5.2 Configuration status accounting

After a change to a CI has been agreed, the project librarian sets the status of the CI accordingly. This process is called configuration status accounting and it maintains a continuous record of the status of the individual items which make up the system.

4.5.3 Configuration control

Configuration control ensures that due account is taken of the status of each CI. For example, when recording the change to add holiday insurance to the boat booking transaction, the configuration librarian may access the CMDB to see the current status of the software component. The librarian may find that the software component is already booked out to a software developer who is implementing a different approved change to the module. If the librarian were to release a copy of the baselined code to a second developer to add holiday insurance, that would create two different versions of the same software. The new change may be given to the developer already working on the component or there may need to be a delay while the first change is completed.

When a developer is happy that all the work associated with a change is complete, the new version of the software is passed to the librarian. The librarian then records the CI as having a new version number and as being ready for acceptance testing. Acceptance testing is usually carried out in a separate IT environment to operational processing. If the designated user representative approves the revised version of the system, a request can be made to the librarian to make the revised application operational. The former version of the software is retained in case there is a need to ‘fall back’ to it, if the new version turns out to be problematic.

SAMPLE QUESTIONS

1. The change control board should consist of:

(a) representatives of the key stakeholders in the project

(b) the project manager and team leader

(c) the people on the project board

(d) the project support office

2. If there are doubts about the projected costs of a proposed change, it would be the responsibility of which of the following to investigate?

(a) the change requestor

(b) the change manager

(c) the change feasibility group

(d) the change control board

3. As a documented procedure, what is the purpose of configuration management?

(a) to ensure the project remains within budget

(b) to identify and document functional characteristics of a system

(c) to record and report changes and their implementation status

(d) to verify conformance with requirements

ANSWERS TO SAMPLE QUESTIONS

1. (a) 2. (c) 3. (c)

POINTERS FOR ACTIVITIES