Lesson 3 — Change and Configuration Management¶
At a glance
- Module: 11 — Metrics, Monitoring & Control
- Level: Advanced
- Estimated time: 40 minutes
- Example project: the e-commerce platform
Learning objectives¶
By the end of this lesson you should be able to:
- Run a change control process from request to decision to record.
- Perform an impact analysis that covers scope, schedule, cost, quality, and risk.
- Decide at the correct authority level, and explain why the threshold must be agreed in advance.
- Describe the five functions of configuration management and apply them to a software project.
Prerequisites¶
Introduction¶
A baseline is only useful if it can be relied upon. Two mechanisms protect it. Change control decides whether the baseline should move, and records why. Configuration management ensures everyone knows which version of which artefact is authoritative.
They sound administrative. In practice they are where projects lose control: scope grows invisibly, quality absorbs the difference, and nobody can say which build was approved.
1. Change control¶
A change request is a proposal to alter the approved baseline. The process is deliberately simple, and almost all of its value sits in a single step — impact analysis.
| Step | What happens |
|---|---|
| 1. Request | Anyone may raise one, in writing |
| 2. Log | It is recorded with a date, a requester, and a description |
| 3. Impact analysis | Effect on scope, schedule, cost, quality, and risk |
| 4. Decision | Approved, rejected, deferred, or approved with conditions |
| 5. Update | Baseline, plan, and affected documents revised if approved |
| 6. Communicate | Everyone affected is told — including the requester, when rejected |
Two refinements matter in practice.
Impact analysis must cover all constraints. A change assessed only for development effort is the classic route to quality erosion: the work absorbs it, testing pays for it, and nobody decided that. The analysis should state the effect on each constraint, even when the effect is "none".
Rejections must be communicated with reasons and recorded. Otherwise the same request returns repeatedly, or worse, arrives as an assumption that it was approved.
2. Who decides¶
The threshold for each authority level is agreed in advance, not negotiated at the moment of the request.
| Scale of change | Typical authority |
|---|---|
| Within tolerance, no baseline effect | Project manager |
| Beyond tolerance, or affects the baseline | Sponsor or change control board |
| Changes the business case or the benefit | Sponsor, with the business owner |
The threshold is the whole mechanism. A project where every change goes to the sponsor exhausts the sponsor; a project where every change goes to the project manager has no governance. Both failures look like "we're being flexible".
Agile projects run the same logic. Replacing a frozen baseline with a prioritised backlog is a decision about what is baselined, not an absence of control. The product owner decides what enters the backlog, and the consequence of an addition is a removal: a change's cost is paid in items not delivered. That discipline is what makes agile scope control real rather than nominal.
3. Configuration management¶
Configuration management has five conventional functions, and they answer five distinct questions.
| Function | Question it answers |
|---|---|
| Identification | What are the configuration items — code, documents, schemas, infrastructure? |
| Baseline control | Which versions are approved and frozen? |
| Change control | Who may change a baselined item, and through what process? |
| Status accounting | What is the current state of each item and each change? |
| Verification and audit | Does the delivered set match the approved set? |
In software, version control implements part of this so completely that teams assume the whole problem is solved. It is not. A repository tracks files; configuration management also tracks decisions. If nobody can answer "which build was approved for release, and which requirements does it implement?", then configuration management is absent regardless of tooling.
A minimal, honest configuration management practice for a small project:
- Everything — code, requirements, decision records, deployment scripts — in version control.
- A written statement of what is baselined and what is not.
- A change log recording what changed, why, and who approved it.
- Release artefacts identified by version, with the requirements they satisfy.
Key terms¶
| Term | Meaning |
|---|---|
| Change request | A proposal to alter the approved baseline |
| Impact analysis | Assessment of a change across all constraints |
| Change control board | The authority that decides changes beyond tolerance |
| Change log | The record of requests and their decisions |
| Configuration item | An artefact under configuration control |
| Baseline | An approved, frozen version of a set of artefacts |
| Status accounting | The recorded state of each item and change |
| Verification and audit | Confirming the delivered set matches the approved set |
Worked example¶
Task: handle a scope change on the illustrative e-commerce platform. The checkout release is baselined and in build. Assertions are invented for teaching.
Step 1 — Receive the request in writing. Marketing asks for guest checkout: the ability to purchase without creating an account. It arrives as a message, and is logged with a date, a requester, and a description before anything else happens. Logging first is what prevents the request from becoming a hallway assumption.
Step 2 — Perform full impact analysis.
| Constraint | Impact |
|---|---|
| Scope | New checkout flow; order-ownership rules for orders with no account; link-to-account-afterwards flow |
| Schedule | Approximately 5 days of development plus testing and review; the checkout path is on the critical path |
| Cost | 5 person-days at the blended rate, plus added review and test time |
| Quality | Touches the order and payment path — the highest-severity area of the codebase |
| Risk | Adds a fraud vector (unverified purchasers); adds a data-protection question about orders with no identifiable owner |
Step 3 — Note what the analysis revealed beyond effort. The schedule number, 5 days, is the least important line. The request lands in the payment path, where the project's severity-1 defects live, and it introduces a new data-protection question. Recording those is what makes the decision a real decision rather than a capacity calculation.
Step 4 — Decide at the correct authority level. The expected variance is beyond the ±5% tolerance agreed in Lesson 2, so the change goes to the change control board, not to the project manager.
Step 5 — Present real options, not a single recommendation. The board can: approve and accept a later date; approve and remove something of similar size (the saved-cart improvement); defer guest checkout to the next release; or reject it, recording the reason.
Step 6 — Record the outcome. Assume the board defers it. The change log records the request, the analysis, the decision, the date, and the reason. The next release's scope begins with guest checkout and the analysis carried forward — so no work is repeated and no one has to remember.
Step 7 — Apply configuration management. The baselined scope statement, the schedule, and the cost estimate remain the approved versions. The deferred request is recorded against the next baseline. When someone asks in week 9 why guest checkout is missing, the answer is a documented decision, not a reconstruction.
Step 8 — Audit the release. Before release, confirm the delivered build matches the approved baseline and implements exactly the approved requirements — no more, and no less. Work built speculatively and never approved is a scope change that happened without a decision.
Common misconceptions¶
“Change control is bureaucracy”
Bureaucracy is a process whose steps nobody uses. Impact analysis changes decisions every time, because it is the only mechanism that stops scope growth from being paid for out of quality, testing, and people's evenings.
“Agile means no change control”
Agile changes what is baselined — a prioritised backlog rather than a frozen scope — and changes how consequences are made visible. It does not remove the need to decide, record, and communicate.
“Version control is configuration management”
Version control covers identification and part of baseline control for files. It does not record which versions are approved, what state each change is in, or whether the delivered set matches what was agreed.
Practical activity¶
Handle a change and protect a baseline. For one example project:
- State your authority thresholds: what the project manager may approve, and what must escalate.
- Invent a realistic change request and log it in the form your process requires.
- Write an impact analysis covering all five constraints, including any you judge to be unaffected — and say why.
- Decide at the correct level and write the change log entry.
- List your configuration items, state which are baselined, and describe how you would audit a release against the approved set.
What "good" looks like: thresholds set before the request arrives, an impact analysis that reasons about quality and risk rather than only effort, a decision recorded with its reason, and a configuration item list that includes requirements and decision records, not only source code.
Self-assessment¶
- Why must impact analysis assess all constraints, rather than just development effort?
- A change is within tolerance. Who should decide, and what must still happen?
- What can configuration management tell you that a version control system alone cannot?
-
How does an agile project control scope if it has no frozen baseline?
-
Apply it — change request. A business analyst emails a developer directly: “Can you add an export button to the reporting screen? It's small — two hours at most.” The developer adds it, the work ships in the next release, and nothing is recorded. A month later the same screen is under audit and nobody can say what changed or why.
Hint: A strong answer says what should have happened instead, and which decision it exposes.
Show answers
- Because a change assessed only for effort is paid for by whatever is not measured — usually testing and review. That is a decision about quality and risk being made accidentally and invisibly, and it becomes visible later as defects in the very area the change touched.
- The project manager, acting within the delegated tolerance. The change must still be logged, the effect recorded, and affected people informed — "within tolerance" changes who decides, not whether control applies.
- Which versions are approved, what state each change is in, and whether the delivered set matches the approved set. Version control stores files; configuration management records decisions about them.
- Through a prioritised backlog: the product owner decides what enters, and the consequence of an addition is a removal, since capacity is fixed. Scope control is exercised as ordering and trade-off rather than as approval of a variance against a frozen document.
- The problem is not the two hours; it is that a baseline was changed without a decision. The change went around change control, so there is no request, no impact analysis, no decision at the right authority level, and no record in the configuration baseline — which is exactly why the audit question cannot be answered. What should have happened: the analyst raises a request, the impact analysis covers scope, schedule, cost, quality, and risk (here small, but the quality answer is not “none” if the screen is under audit), the request is decided at the level the pre-agreed threshold assigns to it, and both the change and the decision are recorded before the work is done. The exposed decision is the threshold: “small” is not a number, and unless a rupee, hour or risk limit was agreed in advance, every change becomes a judgement call made by whoever is most convenient.
Summary¶
- Change control exists to keep the baseline reliable: request, log, analyse, decide, update, communicate.
- Impact analysis covers scope, schedule, cost, quality, and risk — and its value is mostly in the constraints that are easy to overlook.
- Authority thresholds must be agreed in advance; agile changes what is baselined, not whether control exists.
- Configuration management covers identification, baseline control, change control, status accounting, and verification and audit.
- A release should be auditable: the delivered set matches the approved set, and no approved decision is unrecorded.
Further learning¶
- Module 12 — Advanced Project Management
- A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — integrated change control and configuration management.
- Software Configuration Management Patterns, Stephen P. Berczuk with Brad Appleton — practical configuration management for software teams.
Next¶
You have completed Module 11. Continue to Module 12 — Advanced Project Management.