4 CHANGE CONTROL AND CONFIGURATION MANAGEMENT
LEARNING OUTCOMES
When you have completed this chapter you should be able to demonstrate an understanding of the following:
• the reasons for change control and configuration management;
• change control procedures:
▪ the role of the change control board;
▪ the generation, evaluation and authorisation of change requests;
• configuration management:
▪ purpose and procedures;
▪ the identification of configuration items;
▪ product baselines;
▪ the content and use of configuration management databases.
4.1 INTRODUCTION
Business changes have many implications outside the narrow confines of IT development, including their impact on an organisation’s staffing levels, skills and responsibilities. Change management is concerned with the smooth transition of the organisation to the new system that a project delivers. The Water Holiday Company integration project will create new software, change existing software and expand IT infrastructure. These are technical changes, but the integration project will also require changes to the way the merged business will be run.
The particular focus in this chapter, however, is on the events during a project that result in alterations to project requirements. 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 control ensures that modifications to any aspect of the project are only accepted after a formal review of their impact upon the project and its environment.
The procedures for managing change should be established at the beginning of the project. The planned functionality to be implemented may be modified during the project as the needs of the users and the business are clarified. These changes need to be tracked through a change control system. If outside contractors are carrying out some of the work, the need for a change control system is even greater.
New IT systems usually need to be integrated with existing operational systems, and this may require modifications to these legacy systems so that they can communicate with the new functionality created by the project. The changes to these existing systems need particular care to ensure existing operations are not degraded.
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 ensures that these allowances are not exceeded. Where they are exceeded, a new project plan (the exception plan mentioned in Section 3.6) would need to be drafted and approved by the project sponsors.
Change control, 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 users must judge whether a change is essential, desirable or optional. This decision takes account of the possible impact of the change as well as of not making it. The project manager must assess the technical feasibility of the change, and identify its impact on costs, time and quality. 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 takes certain inputs and uses them to produce outputs. The outputs from one process may be inputs to others. Thus, 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 for constructing the system. At this point, the design will need to be frozen; in other words, the design is baselined. If changes are needed to the design after it has been baselined, then rigorous change control is needed because of their potential impact on the processes that use the design.
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 to requirements could imply a potential change to the baselined plan. For projects, the baselines include the agreed scope and quality of work, schedule and costs.
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 be increased. Similarly, cost or scheduled duration could be reduced by decreasing the functionality delivered.
Variations on these baselines can be categorised as follows:
• Changes of scope: These generally originate outside the project, usually by the users, managers or project sponsors changing the requirements, or by the cost or time constraints of the project changing. In the case of the Water Holiday Company integration scenario, the users may, for example, add a requirement that when booking a boat online the client should also be able to purchase holiday insurance. On the other hand, a reduction in the project budget may mean that some planned system features are dropped.
• Development changes: These originate within the project and include changes which are routinely carried out as part of the normal process of developing and refining a product. Typically, this can be something as simple as an adjustment to a screen layout.
• Faults: This type of variation also originates within the project and is caused by the project team making errors. For example, misunderstood requirements in coding detected by system tests could lead to additional corrective work.
Some discretion will be exercised in accepting or rejecting scope and development changes but changes to correct design errors will normally be obligatory, since the system may not work satisfactorily unless they are corrected.
ACTIVITY 4.1
In order to encourage the UK boating holiday industry, the government decides that VAT on canal holiday bookings will be zero-rated with immediate effect. The management of the Water Holiday Company calculate that this could increase the demand for bookings by 30 per cent. At the same time, the government introduces a special tax on holiday insurance that has to be accounted for separately on invoices. When considering the implications of changes, the project team realise that although holiday insurance was included in the original requirement, it has been missed out from the system design. What effect might these changes have on the project?
4.3 CHANGE CONTROL ROLES AND RESPONSIBILITIES
It is important to clarify the various roles and responsibilities in change control. 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.
• The project manager oversees the process and ensures that all requests for change (RFCs) are handled appropriately. In most cases, the project manager also has the role of change manager.
Project managers must ensure that user representatives approve any changes made to the project requirements. They also control the scope of the system to be developed: additional features will require more effort and increase costs. When the project sponsor agrees to additional features, adjustments may need to be made to the project’s contractual price. The project manager also needs to be on the lookout for informal changes made outside the process. Informal changes are often discovered during project reviews and a retrospective RFC form may need to be completed so that records remain accurate.
• The change requestor recognises a need for a change to the project and formally communicates this requirement to the change manager by completing the RFC form.
• The change manager (who may be the project manager) is responsible for logging RFCs in the change register. They decide whether a feasibility study is required for the change. Where this is desirable, for example because the extent of the impact of the change is uncertain, one or more people will be assigned to carry out the study.
• The change feasibility group appointed above investigates the feasibility of a proposed change. It is responsible for researching how the change may be implemented, and assessing the costs, benefits and impact of each option. Its findings are documented in a feasibility study report.
• The change control board (CCB) decides whether to accept or reject the RFC forwarded by the change manager. The CCB is responsible for:
▪ reviewing all RFCs forwarded by the change manager;
▪ approving or rejecting each RFC based on its merits;
▪ resolving change conflict, where several changes overlap;
▪ resolving problems that may arise from any change;
▪ approving the change implementation timetable.
• A change implementation group carries out the change. It is usually made up of staff from the project team.
4.4 THE CHANGE CONTROL PROCESS
Having identified the roles and responsibilities involved in change control, we look at the processes in more detail.
4.4.1 Submit request for change
In the Water Holiday Company integration project, the project manager has been allocated the role of change manager. An experienced office manager of one of the current booking call centres 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 it is, the change requestor submits a RFC to the change manager. The RFC provides a summary of the change required, including:
• a description of the change needed;
• the reasons for change, including the business implications;
• the benefits of change;
• supporting documentation.
There will almost certainly be a standard form for the RFC.
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 Water Holiday Company integration project, one request was to add the sale of holiday insurance to the online booking system. The change manager saw that it was difficult to assess the scope of the change as exact details of the requirement were unclear. The impact of the change on the existing design also needed to be carefully considered. The change manager opened an RFC entry in the change register and recorded that a feasibility study was required.
4.4.3 Assess feasibility of change
The assessment of the feasibility of the RFC not only considers business and technical feasibility but also the impact upon the project in terms of time, cost and quality. For small changes, a team member might assess the change in a relatively informal manner. For major changes, several people could be involved for some time. Different change options will be investigated and reported on. The change feasibility study will culminate in definition of the:
• change requirements;
• change options;
• costs and benefits;
• risks and issues;
• change impact;
• recommendations and plan.
A quality review of the feasibility study is then performed in order to ensure that it has been conducted as requested and the final report 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 affect the project’s budget. For external client projects, the feasibility study may be an additional service which has to be paid for by the customer.
In the Water Holiday Company integration project, two staff were assigned to look at the RFC for a facility to purchase holiday insurance online. One was a business analyst, who focused on the business implications, and the other a developer, who considered the technical impact of the change. After discussing the matter with the user representatives, they found that the change required two additional input fields on the booking screen, two additional data items on one of the tables in the database and a link to a separate insurance products application. They estimated that the changes required 10 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:
• Team leaders may be allowed to accept changes that will not require additional resources, and which do not affect other baselined products.
• The project manager may be allowed to decide upon changes that have a minor impact on project objectives within a tolerance level which has been agreed with the steering committee or project board.
• The CCB decides upon changes that will have a larger impact upon project objectives, but are constrained by any limitations on the budget available for changes.
• Some changes may be particularly large but have compelling reasons for their adoption. These changes may need resources not envisaged in the original plans. In these cases, an exception report will need to be produced for consideration by the steering committee/project board – see Section 3.6.
Whatever the level of review, the change needs to be recorded and reported.
The CCB will do one of the following:
• reject the change;
• request more information related to the change;
• approve the change as requested;
• approve the change subject to specified conditions;
• put the change on hold;
• refer the change to the project sponsors if the current budget or project duration would be affected by the change.
The CCB takes account of the overall profile of possible changes. A large number of minor changes could have an overall effect out of all proportion to their individual significance. Approved changes will necessitate revisions to the schedule and cost plan. The CCB should prioritise essential changes, while non-essential changes may be delayed so that they make less impact on work schedules.
In the Water Holiday Company integration project, the holiday insurance change was only one of several RFCs. The CCB had a budget of only 30 staff days left to allocate, but had requests that needed a total of 35 days. The CCB accepted changes requiring up to 25 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. Where existing code is changed, regression and integration testing will be needed to ensure that existing functionalities will not be harmed (see Section 5.8). 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 that 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 above ensures that the business case for the project is not undermined by an endless sequence of changes – for example, by increasing costs beyond the value of the benefits of the project or by extending development time and thus delaying the benefits. Once a change has been agreed, there are further challenges, such as ensuring that all documents and other products of the project are modified to reflect the change.
ACTIVITY 4.2
What deliverables of a project may be affected by the change to the Water Holiday Company specification to allow for holiday insurance to be recorded when a customer books a boating holiday online?
A project has many documents relating to each phase of the project, along with software objects such as database structures and code segments. A very basic need is therefore a central project repository or library where master copies of all documents and software objects are stored. There should be a system of version numbers for all products so that successive baselines can be identified. These requirements make it essential for one or more people on the project team 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, all software developers working on components that exchange information work from the latest component specifications.
Configuration management has three major elements:
• configuration item identification;
• configuration status accounting;
• configuration control.
4.5.1 Configuration item identification
The items that 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:
• a CI reference number;
• its current status;
• its version number;
• any larger configurations of which it is a part;
• any components that it has;
• other products that it is derived from;
• other products that are derived from it.
Note that a configuration item could have components that are configuration items in their own right. A change to component CI is also a change to the larger entities to which it belongs. The larger entity may need to be re-assembled to allow the component change.
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. Configuration status accounting maintains a continuous record of the status of the individual items that make up the system. Key status settings might include ‘under development’, ‘released for test’ and ‘operational’.
4.5.3 Configuration control
This 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 in our Water Holiday Company example, 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. This will create a new baseline for the component, which can only be changed via change and configuration management processes described above. 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.
Where changes are made to currently operational functionality, current users would need to be made aware of the changes to their systems. Database structures may need modification, which affects the interactions with other system components. Where organisations have extensive user-facing websites that are being continuously updated with new features, they may adopt DevOps technologies that automate many of the technical implementation tasks, such as integration testing. These technologies do not diminish the need for managerial attention to ensuring the basic business value of changes is maintained.
SAMPLE QUESTIONS
1. The change control board should be made up of:
a. representatives of the key stakeholders in the project
b. the project manager and team leader
c. the project sponsors
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
POINTERS FOR ACTIVITIES
Activity 4.1
The changes may have the following effects on the project:
• The change to the rate of VAT should not involve changing the application, as there should already be a system function that allows VAT rates to be changed.
• The potential increase in bookings would not change the functional requirements, but would probably change the quality or ‘non-functional’ requirements; for example, the database would need to be able to hold more records. The equipment needed to run the application might need to be upgraded (this is a change to the scope of the project).
• The statutory change to accommodate holiday insurance tax could well mean changes to input screens and report layouts. This does not increase the scope of the specification which included this functionality, but will change the scope of the planned work. Not including functions to deal with the requirement for holiday insurance in the design is a straightforward fault and the project team should correct it.
Activity 4.2
Among the many deliverables that might be affected are:
• the interface design – screens and report layouts;
• software components;
• the database structure;
• test data and expected results;
• user manuals;
• training material.