Project Delivery · Project Control Methods
Project Issue, Change and Configuration Control
Issue and change control prevents approved products and plans from drifting through informal requests, defects or unrecorded decisions. It classifies what has happened, verifies the affected baseline, assesses impact across the project, develops options, routes the decision to the correct authority and keeps product configuration and records aligned after implementation.
Executive summary
What this guide enables
Issue and change control prevents approved products and plans from drifting through informal requests, defects or unrecorded decisions. It classifies what has happened, verifies the affected baseline, assesses impact across the project, develops options, routes the decision to the correct authority and keeps product configuration and records aligned after implementation.
Learning outcomes
- Classify requests for change, off-specifications and problems or concerns.
- Protect product baselines through configuration identification, status and verification.
- Perform proportionate impact analysis across all project objectives and value.
- Route, implement and verify decisions without losing traceability or delegated authority.
Control guidance
Why projects need integrated issue and change control
Projects exist to create change, but the change-control discipline in this guide concerns changes to the project's approved baselines. Once a product description, plan or management approach is authorised, an alteration can affect cost, time, quality, scope, benefits, risk, contracts, operations and dependent products. Informal acceptance of 'small' changes can accumulate into loss of control even when no single request appears material.
An issue is a relevant event that has happened, was not planned and requires management consideration. Three useful issue types are a request for change, which proposes an alteration to a baseline; an off-specification, where a product is forecast or known not to meet its approved description; and a problem or concern, which requires attention but is not yet one of the first two types. A risk that occurs becomes or creates an issue. A routine action can remain in a daily log when it does not need formal control.
The change control approach defines how issues are captured, classified, assessed, decided, implemented, reported and closed. It names decision authorities and any delegated change budget. The configuration approach defines how products are identified, baselined, versioned, protected, status-reported and verified. These disciplines must interact: a decision to change without configuration control leaves uncertainty about which product changed; configuration control without decision control can preserve the wrong baseline perfectly.
| Issue type | Meaning | Example pattern | Primary decision |
|---|---|---|---|
| Request for change | Proposal to alter an approved baseline | Add, remove or modify a requirement or product | Approve, reject, defer, seek information or escalate |
| Off-specification | Product will not or does not meet its approved description | Criterion failed or agreed component unavailable | Correct, concede, change baseline, defer or escalate |
| Problem or concern | Other event requiring management attention | Dependency conflict, resource concern or stakeholder complaint | Guide, correct, create another issue type or escalate |
Control guidance
Establish the product and configuration baseline
Configuration management identifies the project's products, their versions, relationships, owners and authorised states. The configuration item record can include identifier, title, description, owner, source, current version, status, approval, location, linked products and change history. The level of configuration control should follow product complexity, criticality, contract and audit needs. Not every working note needs formal configuration status, but every product whose version affects delivery or acceptance must be identifiable.
A baseline is an approved snapshot used for control. It should be protected from uncontrolled amendment while remaining accessible to authorised users. Version numbers alone are not enough; status such as draft, under review, approved, superseded or withdrawn explains how a version may be used. Interfaces need particular care because a change in one product can invalidate design, test or acceptance evidence elsewhere.
Status accounting reports the current and historical state of products and issues. Verification checks that the actual product and records match the authorised state. These controls matter at work-package completion, stage boundaries, release, acceptance and closure. When a change is implemented, all affected descriptions, plans, records, tests and dependent configurations must be updated coherently.
Configuration baseline essentials
- Unique product or configuration identifier
- Current approved version and status
- Owner, producer, reviewer and approver
- Location and access control
- Linked requirements, products and interfaces
- Quality and acceptance evidence references
- Issue and change history
- Verification and audit status
Control guidance
The five-step issue and change procedure
- 1
Capture
Record the issue promptly, perform initial analysis, identify the affected product or objective, classify it and decide whether formal handling is required.
- 2
Assess
Verify the baseline and analyse impact on products, time, cost, quality, scope, benefits, risk, operations, contracts, resources and other projects.
- 3
Propose
Develop feasible response options, including do nothing where legitimate, with costs, risks, consequences, authority and recommendation.
- 4
Decide
Route the decision to the person with delegated authority, documenting approval, rejection, deferral, request for information, concession or escalation.
- 5
Implement
Authorise the selected action, update products and baselines, perform required verification, communicate the result and close only when evidence is complete.
Communication operates throughout the procedure. Urgent safety or containment action may be required before full assessment, but emergency action and subsequent authority should still be recorded. The process should be scaled: a low-impact change can use a short standard form and delegated decision; a material change may require technical, commercial, user, benefit, risk and assurance analysis before governance decides.
The issue register is the control index, not the full evidence store. It should link to the affected product, analysis, decision and implementation evidence. The daily log can hold informal concerns and actions, but items should move into the formal register when they affect a baseline, need wider decision or require sustained tracking.
Control guidance
Perform decision-ready impact analysis
Impact analysis begins by confirming the authorised baseline and the exact requested or observed deviation. Ambiguous requests should not proceed to cost estimation until the desired outcome and affected product are clear. Identify direct effects, then trace dependencies through product, schedule, resource, contract, operational and benefit relationships. Include the impact of analysis and implementation itself.
Assess all six performance dimensions. A request may have negligible build cost but materially weaken quality, increase operational risk or delay benefits. An off-specification may be acceptable technically but violate user acceptance or contract. A correction may restore product compliance while causing a stage exception. The business case and risk profile should be updated when decision significance warrants it.
Options should be comparable and feasible. Common options are reject, implement as requested, implement a modified response, defer to a later stage or release, correct the product, grant a controlled concession, seek more information, prepare an exception plan or refer to a higher authority. State who bears cost, who owns residual risk and by when a decision is needed.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| What is the baseline? | Approved product or plan identifier, version, criteria and decision history | Confirm the control reference |
| What changes or fails? | Precise request, observed result, cause and affected interfaces | Classify and contain |
| What is the total impact? | Time, cost, quality, scope, benefit, risk, contract and operational analysis | Compare response options |
| Who can decide? | Delegated change authority, budget, tolerances and external obligations | Decide locally or escalate |
| How is completion verified? | Updated configuration, tests, approvals, plans and communication | Close or return for action |
Control guidance
Decision authority, tolerance and change budget
Decision authority can be delegated by issue type, impact, product, value or tolerance. The project manager may decide corrections and minor changes inside the authorised stage and change budget. A governing body decides changes that affect the project baseline, business case, acceptance or stage tolerance. The commissioning authority may be required where project tolerance, policy, funding or strategic commitments are affected. Contract, regulatory and safety decisions may require additional named authorities.
A change budget is an amount reserved for the analysis and implementation of approved changes. It does not make every request affordable or automatically approved. Define who controls it, what it covers, any per-change limit and how remaining budget is reported. Small changes can still create large cumulative scope or support consequences; monitor trend and aggregate impact.
Tolerance is not a hidden change allowance. A scope or quality tolerance permits an agreed range around the baseline; a request outside that range requires decision. Even inside tolerance, a change may need configuration and communication control. Conversely, a high-value change can be approved when justified and authorised; control is about conscious decision, not preventing all change.
Decision authority is valid only when issue type, cumulative impact, tolerance, budget, product authority and external obligations are all within the delegate's remit.If any dimension exceeds authority, escalate with the completed impact analysis rather than splitting the request to avoid review.
Control guidance
Implement and verify the decision
An approved change becomes authorised work. Update the relevant plan and work package, assign actions and resources, modify product descriptions and configuration items, and schedule quality activities. Communicate the decision to affected producers, reviewers, users, suppliers and governance. Withdraw or mark superseded information so teams do not continue from an obsolete baseline.
Verification confirms that the selected option was implemented as decided and that all affected evidence remains valid. Retest or re-review where configuration impact demands it. Update cost, schedule, risk, benefit and quality forecasts. If the implementation creates a new issue or forecast tolerance breach, control it separately rather than hiding it under the original approval.
Closure requires more than marking the issue complete. Record decision, implementation evidence, actual impact, residual actions, configuration status and lessons. Some issues remain open at project closure and must be transferred to operational or programme owners with acceptance of consequence and a follow-up date.
Change implementation verification
- Decision and authority are recorded
- Affected product descriptions and versions are updated
- Plans, work packages, cost and resources reflect the work
- Dependent products and interfaces have been reviewed
- Required tests, reviews and acceptance are complete
- Superseded information cannot be used accidentally
- Risk, benefit and business-case impacts are current
- Stakeholders received the decision and changed baseline
- Residual actions and lessons have owners
Control guidance
Worked scenarios
Controlling an apparently minor user request
Situation: During testing, a user asks for an additional reporting field. Development effort appears small, so the delivery team proposes adding it immediately.
- The request is captured against the approved product version before code is changed.
- Impact analysis identifies data governance, training, test, interface and support consequences that are larger than the coding effort.
- A modified option meets the user need using an existing field and stays within delegated stage authority; the change budget and configuration are updated.
- The changed version is retested and the user decision is recorded before the issue closes.
Control outcome: The project remains responsive without allowing a small visible task to bypass its wider product and operational consequences.
Deciding an off-specification
Situation: A fabricated component misses a non-safety dimensional criterion but can still fit after a controlled interface adjustment. Replacement would threaten stage time tolerance.
- The product and criterion are verified, the deviation contained and dependent interfaces identified.
- Technical, user, quality, schedule, cost and residual-risk impacts are assessed, including future maintenance and interchangeability.
- The authorised product owner grants a one-item concession with identification and inspection conditions; the interface adjustment follows controlled change.
- Configuration records, acceptance evidence and lesson about the manufacturing method are updated.
Control outcome: The decision is traceable to one product and does not silently relax the criterion for future components.
Does every issue need a formal report?
No. Low-impact matters can be handled informally within delegated authority, but anything affecting a baseline, wider decision or sustained tracking needs controlled capture.
Is a change budget contingency?
Not necessarily. A change budget funds approved changes under defined authority; contingency addresses uncertainty. The organisation may structure reserves differently.
Can a product description be changed after approval?
Yes through the authorised procedure, with impact, version, affected evidence and acceptance implications controlled.
Who closes an issue?
The designated issue owner or project manager according to the approach, after verifying implementation and residual actions—not merely when a decision is made.