“Configuration Management in Projects: A Plain-English Guide”

What is configuration management in plain English?

Configuration management is the set of rules and records that tell you, at any moment, exactly which version of which deliverable is the approved one — and what happened to every version before it. It applies equally to software, drawings, specifications, contracts, and a marketing campaign’s assets.

The plain-English version: if two people disagree about which file is current, configuration management is the thing that settles it without a meeting.

Systems engineering defines it more broadly — a discipline applied across a product’s life cycle to provide visibility into, and control over, its configuration (SEBoK). The definition matters because it makes clear that this is not a filing habit. It is a control system with roles, records, and decision points.

Three terms carry most of the weight:

• A configuration item (CI) is any artifact placed under control. Not everything is a CI; selection is a deliberate decision.
• A baseline is an approved, frozen snapshot of a set of CIs at a point in time.
• Change control is the route a proposed modification takes before it becomes part of the product.

> Important note: configuration management is not version control software, and buying a tool does not install the discipline. A repository with no naming rules, no approval route, and no status field is a very well-organised mess.

What are the five functions of configuration management?

There are five, and skipping any one breaks the chain. They are usually described as planning, identification, change control, status accounting, and verification.

The order matters less than the completeness. A small project can run all five on a spreadsheet and a shared folder. A large one needs tooling. What it cannot do is run four of the five and hope.

What counts as a configuration item?

A configuration item is anything whose change would need to be coordinated with other people. That practical test scales better than a policy list.

For a construction project, CIs typically include drawings, specifications, the bill of quantities, approved submittals, schedules, and the contract itself. For software: source code, build configuration, infrastructure definitions, database schemas, and release notes. For a marketing programme: brand assets, approved copy, legal disclosures, and published pages.

Two rules keep the list honest. Control the interfaces, not every file — the items that matter are the ones other people depend on. And review the CI list at each phase gate, because a document that needed no control in concept design may be contractual by tender.

What is a baseline, and why does it matter?

A baseline is an agreed snapshot used as the reference for future change. It converts “the design” from a moving argument into a fixed reference point that a change can be measured against.

Most projects recognise three baselines, though small projects often collapse them:

• Functional baseline — what the product must do, agreed with the client.
• Allocated baseline — how the requirements are distributed across components or packages.
• Product baseline — the detailed definition used for build, manufacture, or release.

A baseline does three useful things: it gives a defensible answer to “what did we agree?”, it gives change control something to compare against, and it gives you an audit trail when a dispute arrives eighteen months later.

What a baseline is not is a ban on change. Teams resist baselining because “frozen” sounds like a bureaucratic wall. The correct framing: a baseline is a checkpoint, not a cage. Change is allowed; it simply has to be visible, estimated, and approved by someone with authority to accept the consequence.

> Common mistake: baselining a design that is not actually coordinated. A baseline over conflicting drawings freezes the conflict and makes every later correction a formal change. Baseline when the package is consistent, not when the calendar says so.

How does change control actually work?

Change control is a five-step loop: request, assess, decide, implement, verify. Rigor should scale with the consequence of the change, not with the seniority of whoever requested it.

1. Request. A change request records what should change, why, who raised it, and what happens if it is not made. One form, one ID, one date.

2. Assess. Someone estimates impact on cost, schedule, quality, risk, and other CIs. This is where most informal processes fail: the change is approved before anyone works out that it touches four other packages.

3. Decide. An authority approves, rejects, or defers. Define thresholds in advance — the project manager up to $10,000, the sponsor up to $100,000, the board beyond that. A change board helps when changes interact; it is ceremony when they do not.

4. Implement. Change the controlled item, increment the version, and update every affected document in the same action. A change that updates one drawing and forgets the specification has made things worse.

5. Verify. Confirm the change was made as approved, that downstream items were updated, and that the record is complete. Then close it.

Two habits make this survive. No approval without an impact statement, even a two-line one. And no implementation without a version increment — if the version number does not change, the change did not happen as far as anyone downstream is concerned.

What naming and versioning scheme should you use?

Use a scheme that encodes type, project, sequence, and status — short enough that people type it correctly. Long conventions fail because humans abbreviate them under time pressure.

A workable document identifier: `PRJ-ATL-STR-DWG-0142`.

• `PRJ` — document type (project record)
• `ATL` — project code
• `STR` — discipline or workstream
• `DWG` — artefact type
• `0142` — sequential number, never reused

Versioning is where most schemes collapse. The rule that survives: major.minor, with a status flag.

Add a status and location field and you have the four attributes that make a register useful: ID, version, status, location. Without status, a register is a list of files. Without location, people keep local copies.

> Practical tip: print the version and status in the title block of every drawing and the footer of every document. If the version is not visible on the artifact itself, someone will build from a superseded printout and no register will save you.

What does this cost, and what does the absence cost?

Configuration management costs hours. Its absence costs rework, disputes, and sometimes the whole margin.

Example 1: the wrong revision. A façade subcontractor builds from drawing A-201 Rev B. Rev C, issued eleven days earlier, moved two anchor points by 150mm. Nobody printed Rev C because the transmittal went to a project manager on leave. Correction needs 14 crew-days of removal and reinstatement, plus engineering sign-off: 14 × $640 = $8,960, before the schedule impact on the following trade. The control that would have prevented it: a transmittal log and a 15-minute weekly check.

Example 2: time spent establishing truth. In a 25-engineer team, an audit finds people spend an average of 8 minutes a day confirming which document is current. That is 25 × 8 = 200 minutes daily, or 3.3 hours. Over 220 working days: 733 hours a year. At $65 per hour loaded, $47,645 of engineering time answering a question a register should answer instantly.

Example 3: audit sample. A register holds 120 configuration items. An audit samples 20 and finds 3 not at the current approved revision — a 15% error rate. If that rate holds, roughly 18 items are wrong. The audit takes four hours; discovering the same thing during a client review costs more.

Example 4: what right-sized looks like. A 12-person software team runs configuration management for 40 CIs — repositories, environment definitions, schema migrations — using its existing Git host at no extra cost, with pull-request approval and a weekly 20-minute change review. Total overhead: roughly 3% of engineering time. That is the honest answer for most small teams: cheap when built into the workflow, expensive when bolted on afterwards.

Does configuration management only apply to engineering projects?

No. The same discipline applies wherever an artifact is approved and then reused, which includes most professional work.

Construction. Drawing registers, submittal logs, and revision control on specifications. The contractual stakes are high, and the register is often the first document requested in a dispute.

Software. Source control, environment configuration, dependency pinning, and release management. The CI list is largely automated here, which is why software teams often underestimate how much configuration management is implicit in their tooling.

Marketing and contracts. Approved brand assets, legal disclosures, published pages, and the executed version of an agreement with its amendments. The failure mode is identical: someone reuses last quarter’s approved claim after legal withdrew it.

Configuration management vs change management vs asset management

The distinction that matters: change control decides whether to change; configuration management records what the product now is. A project can approve a change and still fail to update the product record — which is how a project ends up with an approved change and a build that ignores it.

What are the common mistakes?

• Controlling everything. When every file is a CI, nobody maintains the register. Control the items other work depends on.
• Letting the tool do the thinking. Version control tracks revisions; it does not decide which one is approved. That is a human decision recorded in a status field.
• Approving changes in chat. A decision without a record is a memory. Every approval needs an ID and a date.
• Updating the drawing but not the specification. Changes propagate. If the impact assessment does not list affected items, the change is incomplete.
• Skipping the audit. Without verification the register drifts, and drift is worse than no register because people trust it.

When is configuration management overkill?

It is overkill when a deliverable has no downstream consumer, no contractual reference, and no cost of being wrong. Forcing formal control on a one-week workshop deck teaches the team that the discipline is theatre.

Scale it deliberately:

• Light — a naming convention, one shared location, and a version in the filename.
• Standard — a CI register, a change request form, a weekly change review, and quarterly spot audits.
• Formal — a configuration management plan, a change board, status accounting reports, and scheduled audits.

Move up when the cost of a wrong version exceeds the cost of the process. If it would cost more than a day of rework, or be visible to a client or regulator, formal control is justified.

How do you start in the next two weeks?

Start with the register, not the policy. A policy describes behaviour you do not yet have; a register pays off the first time someone asks which version is current.

Week 1. List the ten artifacts that would cause most damage if the wrong version were used. Give each an ID, version, status, location, and owner. That is your first CI register, and it takes about three hours.

Week 1, second half. Write one page: naming convention, version rules, and who approves changes at what threshold.

Week 2. Run one change end to end, including the impact statement and the version increment. Then audit five random items against the register and fix what you find.

Where does tooling fit?

Configuration management is a records problem, and records need a home everyone can reach. The most common failure is not a missing standard; it is a register in one person’s spreadsheet, a document library nobody can search, and a change log in an email thread.

That is the gap Doitify addresses: project documents with owners, versions, and status; tasks and sub-tasks that carry the change through to implementation; checklists for the impact assessment; and work reports showing which changes are open, approved, or overdue. Because it also holds the schedule and task board, the register and the work it controls stay together instead of drifting apart.

Doitify is our product, so treat that as a description of fit rather than an independent review. A team with twenty documents and one reviewer can run configuration management perfectly well in a shared folder with a disciplined naming rule.

Conclusion

Configuration management is unglamorous insurance. It does not make the design better or the build faster; it makes the record trustworthy, which is what lets everything else be coordinated without a meeting per question.

Start small. Build a register of the ten items whose wrong version would hurt most, give each an ID, a version, a status, and a location, and route one change through a form this week. Then audit five items and fix what the audit finds. That loop — register, change, audit — is the whole discipline, and it scales from a five-person team to a regulated capital programme without changing shape.

If this post on configuration management was helpful, you might also enjoy How to Get Your Team to Actually Use Project Management Software and Project Management Software for Ecommerce Teams: 2026 Guide.