What breaks when implementation departs from the approved plan

We noticed the approval gate started to break down at a very specific moment: implementation no longer matched the approved plan.

Work had begun. An unexpected dependency appeared. Someone now had to decide whether the change could continue.

That decision was hard to reconstruct if the original approval, the revision and the final acceptance hadn’t been recorded separately. The team could no longer answer three basic questions reliably:

• What was approved?
• Who could approve it?
• Which changes required another decision?

A recorded plan gives implementation and review a common reference point. It doesn’t, by itself, show that planning improves delivery.

Record the intent, not the code structure

We found it useful to focus the plan on decisions expected to remain stable during implementation:

• intended behaviour
• relevant business rules
• system boundaries
• failure handling
• testing strategy
• evidence required for acceptance

Product and engineering participants agree the outcome and constraints. The implementer still decides how to meet them within the repository.

Without that agreement, reviewers have to reconstruct more of the requirement from the implementation. By then, the code has a way of anchoring the discussion. Replacing an unsuitable approach looks more expensive once it has been built than choosing a different approach before work starts.

There’s a limit, though.

A plan shouldn’t prescribe incidental code structure. Too much detail takes longer to review, becomes stale and restricts implementation choices that don’t affect the agreed outcome.

The approval gate therefore needs to record three separate decisions:

1. Approve or reject the plan before implementation.
2. Continue, pause or seek renewed approval when a material change appears.
3. Accept or reject the completed change against the current approved plan.

Those aren’t interchangeable decisions. The control model needs an authorised role for each one rather than assuming that initial approval covers the whole lifecycle.

For each risk band, the rules should state:

• how the risk band is assigned
• who may approve the initial plan
• who may approve revisions
• who may give final acceptance
• whether the same role may make those decisions
• whether independent challenge is required
• whether implementation pauses while a revision is pending
• how unresolved disagreement is escalated
• what evidence final acceptance requires

A risk label on its own doesn’t tell anyone which controls apply.

Keep the decisions together

The table below is a proposed minimum record. It’s a template, not evidence that the control has operated.

Each approved version should link to the version it supersedes. If a record is missing, that gap should remain visible rather than being inferred from nearby entries.

This becomes particularly important when the plan changes. A material change affects either the approved intent or the basis on which it was approved.

These examples show the decision test. They don’t define the risk bands. Each organisation still needs operational criteria for assigning risk and identifying authorised approvers.

When a material change appears, the lifecycle record should capture the affected field, the reason, the revised risk classification, the work status, the decision and the plan version being superseded.

Consider a synthetic example.

1. A plan says that a component must reject invalid input without writing outside its declared boundary.
2. Acceptance requires a test showing the rejection and confirming that no external write occurs.
3. An authorised approver approves the plan under the assigned risk band.
4. During implementation, the engineer finds that the proposed path requires a write to an excluded component.
5. The engineer records the boundary change and requests reassessment.
6. Work continues or pauses according to the rule for that risk band.
7. The authorised revision approver accepts or rejects the new boundary.
8. Code review checks the implementation and tests against the approved version.
9. The authorised acceptance role records the final decision and links it to the evidence.

The external write is material because it changes the declared boundary. A local refactoring that preserves the rejection behaviour, boundary and acceptance test doesn’t require renewed approval.

Should the initial approval, revision approval and final acceptance come from one person or from separate roles? This example doesn’t answer that. The organisation’s authority rules have to do so.

Connect review to repository evidence

An approved plan reduces the amount of requirement discovery and business-rule interpretation needed during normal code review. It doesn’t remove either activity.

Review can still expose mistaken assumptions, missing requirements or dependencies that weren’t recognised during planning. Reviewers can ask:

• Does the implementation preserve the agreed behaviour and invariants?
• Are error paths handled as specified?
• Do the tests exercise every acceptance condition?
• Has the change stayed within its declared boundary?
• Is each material departure recorded and approved?
• Does the acceptance evidence refer to the current plan version?

If a finding changes behaviour, boundaries, risk or acceptance conditions, the plan needs reassessment. Otherwise, it can be handled as an implementation issue within the approved scope.

The repository also has to support the evidence named by the plan. Planning can’t make up for a validation process that can’t be reproduced or enforced.

A plan shouldn’t claim that evidence is repeatable unless the repository provides the mechanism needed to repeat it. The lifecycle record should connect the approved plan, implementing code, validation results, review findings and final acceptance decision.

Measurement is a separate problem

Comparisons between planned and unplanned work only make sense when every measure has an operational definition.

Teams need to define sizing, complexity and severity schemes before collecting results. Classifying them afterwards risks inconsistent comparisons.

Ambiguous records shouldn’t be forced into a category. Record them as unknown and explain why. A missing approval or acceptance record isn’t evidence of rejection, acceptance or the absence of findings.

Reports should include:

• definitions and reporting period
• planned and unplanned cohort sizes
• risk band, repository and scope
• change size and complexity
• first-pass and final acceptance results
• finding counts and classifications
• revision frequency
• approval latency
• missing and ambiguous records

Work should be compared with other work that has similar risk, repository and scope characteristics. Where direct matching isn’t practical, results can be grouped by those factors, with size and complexity reported for each group.

That may reduce unsuitable comparisons. It can’t show causation.

This is still a proposed control model built around a synthetic record. It doesn’t include a real change record, repository artefacts, operational risk-band rules, defined outcome measures or source-backed separation of approval roles. No governance, change-management or software-assurance standard is cited because no supporting source was provided.

For the same reason, we can’t justify a percentage about delivery performance without its source, population, numerator, denominator and definition.

The model gives us a way to record intent and test a completed change against it. Whether that improves delivery remains unanswered. Only complete lifecycle records and consistently defined comparisons can tell us.