About this interactive
Change management is usually met as a list of eight words in a row — request, review, approval, testing, implementation, verification, documentation, closure — and a student who can recite that list still cannot say what has to already exist before any one of those steps can begin, or what each of them actually leaves behind. Closing that gap is what this set is for, and it is why no card opens with its step name. Each card describes the work and ends with what that step produces, so the vocabulary is attached to the behaviour rather than standing in for it. The chronology here is causal rather than conventional, and three constraints do most of the work. The first is that nothing is touched before somebody with the authority to say yes has said it. That single rule sorts the first five steps on its own: the request exists to create a written, owned, trackable proposal, because an undocumented change is not a small change but an invisible one; the review exists to turn that proposal into an understood one, assessing technical risk, business impact, the backout plan's actual executability, and the schedule conflicts with other work already booked against the same systems; and the approval is the moment a named accountable role fixes the scope, the schedule and the window. The requester almost never approves their own change, and that is separation of duties rather than bureaucracy — the reviewer's job is to find the cost that lands on somebody else, which is exactly what the person who wants the change is least placed to see. Approval is also what makes "unapproved change" a meaningful phrase: anything the work does beyond what was authorized is one, including the tempting "while I'm in here" fix that nobody thinks to look at when something breaks a week later. Standing pre-approval for a defined low-risk change type is not a way around this step; it is this step, decided once in advance instead of every time. The second constraint is that you rehearse before you perform. Testing comes before implementation because the environment that can be broken safely has to be used before the one that cannot, and because the rehearsal produces something implementation needs: the runbook — the ordered steps, the commands, the checks, the go/no-go points — so the person doing the work inside a maintenance window at 2am is following a script that has already succeeded once. Testing here is not only "does it do the thing"; it is also does the dependent service still work, does the monitoring still see what it saw before, and does the backout genuinely restore the previous state when it is executed rather than merely described. Implementation is then deliberately unglamorous: notify the stakeholders, take the pre-change backup so the backout has something to restore from, open the authorized window, follow the runbook as written, note deviations instead of improvising them, and honour the go/no-go points — a failed check partway through means executing the backout and rescheduling, not pushing on in the hope it settles. The third constraint is that a change is not finished when the work stops. Verification is a separate step from implementation because the work being done is not the same as the work having worked: the vulnerability actually closed, the capability actually available, the metric actually moved, and — the half students forget — nothing that was working before is now broken. That means watching the logs and monitoring for adverse effects across a defined observation period rather than a glance, and asking the affected users rather than reading silence as success. It is also the last moment at which backing out is cheap, because the window and the people are still there. Documentation follows because the environment has changed and every record describing it is now wrong until corrected: the diagrams, the configuration baselines, the CMDB entries for the affected configuration items, the runbooks and standard operating procedures, the version-controlled configuration, and the change record itself completed with what was actually done, which is regularly not identical to what was proposed. Documentation that lags is what turns a routine change into an outage six months later, because the review step of every future change reads exactly these records to assess dependencies and impact — and it is what the auditor asks for and what the responder reads first at 3am. Closure is then a review rather than a filing action: the change is confirmed complete and successful, or recorded honestly as failed, partial or backed out, because a process that only records successes measures nothing; the post-implementation review asks whether the risk and duration estimates matched reality and what should be done differently; and the metrics that come out of it — change success rate, emergency change rate, changes causing incidents — are what decide whether a change type earns standing pre-approval or more scrutiny next time. The set also answers the question students reliably ask at this point, which is what happens when there is no time for any of this. An emergency or hotfix change compresses the sequence; it does not delete steps from it. Review and approval shrink to an emergency authorization by a smaller group — often an emergency CAB convened in minutes, sometimes a single on-call authority acting under a pre-agreed policy — but somebody who is not the implementer still says yes, and the fact that they did is recorded. Testing shrinks to whatever can honestly be done in the time available, which is usually a smoke test and a confirmed backout rather than a full staging run, and the risk of that reduction is accepted explicitly rather than pretended away. Implementation and verification do not compress at all: the whole reason for the hurry is an effect somebody needs, so confirming that effect arrived is the point of the exercise. And documentation and closure are deferred, not skipped — completed retroactively, usually within a stated window, and reviewed harder than a normal change precisely because so much of the front of the process was traded away. The honest summary for a student is that an emergency change is more paperwork than a normal one, not less; the paperwork simply arrives afterwards. All 8 cards are presented on every run rather than sampled: this is the naturally finite domain the pool guideline makes an exception for — a lifecycle with a step removed is not a shorter version of the same object, it is a broken chain, and the chain is the entire skill being assessed. This pairs best with the module's own sequence — run it after Change Management (pspo-12-0020) and alongside Evaluation and Implementation (pspo-12-0040) and Monitoring, Documentation, and Closure (pspo-12-0050), so that the steps the cards separate are ones the student has already seen taught together.