Change control vs change management
Change control is deciding on changes to something that was agreed — the requirements, the scope, a baseline. Change management means one of three things, depending on who says it: the same decisions in a project, controlling changes to running IT systems, or helping people adopt a new way of working. Configuration management keeps track of which versions of everything belong together. A software project can need all four at once. Below is what each term means, who uses it, and one change followed through all of them.
There is considerable overlap and confusion between change management, configuration management and change control.
Change control vs change management at a glance
| Term | Means | Decides on |
|---|---|---|
| Change control | Deciding on changes to what a project agreed | Requirements, scope, cost, dates |
| Change management, in projects | Usually the same as change control | The same |
| Change management, in IT operations | Controlling changes to running systems; ITIL now calls it change enablement | Releases, configuration, infrastructure |
| Organisational change management | Helping people adopt a change in how they work | Training, communication, adoption |
| Configuration management | Keeping track of versions and what belongs together | Baselines, builds, releases |
The terms are close enough that one word can mean different things in one meeting. Wikipedia’s article on change management sends readers looking for software versions to change control, and those looking for IT services to a separate article. ITIL itself, as Wikipedia lists its practices, has change enablement, service configuration management, organizational change management and project management as four separate practices (Wikipedia).
Change control in a project
PMI’s definition, as Wikipedia quotes it: a “process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected” (Wikipedia). For requirements, the SWEBOK Guide puts it in one line: “Change control is central to managing requirements” (SWEBOK Guide V4.0a).
In project management, “change management” is often used for the same thing. One answer to “What is change management?” on Project Management Stack Exchange: “change management is the process through which you control changes to your project. It’s main objective is to prevent continuous changes to the scope from turning your project into a never-ending death march” (Project Management Stack Exchange, 2011).
What it involves — the request, the impact analysis, the decision, the update to every document and test — is in requirements change management; who decides is in change control board.
Change management in IT operations
In IT service management, change management is about the systems that are already running. Wikipedia: “The objective of change management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service” (Wikipedia). Its board is the change advisory board (CAB), and its question is not “should we build this?” but “is it safe to put this into production now?”.
That is the meaning behind the accepted answer on the same Stack Exchange question: “I would say that most changes and change management comes into picture when the software is deployed and in service and not during software development” (Project Management Stack Exchange, 2011). It is also where the two worlds can clash. On combining ITIL change management with Scrum: “In Scrum the Product Owner is responsible for prioritising the product backlog and often decides when releases will happen. This responsibility will typically clash with the roles and responsibilities of the ITIL process (such as the CAB)” (Project Management Stack Exchange, 2018).
Organisational change management
The third meaning is about people: the training, communication and support that get a business to work a new way. It has its own methods and its own certifications, and searches for “change management” are often about this meaning, not software.
On a software project it matters because the business objectives usually depend on it. The customer portal from the other templates on this site was built to get invoices paid sooner — and that only happens if customers stop paying by bank transfer and the accounts team works from the portal. The software can be finished and the objective still missed.
Configuration management
Wikipedia’s definition: “a management process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life” (Wikipedia). In software it means knowing which version of the requirements, the code, the tests and the documents belong together, and which build is in production.
It is the partner of change control. One accepted answer separates them: “At its simplest level, Change Control usually refers to changes to the project,” while “Configuration Management, on the other hand, is all about the things that the project will deliver” (Project Management Stack Exchange, 2021). The SWEBOK Guide’s software configuration management chapter even uses the same initials for its board: “The authority for accepting or rejecting proposed changes rests with an entity known as a configuration control board (CCB).” For requirements, configuration management is the requirements baseline and the history of each requirement.
One change through all four
In June, the portal’s finance lead asked for CR-10: letting customers pay large invoices in parts.
| Kind | What happened |
|---|---|
| Change control | The impact was analysed — six requirements, the data, an integration, nine days — and the finance lead approved option A (decision D-8) |
| Configuration management | The requirements went from version 1.3 to 1.4; version 1.3 stayed as what phase 1 was signed against |
| IT change management | The release went to production together with the change to the accounting export, because the new portal with the old export would have double-counted payments |
| Organisational change management | The accounts team learned to reconcile part payments; customers were told they could pay in parts |
Each was decided by different people, on different questions. A project that only says “change management” may have done one of them and assumed the others.
Change control plan vs change management plan
Some methods ask for a plan for each. In practice, a change control or change management plan for a software project answers four questions: who may ask for a change, how its impact is assessed, who decides and up to what limit, and how the decision reaches the requirements and the people affected. The change control board charter and the change request template cover most of it. A configuration management plan answers a different question: what is versioned, and how a set of versions is frozen as a baseline.
Which of them does a software project need?
- Change control, always. “All projects need to have a way to process changes because changes are a near certainty for every project in existence and will always be” (Project Management Stack Exchange, 2020). On a small project it can be one named person and a log.
- Configuration management, always, at least for the requirements and the code: versions, and a baseline for each sign-off.
- IT change management when the software runs in someone’s production environment and changes there need approval — often the client’s IT department.
- Organisational change management when the objectives depend on people working differently.
Where Specroot fits
This is the problem Specroot works on: change control and configuration management for requirements — each change decided, and each agreed version kept — so that everyone can see which version of the requirements a change, a test or a release belongs to. Specroot for agencies and consultancies.
Read next
- Requirements change management: the process, with an example — Requirements change management step by step: request, impact analysis, decision, updating every document and test, and closing — with a worked example.
- Change control board (CCB): members, charter and process — What a change control board is, who sits on it, what it decides, a CCB charter template with an example, how a meeting runs, and CCB vs CAB vs product owner.
- Change request vs pull request — A change request changes what was agreed; a pull request changes the code. Scope creep vs change requests, change orders, and the change request process.