Change Management is concerned with the proposal, selection and scheduling of changes during the lifecycle of a project.
Change Management is interlinked with, but separate to, Revision Control.
Change Management is the core to controlling your development processes. Without effective Change Management the management of your project is subject to slavish adherence to a (fixed, and pre-determined) project plan, with no mechanism for dealing with inevitable changes in requirements, design, implementation or testing.
It is no surprise that Change Management is at the heart of so many Agile process, such as SCRUM.
The core of Change Management is the Change Request (often abbreviated simply as CR) A Change Request has many different names, all meaning the same thing:
- Change Note (CN)
- Engineering Change (Order)
- Engineering Change Request (ECR)
- Action Request (AR)
- Request For Change (RFC)
Essentially, a Change Request is a call for an adjustment to a system. Change requests typically originate from one of five sources (Dennis, Wixom, & Tegarden, 2002):
- Bugs that must be fixed
- System enhancement requests from users
- Events in the development of other systems
- Changes in underlying structure and or standards
- Demands from senior management
The CR Artefact
A CR is a project artefact – that is, it is a entity that is created, worked on, stored and audited, just like every other artefact in the system. The CR represents the lifecycle of a change. As such it has a different lifecycle to other artefacts.
As an artefact the CR may (in fact, should) also be held under revision control.
The CR lifecycle is shown in Figure 19. There are three main parts to the lifecycle.
Figure 19 – The Change Request is an artefact with its own unique lifecycle
Opening the CR
Creating a CR records that some change to the system is requested; it does imply that the work will be performed. Once created the change must be reviewed before it can be worked on. The review is performed by the Change Control Board (CCB). The CCB consists of stakeholders who will be affected by the change, and those who can decide whether the change is worth doing. At the minimum this will be the Project Manager or Team Leader; but may include a multi-disciplinary group including engineering, senior management, marketing, customer support, etc.
The CR must be assessed for impact to the project. This work should ideally be done by the CR submitter. Points considered during the assessment of a change request include:
- Technical feasibility
- Customer expectation
The CR may be Accepted (Opened for working), Rejected (Infeasible or invalid) or Deferred (delayed; therefore inducing technical debt to the project)
Once opened project artefacts can be modified. Each artefact follows its own Configuration Item lifecycle (Figure 20). The CR records artefacts modified. Each artefact records the changes made in support of the CR.
Figure 20 – Each artefact modified under the Change Request follows its own change lifecycle
Including the change
The completed change should be reviewed again by the CCB. The purpose of the review is to assess whether the change is valid – That is, do the modifications made to the system correctly addresses the change requested? An invalid change will be rejected for rework.
Once accepted the change can be integrated into the product.
Change Management is often overlooked in CM. Change Management controls precisely what is going to change in the project and when. Without Change Management a project is running on ad hoc and unrecorded decisions by the development team or project manager and runs a serious risk of heading out of control. Although the Change Management presented here involves project artefacts (CRs) many Agile processes adopt similar principles using techniques such as Product Backlogs and Feature Lists (SCRUM), which are organised by customer priority. These mechanisms are, in effect, simple Change Management processes.
- Practice makes perfect, part 3 – Idiomatic kata - February 27, 2020
- Practice makes perfect, part 2– foundation kata - February 13, 2020
- Practice makes perfect, part 1 – Code kata - January 30, 2020
Glennan is an embedded systems and software engineer with over 20 years experience, mostly in high-integrity systems for the defence and aerospace industry.
He specialises in C++, UML, software modelling, Systems Engineering and process development.