The drawing says revision C. The factory is building revision B. Testing used revision C with one temporary patch. The operations manual still describes revision A. Nobody is certain whether the supplier incorporated the approved interface change.
The project may have excellent people, a strong schedule and formal change control. It still has a dangerous problem: the project does not know whether everyone is working from the same approved reality.
Project configuration management is the discipline of keeping controlled project artefacts, product versions, baselines, approved changes and the real delivered state coherent through the project life cycle.
It answers questions that become increasingly expensive when nobody can answer them:
- What is the current approved version?
- What exactly does that version contain?
- Which requirements, drawings, models, code, procedures or datasets define it?
- What changed?
- Who approved the change?
- Which downstream artefacts must change with it?
- What version was actually built, tested, accepted and handed over?
Configuration management makes those answers recoverable rather than dependent on memory.
The one-sentence answer
Project configuration management works by identifying the artefacts and product elements that require control, establishing approved baselines, assigning stable identities and version rules, evaluating and implementing authorised changes, recording configuration status, auditing consistency, and ensuring the physical or digital product continues to match the information that defines it.
1. Current PMI terminology
The Project Management Institute’s current 2026 Lexicon defines a configuration management plan as a component of the project management plan containing procedures used to track project artefacts and monitor and control changes to those artefacts. It defines a configuration management system as the collection of procedures used for the same purpose. Source: Project Management Institute, Lexicon of Project Management Terms, Version 5.0.
PMI’s Practice Standard for Project Configuration Management describes configuration management more broadly as the collective processes, activities, tools and methods used to manage project items through the project life cycle, including the composition of the project, the documentation defining it and the supporting data. Source: Project Management Institute, Practice Standard for Project Configuration Management.
The central idea is stable across both formulations: project artefacts and product states need managed identity through change.
2. NASA’s configuration-management principle
NASA’s systems-engineering guidance frames configuration management as a practice that provides visibility of the true product configuration, protects product integrity by controlling changes to baselines, distinguishes product versions and keeps the product consistent with the information that defines it. Source: NASA Systems Engineering Handbook, Configuration Management section.
That formulation captures why configuration management matters beyond engineering.
When a project cannot establish whether the real delivered item matches the approved information, every later control becomes weaker: testing, acceptance, safety, support, audit, handover and change analysis.
3. Configuration management is not the same as change control
Project Change Control owns the decision process for consequential changes to controlled commitments.
Configuration management owns the identity and state of the artefacts and products affected by those decisions.
Change control asks:
Should this proposed change be authorised?
Configuration management asks:
Which controlled items change, what version becomes current, which records and dependent artefacts must update, and how do we prove the real configuration now matches the authorised state?
The two disciplines should work together. Authorising a change without propagating it creates configuration drift. Updating artefacts without proper authority creates uncontrolled change.
4. Configuration management is not document management
Document management stores and controls documents. Configuration management manages the defined state of the product or project system and the information needed to reproduce, verify and understand that state.
A controlled drawing may be part of configuration management. So may software code, firmware, a requirements baseline, a bill of materials, a data schema, a model, an interface specification, a test configuration or an operating procedure.
The key test is not “Is it a document?” It is “Does this item define or provide evidence about a configuration whose identity matters?”
5. Configuration management is not integration management
Project Integration Management owns coherence across the whole project: scope, schedule, cost, risk, change, resources and decisions.
Configuration management owns a narrower but essential question: Which approved version of the project artefacts and product configuration is the project actually using?
Integration management may decide that scope, schedule and cost must change together. Configuration management ensures the requirement set, design package, implementation and verification records remain internally consistent afterward.
6. Configuration items
A configuration item is an item selected for configuration control.
Depending on the project, configuration items may include:
- requirements specifications;
- system architecture;
- drawings;
- software repositories;
- firmware;
- data schemas;
- models;
- interface specifications;
- bills of materials;
- approved procedures;
- test configurations;
- training packages;
- operational runbooks;
- released publications or learning materials where edition identity matters.
Not everything needs the same level of control. Over-controlling low-consequence items creates friction. Under-controlling high-consequence items creates ambiguity.
7. Choose configuration items by consequence
An item deserves stronger configuration control when losing its identity could cause material rework, unsafe action, invalid testing, contractual dispute, operational failure or inability to reproduce the accepted product.
A useful selection question is:
If two competent people used different versions of this item without realising it, what could go wrong?
The greater the consequence, the stronger the case for formal configuration identification, approval and status tracking.
8. Stable identity
A configuration item needs a stable identity.
Useful identity information can include:
- item ID;
- title or description;
- owner;
- version or revision;
- status;
- effective date;
- baseline membership;
- location of authoritative source;
- related configuration items.
Identity prevents “the latest file” from becoming a project control method.
9. Version numbers need rules
A version label is useful only if people understand what it means.
Projects may use revision letters, semantic versioning, numbered releases, issue states or controlled edition IDs. The specific convention matters less than consistent interpretation.
The project should define:
- when a version changes;
- which changes are considered material;
- how superseded versions are retained;
- how draft and released versions differ;
- who can issue a release;
- how users find the current authorised version.
The most elegant versioning scheme is useless if nobody knows which version is authoritative.
10. Baselines
A baseline is an approved reference state used for comparison, control and future change.
Examples include:
- requirements baseline;
- design baseline;
- configuration baseline;
- released software baseline;
- approved publication edition;
- as-built or as-configured baseline;
- operational baseline.
A baseline does not mean “never change.” It means “change deliberately from a known starting point.”
11. Baselining too early
An immature baseline creates unnecessary change traffic.
If the project baselines requirements before important stakeholder conflicts are resolved, ordinary discovery becomes formal change.
This can make the project appear unstable when it is simply learning.
Baseline when enough maturity exists that changes deserve visibility and consequence analysis.
Project Requirements Management explains why different requirement families may mature at different times.
12. Baselining too late
If the project keeps everything “draft” while suppliers build, teams test and operations prepare, people may be using different interpretations without controlled change.
Late baselining hides the point at which a working idea became a real commitment.
A useful baseline exists before dependent work needs stability—not after disagreement reveals that stability was missing.
13. Configuration identification
Configuration identification establishes what items are controlled and how they are identified.
NASA describes configuration identification as one of the core elements of configuration management alongside change control, status accounting and verification or audit. Source: NASA Systems Engineering Handbook, Configuration Management.
Without identification, the project cannot reliably answer which item a change, test or acceptance record refers to.
14. Configuration change control
Configuration change control governs changes to baselined configuration items.
A proposed change should identify:
- the item affected;
- current version;
- proposed version or state;
- reason for change;
- requirements affected;
- interfaces affected;
- cost and schedule effect;
- verification or retest needed;
- operational or supplier consequence;
- approval authority.
The point is not paperwork. It is consequence visibility before the project changes something others rely on.
15. The configuration control board
A configuration control board, often shortened to CCB, is one governance mechanism for evaluating and authorising controlled configuration changes.
The board should include enough technical, project and operational authority to understand consequence.
NASA notes that systems engineers, project managers and other key engineers often participate in change approval processes to assess cost, performance, programmatic and safety impact. Source: NASA Systems Engineering Handbook.
Not every project needs a formal board. Small projects may use one accountable owner plus specialist review. The important property is controlled authority, not meeting size.
16. Change impact is a network problem
A change rarely affects one artefact only.
A requirement change may affect:
- design;
- code;
- supplier scope;
- test cases;
- training;
- operations manuals;
- cost;
- schedule;
- risk;
- acceptance evidence.
Configuration management makes those relationships discoverable enough to propagate change.
This is where Project Requirements Management and configuration management become tightly connected: traceability helps identify which downstream items must be reviewed when a requirement changes.
17. Configuration status accounting
Configuration status accounting records and reports the current and historical state of configuration items and changes.
A useful status record can answer:
- What is the current approved version?
- What baseline contains it?
- Which change requests are open?
- Which changes were approved?
- Which approved changes are implemented?
- Which implemented changes are verified?
- Which versions are superseded?
- What product serial, build or release contains which configuration?
History matters because acceptance and investigation often require reconstructing what was true at a specific moment.
18. Approved does not mean implemented
A change can be approved while the old configuration remains physically or digitally in place.
This distinction prevents a dangerous reporting shortcut.
Useful states may include:
- proposed;
- under assessment;
- approved;
- implemented;
- verified;
- released;
- superseded;
- rejected or withdrawn.
Do not mark the product changed merely because authority approved the change.
19. Implemented does not mean verified
An engineer may implement an approved change incorrectly.
A supplier may update the drawing but not the manufactured part. A software team may merge the code but deploy a different build. A writer may apply an editorial decision in one format but leave another edition unchanged.
Configuration verification asks whether the approved change exists in the actual configuration and whether the defining information has remained consistent.
20. Configuration verification and audits
Configuration audits test whether the documented configuration and actual product agree.
Depending on the domain, an audit might compare:
- approved requirements against implemented functions;
- released drawings against as-built components;
- software release notes against deployed code;
- bill of materials against installed equipment;
- operating procedure against actual system behaviour;
- publication metadata against the released edition.
The audit is not a substitute for normal quality control. It tests configuration integrity.
21. Functional vs physical configuration
Complex technical projects often distinguish functional configuration from physical configuration.
Functional configuration describes what the product must do and the performance it must provide.
Physical configuration describes how the realised product is actually composed.
This distinction helps explain why two products can satisfy similar functions through different physical configurations—and why configuration management must preserve both requirement and implementation identity.
22. As-designed, as-built, as-tested and as-operated
A strong project distinguishes several configuration states.
- As-designed: what approved design information specifies.
- As-built: what was actually constructed or implemented.
- As-tested: the exact configuration used when verification evidence was produced.
- As-released: the configuration formally released for use.
- As-operated: the configuration currently in service after authorised operational changes.
The states may be identical. When they are not, the differences must be understood.
23. Test evidence belongs to a configuration
A test result is only as meaningful as the configuration it tested.
If a performance test passed on build 3.2 but production deploys build 3.4 with changed database logic, the project should assess whether the old evidence still applies.
This is why Project Readiness Management should verify the relationship between tested configuration and deployed configuration before go-live.
24. Configuration drift
Configuration drift occurs when the real system moves away from the approved or recorded state without the change being controlled properly.
Examples include:
- an administrator changes a production setting manually;
- a contractor substitutes a component without updating the drawing;
- a teacher uses an unofficial revision of a learning pack;
- a supplier changes a firmware version without notifying the project;
- a published page changes while the source edition ledger remains unchanged.
Drift creates uncertainty about whether testing, support and acceptance evidence remain valid.
25. Emergency changes still need configuration control
During an incident, normal approval timing may be too slow.
Emergency change procedures can allow accelerated authority while preserving minimum controls:
- who authorised the emergency change;
- what changed;
- which configuration received it;
- what temporary risk was accepted;
- what evidence must be collected afterward;
- whether the change becomes permanent or is reversed.
Project Crisis Management may temporarily compress decision paths. Configuration integrity should not disappear with them.
26. Configuration management plan
A configuration management plan describes how configuration control will work for the project.
NASA’s handbook appendix suggests that a comprehensive CM plan normally addresses product definition and scope, CM activities and procedures, roles and responsibilities, interfaces, deliverables, milestones and supplier flow-down requirements. Source: NASA Systems Engineering Handbook, Appendix M: CM Plan Outline.
For ordinary projects, a proportionate plan may cover:
- what is controlled;
- how items are identified;
- where authoritative versions live;
- who can approve changes;
- how version and release states work;
- how status is reported;
- how suppliers participate;
- how audits are performed;
- how configuration transfers to operations.
27. Authoritative source
For every controlled item, people should know where the authoritative version lives.
Copies may exist for convenience. Only one controlled source should define current status unless the project has an explicit distributed-control model.
Email attachments are a common source of configuration ambiguity because copies detach from the state of the original.
A strong system distributes links to controlled sources rather than encouraging uncontrolled copies where practical.
28. Supplier configuration management
Supplier boundaries are frequent configuration failure points.
The client may approve requirement revision 4 while the supplier works from revision 3. A supplier may change a component because the original becomes unavailable. A subcontractor may use a drawing version the prime contractor has already superseded.
Procurement documents should therefore define appropriate configuration obligations where they matter:
- controlled specifications;
- change notification;
- approval thresholds;
- release identity;
- as-built records;
- substitution control;
- handover data.
Project Procurement Management owns the commercial framework. Configuration management preserves technical identity across that commercial boundary.
29. Interface configuration
Interfaces need especially careful configuration control because two or more owners depend on the same definition.
An interface change can be implemented correctly by one side and still fail if the other side remains on an older version.
Useful interface controls can include:
- stable interface IDs;
- versioned schemas;
- compatibility rules;
- joint approval;
- effective dates;
- integration-test traceability.
Project Dependency Management identifies what one party needs from another. Configuration management ensures both parties are using the same controlled definition of that exchange.
30. Configuration management in software
Software configuration management often includes source control, branches, builds, dependencies, release packages, environment configuration and deployment identity.
Automation can strengthen control through:
- version-control systems;
- immutable build artefacts;
- automated deployment pipelines;
- infrastructure as code;
- dependency manifests;
- automated configuration drift detection.
Automation reduces manual ambiguity but does not remove governance. Someone still defines which branch can release, which tests are required and who can promote a build into production.
31. Configuration management in data projects
Data projects also have configuration states.
Controlled items may include:
- schema versions;
- transformation logic;
- reference data;
- mapping tables;
- data-quality rules;
- model features;
- pipeline code;
- retention policies;
- model or dataset releases.
If the training dataset, model and production schema cannot be connected to stable identities, reproducibility and incident investigation become difficult.
32. Configuration management in construction and engineering
Physical projects rely heavily on configuration control because drawings, specifications, components and as-built conditions can diverge.
Examples include:
- issued-for-construction drawing revisions;
- approved material substitutions;
- site changes;
- non-conformances;
- equipment serial numbers;
- commissioning records;
- as-built drawings;
- operating manuals.
The final operational owner needs to know what was actually installed, not only what was originally designed.
33. Configuration management in publishing
Publishing projects also require configuration control when edition identity matters.
A publication may exist as:
- source manuscript;
- review edition;
- approved edition;
- WordPress representation;
- rendered public page;
- syndicated or cached copies.
A correction should identify which edition changed, which evidence supports the change, and whether dependent representations require update.
“Updated” is not a sufficient configuration record when substantive claims changed.
34. Configuration management in education
Learning systems also produce version-sensitive artefacts.
A curriculum guide, worksheet, marking rubric and teacher manual can become inconsistent if one changes without the others.
When syllabus or examination requirements change, configuration management helps identify which learning materials belong to the old regime and which have been updated for the new one.
This is particularly important where teachers and students rely on archived copies distributed outside the main platform.
35. Configuration management and requirements
Requirements management and configuration management meet at the baseline.
Project Requirements Management ensures requirements are clear, traceable and controlled through change.
Configuration management ensures the approved requirement set has stable identity and remains consistent with downstream design, implementation and verification artefacts.
NASA explicitly treats requirements baselines and approved requirement changes as inputs to configuration management. Source: NASA Systems Engineering Handbook, Configuration Management process.
36. Configuration management and readiness
A project cannot prove readiness confidently if it does not know what configuration is being launched.
Project Readiness Management should ask:
- Which configuration was tested?
- Which configuration will be deployed?
- Are differences understood?
- Do procedures and training match the released state?
- Can operations identify the configuration after handover?
NASA’s readiness guidance similarly treats configuration-controlled operations materials as necessary for reliable operations.
37. Configuration management and project assumptions
Configuration identity can expose failed assumptions.
The project may assume all field units run firmware 4.1. Configuration status accounting reveals that twelve units still run 3.9.
The project may assume all teaching packs use the revised rubric. Version data shows older packs remain in circulation.
Project Assumption Management owns the belief. Configuration management provides evidence about the actual state.
38. Configuration management and issues
Many project issues begin as configuration mismatches.
A defect appears only in one software build. A supplier installs the wrong component revision. A test uses an obsolete procedure. An operator follows an outdated manual.
Project Issue Management addresses the active problem. Configuration history helps reconstruct what changed and where else the condition may exist.
39. Configuration management and risk
Weak configuration control creates risk directly.
- wrong-version risk;
- invalid-test-evidence risk;
- supplier-mismatch risk;
- operational-support risk;
- auditability risk;
- safety risk;
- rework risk;
- cybersecurity and access-control risk.
Project Risk Management should treat configuration-control weakness as a cause or control failure where material.
40. Configuration management and handover
Handover should transfer a known configuration, not an informal collection of files.
Operational owners may need:
- as-built or as-configured records;
- current manuals;
- software and firmware versions;
- approved deviations;
- open configuration actions;
- support dependencies;
- release history.
Project Closure and Handover should confirm that the receiving organisation understands and accepts the transferred configuration.
41. Configuration ownership after project closure
Configuration management does not end merely because the temporary project closes.
The operating organisation needs continuing configuration ownership for assets, systems, code, data, procedures or content that will change in service.
Closure should define:
- who owns future changes;
- where configuration records are maintained;
- how operational changes are approved;
- which historical records must be retained;
- how the current operational baseline is identified.
42. Configuration management in agile delivery
Agile delivery changes configurations frequently. It does not remove configuration management.
Modern software teams may implement configuration control through automated version control, continuous integration and deployment pipelines rather than traditional document-heavy methods.
The underlying questions remain:
- What version exists?
- What changed?
- Who authorised release?
- What tests belong to the build?
- What is running in production?
- Can the team restore a known previous state?
Agile Project Management benefits when configuration control is automated enough to support frequent change without losing identity.
43. Configuration management in hybrid delivery
Hybrid projects often combine rapidly changing digital components with slower physical or contractual baselines.
The configuration system must respect both speeds.
A software release may change weekly while a hardware interface freezes months earlier. The project should know where adaptability remains cheap and where change now creates broad consequences.
Hybrid Project Management should define how these control regimes meet.
44. Configuration management in programmes
Programmes may contain configuration items shared across projects.
Examples include:
- common architecture;
- shared data standards;
- common interfaces;
- operating-model definitions;
- shared supplier components;
- integrated release baselines.
Programme Management should distinguish project-local configuration from programme-shared configuration so one project cannot change a shared item without understanding cross-project consequence.
45. Configuration management in megaprojects
Megaprojects make configuration control especially difficult because thousands of components, drawings, suppliers, interfaces and field changes evolve over long periods.
A small discrepancy can propagate widely if it concerns a shared interface or repeated component.
Megaproject Management therefore needs configuration structures that scale across packages while preserving enough central control over critical interfaces, baselines and as-built records.
46. Configuration management and AI
AI can help compare versions, identify change impact, detect inconsistent references, summarise release histories and find artefacts that still cite superseded configurations.
AI can also create new configuration ambiguity if generated outputs are not bound to stable source versions.
An AI-generated answer may reflect requirement revision 6 while the current baseline is revision 8. A generated procedure may silently combine information from several historical states.
A strong AI-assisted configuration workflow therefore preserves source identity, version, authority and effective state.
AI Project Management owns the broader governance. Configuration management ensures AI works from the intended project state rather than whichever artefact it happens to retrieve.
47. Common failure: “final_final_v7”
File names become the version-control system.
Nobody knows which file is approved or whether a later copy includes authorised changes.
Repair this with stable identity, controlled status and one authoritative source.
48. Common failure: approval changes the document but not the field
The drawing is updated after approval, but the installed asset remains unchanged.
Do not confuse information update with implementation.
49. Common failure: field change never reaches the baseline
A team makes a practical site modification to solve an installation problem but never updates the as-built record.
Operations later works from the wrong information.
Field reality must return to the controlled baseline.
50. Common failure: change impact stops at the edited item
The requirement changes. The requirement document is updated. The test case, interface specification and training guide remain unchanged.
Use traceability to propagate the change through dependent artefacts.
51. Common failure: superseded items remain easy to use
Old drawings or manuals remain in shared folders beside current versions with no obvious status difference.
Retain history, but make superseded state unmistakable so users do not select the wrong version accidentally.
52. Common failure: testing has no configuration identity
A test report says “passed” without recording the software build, hardware revision, dataset, environment or procedure version.
Later nobody can determine whether the evidence applies to the released product.
53. Common failure: suppliers manage configuration differently
Every supplier has a competent internal system, but the project has no shared rules at package boundaries.
Define the common minimum: item identity, interfaces, change notification, approval authority, effective dates and as-built return.
54. Common failure: configuration control becomes bureaucracy
Every minor working note requires formal board approval.
This creates delay and encourages people to bypass the system.
Tailor control to consequence. Draft working material can remain flexible. Baselined items and critical interfaces deserve stronger governance.
55. Common failure: configuration ownership ends at launch
The project hands over the product but not the configuration-management responsibility.
Operations begins changing the system without an agreed control model.
Transfer configuration ownership explicitly during handover.
56. A worked example: one interface change
Consider a fictional project connecting a booking platform to a scheduling service.
The baselined interface specification is INT-04 revision 2. It defines a date field as YYYY-MM-DD.
The scheduling supplier proposes revision 3, adding a timezone-aware timestamp because the service now supports several regions.
The project first identifies affected items:
- interface specification INT-04;
- booking-platform transformation code;
- scheduling-service API;
- integration tests;
- data mapping documentation;
- support troubleshooting guide.
The change assessment finds that revision 3 improves future compatibility but requires additional development and regression testing.
The authorised board approves the change for Release 2, not the current Release 1.
Configuration status is then:
| Item | Release 1 | Release 2 target |
|---|---|---|
| Interface spec | INT-04 Rev 2 | INT-04 Rev 3 |
| Booking code | Build 1.8 | Build 2.x with timestamp support |
| Integration test pack | IT-04 Rev 5 | IT-04 Rev 6 |
| Support guide | SG-12 Rev 2 | SG-12 Rev 3 |
Release 1 remains coherent because the approved change does not silently alter it. Release 2 becomes coherent when all dependent items update together and the new configuration is verified.
The discipline prevents an awkward middle state in which one side implements the new timestamp while the other side still expects the old date field.
57. A practical configuration-management cycle
- Plan: define the configuration-management approach, roles, authority and tools.
- Identify: select configuration items and assign stable identities.
- Baseline: establish authorised reference states at appropriate maturity points.
- Propose change: describe the requested change and affected items.
- Assess impact: examine technical, cost, schedule, risk, interface and operational consequence.
- Authorise: route the change to the correct authority.
- Implement: change the controlled item and related artefacts.
- Verify: confirm the actual configuration matches the approved state.
- Account: update status records, release identity and change history.
- Audit: test configuration integrity where consequence requires it.
- Release: make the approved configuration available for intended use.
- Transfer: hand configuration ownership and records to the receiving organisation.
- Maintain: continue configuration control through operations where the product evolves.
This is a practical teaching cycle rather than a mandatory universal standard. Different sectors organise configuration management differently. The underlying integrity questions remain transferable.
58. A practical configuration review
- Which items require configuration control?
- What is the authoritative source for each?
- What is the current approved version?
- Which baseline contains it?
- Who can approve changes?
- Which changes are approved but not yet implemented?
- Which changes are implemented but not yet verified?
- Do downstream artefacts match the new state?
- Which configuration was tested?
- Which configuration is deployed or installed?
- Are superseded items clearly controlled?
- Do suppliers follow compatible configuration rules?
- Can the project reconstruct configuration history at any major decision point?
- Will operations receive accurate as-built or as-configured records?
- Who owns configuration after project closure?
59. The deeper idea
Project configuration management is the discipline of making reality reproducible.
A complex project changes constantly. Requirements evolve. designs mature. suppliers substitute. code releases. defects are repaired. procedures improve. field conditions force adaptation.
The purpose of configuration management is not to stop that change.
It is to stop change from destroying identity.
When configuration management works, the project can answer a demanding chain of questions without reconstructing history from memory: What exactly did we approve? What changed? Which version did we build? Which version did we test? Which version did we release? What does the operator have now? And can every important record still be traced to that reality?
That is what turns a changing project from a collection of moving files into a controlled evolving system.
Sources and boundaries
The configuration-management definitions and control principles in this article were checked against current PMI terminology and current NASA systems-engineering reference material in September 2026. The practical examples, lifecycle states, configuration-review questions and publishing/education applications are original explanatory structures and should be tailored to the project’s industry, safety, regulatory, contractual and technical requirements.
- Project Management Institute — Lexicon of Project Management Terms, Version 5.0. Current definitions for configuration management plan and configuration management system.
- Project Management Institute — Practice Standard for Project Configuration Management. Describes PCM as the collective processes, activities, tools and methods used to manage project items through the life cycle.
- NASA Systems Engineering Handbook — Configuration Management. Describes configuration identification, change control, status accounting, verification and the principle of keeping product and product information consistent.
- NASA Systems Engineering Handbook — Appendix M: CM Plan Outline. Provides guidance on configuration-management planning, roles, procedures, interfaces, suppliers and life-cycle review.