15.2 Managing Scope Through Configuration Management
Key Takeaways
- The five configuration management activities are planning, identification, control, status accounting, and verification audit.
- Identification assigns unique references and versions so everyone can say exactly which item and which version they mean.
- Control ensures changes to configuration items happen only through the agreed process, protecting the integrity of the baseline.
- Status accounting records the current state and history of every configuration item, which is what makes reporting and audit possible.
- Verification audit confirms the physical reality matches the records, catching undocumented changes before they reach handover.
Outcome 16b names five configuration management activities explicitly: planning, identification, control, status accounting and verification audit. Named process steps in a syllabus are near-certain exam content, so learn what each one does and what fails without it.
Managing scope through configuration management
Configuration management (CM) is the discipline that ensures the products, components, and documentation of the project remain identified, consistent, and controlled as they evolve. If requirements management defines the needed scope, CM protects the integrity of the evolving solution and its records so that teams build, test, and hand over the correct configuration.
Scope creep often appears as uncontrolled document or product versions: two drawings, three requirement lists, and a "final_final_v7" build that nobody can relate to approved tests. CM prevents that chaos.
The five configuration management processes
APM-aligned teaching commonly recognises five CM processes. Learn them as a complete system, not isolated jargon.
| Process | Purpose | Typical activities | Failure if weak |
|---|---|---|---|
| 1. Configuration management planning | Define how CM will work on this project | CM plan: items in scope, naming/version rules, tools, roles, baselining points, audit approach, link to change control | Ad hoc versioning; inconsistent team habits |
| 2. Configuration identification | Decide what will be controlled and how it is uniquely labelled | Select configuration items (CIs); assign IDs; define product breakdown/structure; specify baselining events | Unclear what is "the product"; cannot find the approved item |
| 3. Configuration control | Manage changes to baselined CIs | Raise change requests; impact assess; approve/reject; update items and related docs; release new versions | Unauthorised changes; silent scope growth |
| 4. Configuration status accounting | Record and report the status of CIs and changes | Status records, version histories, change logs, progress of approved changes | Nobody knows current approved state or open changes |
| 5. Configuration verification and audit | Confirm physical/actual items match approved records | Reviews, configuration audits, reconciliations before gates/handover | "As-built" differs from "as-documented"; failed assurance |
1. Configuration management planning
Planning sets the rules before complexity explodes. A configuration management plan (standalone or embedded in the PMP) typically covers:
- Which products and documents are configuration items
- Naming, numbering, and version conventions
- Tools (registers, repositories, PLM/ALM tools)
- Roles (configuration librarian/manager, change authority)
- When baselines are created (requirements, design, product, handover)
- How CM links to change control, quality, and release management
- Audit schedule and gate evidence expectations
Planning is proportionate: a small internal process change needs lighter CM than a multi-contractor infrastructure asset with safety-critical drawings.
2. Configuration identification
Identification answers: what are the configuration items, and how is each uniquely known?
Configuration items (CIs) might include requirement specifications, design models, software builds, hardware assemblies, test procedures, training materials, or as-built drawings — selected by risk and need for control. Over-controlling every email is wasteful; under-controlling critical products is dangerous.
Identification also defines the product structure (how parts relate) so impact analysis can see that changing Module A affects Interface B and Test Pack C.
3. Configuration control
Control is the operational heart of CM. Once a CI is baselined, changes follow a controlled path:
- Propose change with rationale
- Assess impact on scope, time, cost, quality, risk, benefits, and related CIs
- Decide via agreed authority (project manager, change board, sponsor — per governance)
- Implement approved changes and update all related configuration information
- Release the new approved version and withdraw superseded items from use
Configuration control and project change control are tightly linked: change control decides whether the project should accept a change; configuration control ensures the product and document set actually reflects the decision.
4. Configuration status accounting
Status accounting is the information service of CM. It answers questions such as:
- What is the current approved version of CI-017?
- Which changes are proposed, approved, implemented, or rejected?
- Which baseline was used for the last test run?
- What is the configuration of the build going to pilot users?
Without status accounting, control decisions cannot be evidenced and teams work from stale copies.
5. Configuration verification and audit
Verification and audit check that reality matches the record. A configuration audit may confirm that the installed asset, software release, or document pack matches the approved configuration baseline and that mandatory changes have been incorporated. This is especially critical before handover/transition, major gates, or regulated go-live.
| Audit focus | Example question |
|---|---|
| Functional | Does the item meet the baselined requirements/performance? |
| Physical / configuration | Does the as-built item match drawings, BOMs, and version records? |
Scenario B — configuration failure at handover
A manufacturing line upgrade is "complete," but operations receive training manuals for software build 3.2 while the live PLC runs build 3.4 with two unrecorded parameter changes made overnight by a contractor. Status accounting and verification audit were skipped. Result: incidents, blame, and delayed benefits. Correct practice: identify critical CIs, control parameter changes, maintain status records, and audit configuration before acceptance.
Linking requirements baselining to scope control
Think of the chain as:
Gathered needs → analysed & justified requirements → requirements baseline → design/product baselines (CIs) → configuration control of changes → status accounting & audit evidence
Scope is therefore managed by:
- Defining scope through justified requirements
- Baselining those requirements (and related product definitions)
- Forcing subsequent change through impact assessment and authority
- Keeping configuration records consistent with decisions
- Verifying that delivered products match approved configuration
Scenario C — "small tweak" that was not small
A stakeholder asks the developer to "just add one extra report" outside the change process. That report needs new data feeds, security roles, and test cases — a multi-CI impact. Without configuration control, the team absorbs silent scope, misses tests, and fails UAT. The PM should route the request through change/configuration control, re-baseline if approved, and replan tests and training.
Answer pattern for LO16 long responses
When a scenario shows unclear scope, conflicting asks, or version chaos:
- Separate requirements management (establish what is needed) from configuration management (control what is produced and recorded).
- Walk gather → analyse → justify → baseline for establishing scope.
- Name all five CM processes where relevant, with purpose not only labels.
- Link baselines to change control and governance authority.
- Use a scenario example (wrong version, gold-plating, silent tweak) to show applied judgement.
That structure scores as professional scope control rather than a generic "manage stakeholders better" answer.
What is the primary purpose of configuration status accounting?
A contractor changes a baselined design drawing on site without going through the agreed process. Which configuration management response is most appropriate?