Process · Change Management

Triage every change. Integrate only the approved ones.Five phases around a Change Control Board.

Undisciplined change is the largest single risk to test completion. This process defines the Change Control Board loop (from intake through final approval) so nothing slips into a release untested or unscored.

Phases
5
Sub-steps
6
Governance body
Change Control Board
Every change is a proposal to trade one set of risks for another. The CCB is the forum where that trade is made explicit, and therefore reversible.

Key takeaways

Four things to remember.

  1. 01

    Gather before you triage

    A single intake queue for changes and bug fixes prevents shadow prioritization inside individual teams.

  2. 02

    Assess cost, schedule, and risk together

    A change that is cheap to implement can still be expensive to test or to release. Evaluate all three dimensions at intake, not after implementation.

  3. 03

    Decide at the board, not at the desk

    The whole point of a CCB is that prioritization and rejection happen in one forum with all stakeholders present. Out-of-band approvals corrupt the signal.

  4. 04

    Approve inclusion, not just completion

    Even a successfully implemented and tested change must clear a second gate before shipping, because the world may have changed while you were building it.

Why this exists

The problem this process fixes.

Change during a release is the default. The question is whether that change arrives through a clean process or through shadow channels, late bug fixes jammed in on Friday, feature flags flipped mid-cycle, "just one more thing" from a product owner after sign-off.

This process replaces the shadow channels with a Change Control Board loop. Five phases, one governance body, and two explicit gates: one at intake, one before inclusion. The result is a release whose contents can be defended.

The checklist

11 steps, in order.

  1. 1

    Gather requested changes and bug fixes proposed for inclusion in the current, a future, or an emergency system release.

  2. Phase 2

    Review proposed requests during a regular or emergency change control board meeting, via e-mail, or by conference call.

  3. 2.A

    Assess associated feature, budget, schedule, and quality benefits, costs, issues, and risks for implementation, testing, and release. Defer consideration to a subsequent meeting and obtain clarifying information if necessary.

  4. 2.B

    Prioritize or reject each request.

  5. 2.C

    Identify implementation, testing, and release integration deliverables, and estimated completion dates for each request.

  6. 3

    Plan, implement, test, and integrate the change or fix, noting new costs, benefits, issues, or risks.

  7. Phase 4

    Present implementation, testing, and release integration results and deliverables for final approval.

  8. 4.A

    Assess outstanding feature, cost, schedule, and quality costs, benefits, issues, and risks.

  9. 4.B

    Weigh benefits of including change against costs, issues, and risks.

  10. 4.C

    Approve or reject inclusion of the change in appropriate release.

  11. 5

    If approved, check new or changed system components, project documents, and other deliverables into configuration management.

One more thing

The cost of change control is felt at intake; the cost of skipping it is felt at release. Teams that treat the CCB as optional will eventually release a change they could not have defended, and the first release after that is when discipline becomes easy to enforce.

Take it with you

Download the piece you just read.

The library is free. Tell us who you are so we can send you updated versions. One form; this browser remembers you after that.

In the library

Pair this with.

Keep reading

Related reading

Practices

Where this leads

Working on something like this?Talk to the people who wrote it.

Book a call