Plan the landing before you fly
REF ACC-RLL-900OWNER Delivery PracticeUNIT Waves
Access change programmes touch every working day of the organization, so the rollout deserves as much care as
the design. We sequence the work into waves by function and dependency, define what success looks like after
each one, and hold a rollback position that is tested and understood before a wave begins.
Nothing moves on the strength of optimism. Each wave has entry criteria, exit criteria, a named owner and a
support arrangement for the days that follow.
How we build the wave plan
REF ACC-RLL-920STEPS SixARTEFACT Runbook
- Inventory and grouping. List the populations and systems, then group them by similarity of need and
tolerance for interruption rather than by org chart.
- Dependency mapping. Identify what must exist before a wave can run: directory changes, zoning,
approvals, support cover, and any data we need in place.
- Pilot wave. A small, willing cohort goes first, chosen so that problems surface early and cheaply.
- Communication. A short, plain notice for each wave: what changes, what people will notice, what to do
if something feels wrong, and where to ask for help.
- Cutover and hypercare. A defined window, a checklist, and elevated support for a set period after the
change, with a daily stand-up until the wave is stable.
- Exit and review. Exit criteria confirmed, lessons recorded, and the next wave adjusted before it
starts.
Rollback and contingency
REF ACC-RLL-940POSITION TestedTIMING Defined
Every wave carries a rollback position: the exact steps, the owner, and the point beyond which rolling back is
no longer sensible and we fix forward instead. We test the rollback in a rehearsal environment before it is ever
needed for real, because a recovery plan nobody has practised is a paragraph, not a plan.
Where a change risks interrupting critical operations, we arrange a maintenance window and a fallback path so
that the affected teams can keep working while the change settles.
Handing over cleanly
REF ACC-RLL-960CLOSE DocumentedSUPPORT Retainer
The programme ends with a close-out pack: the final architecture as built, the rules and policies in force,
the runbooks, the support model and the lessons recorded. Your team can then run the model unaided, and our
retainer, if you keep one, shifts from delivery to monitoring and review.
Deliverables · wave plan, dependency map, communication pack, cutover checklists, tested
rollback positions, hypercare rota and the close-out pack.
Communication is where most rollouts are won or lost. A wave that goes perfectly but surprises people still
generates support calls and erodes trust, so we treat the notice as a deliverable in its own right. It is short,
it is written in plain language, and it always answers the same three questions: what is changing, what you will
notice, and who to contact if something feels wrong.
We also plan for the questions that arrive after a wave, not only for the change itself. A short list of
likely queries, with answers prepared in advance, means the support team can respond in minutes rather than
raising a ticket and waiting on a design decision.