The change control process is a very important activity in project management practices.
Having identified the roles and responsibilities involved in change control, we look at the processes in more detail. 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.
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 a Request for change (RFC) entry in the change register and recorded that a feasibility study was required.
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. The entire project life cycle should be aligned with these activities.
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.
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 project 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. Agile project management planning does not follow the same rules and principles in work schedules and change management. We are discussing strict waterfall project methodologies in this article.
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.
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.
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. The project management certification program of BVOP does not include the same flow but advice modern project managers to watch and optimize their processes carefully. More about their project management certification program is published in PGOV.org
CONFIGURATION MANAGEMENT
The change control system (as part of monitoring and controlling phase in project management) 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
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. PMA suggests strict specifications management in its project management course and even quality management plans.
Configuration management has three major elements:
- configuration item identification;
- configuration status accounting;
- configuration control.
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.
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’.
Configuration control
This ensures that due account is taken of the status of each configuration control (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
The change control board should be made up of:
- representatives of the key stakeholders in the project
- the project manager and team leader
- the project sponsors.
- the project support office
If there are doubts about the projected costs of a proposed change, it would be the responsibility of which of the following to investigate?
- the change requestor
- the change manager
- the change feasibility group
- the change control board
As a documented procedure, what is the purpose of configuration management?
- to ensure the project remains within budget
- to identify and document functional characteristics of a system
- to record and report changes and their implementation status
- to verify conformance with requirements
POINTERS FOR ACTIVITIES
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
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.