Use this when you need to show a rollout as a sequence: milestones across the top, one card per phase with its goal, tasks, risks, and the exit bar that lets it advance.
This is a copyable exemplar. Lift the <section class="demo"> block below into a lesson built from assets/lesson-template.html — the design tokens already match.
A big change rarely happens all at once. You break it into phases that go in order, and you only move to the next phase when the current one clears its exit bar — the proof that it is safe to continue. The strip at the top is the map; each card below zooms into one phase.
Think of it like… moving house room by room. You don't empty the whole house onto the lawn. You pack one room, check nothing's broken, then start the next — and you keep the kettle plugged in until the very end so you can always make tea.
Project Single sign-on (SSO) rolloutWindow Q3 → Q4Owner Identity & Access team
Progress1 of 4 phases complete
Click a milestone — or focus the bar and use ←→ — to open its phase card.
Phase 1 · Done
Discovery
Weeks 1–3
Goal: Know exactly what logs in today, so nothing gets locked out tomorrow. Inventory every app, account, and login path before touching production.
Tasks
Inventory all apps and their login methods (SAML, OIDC, password, API key)
Map service accounts and shared logins that have no human owner
Pick the identity provider and confirm SCIM provisioning support
Draft the group → role mapping for least-privilege access
Exit criteria
Signed-off app inventory with an owner per app
Every login path classified as SSO-ready or needs work
IdP chosen and procurement approved
Risks & mitigations
MedShadow apps no one listedCross-check the inventory against SSO/proxy access logs. Mitigation: 2-week amnesty window to self-register apps.
LowOrphaned service accountsSome daemons log in with shared creds. Mitigation: tag each as machine identity; exclude from human SSO.
Phase 2 · In progress
Pilot
Weeks 4–7
Goal: Prove SSO works for real people on real apps — with the old password login still available as a safety net. Start with one volunteer team.
Tasks
Wire up the IdP for the 3 most-used apps (email, chat, code host)
Enroll the pilot team (~25 people) and turn on MFA
Keep password login as a fallback — do not disable it yet
Write the help-desk runbook for lockouts and recovery
Exit criteria
Pilot team logs in via SSO for 2 weeks with no blocking issues
Login success rate ≥ 99%; median time-to-login under 5s
Recovery flow tested end-to-end at least once
Risks & mitigations
HighIdP outage locks everyone outIf the provider goes down, no one logs in. Mitigation: keep password fallback on; document a break-glass admin account stored offline.
MedMFA fatigue & abandoned setupPeople skip enrollment or approve prompts blindly. Mitigation: number-matching prompts; live enrollment clinic; clear deadline.
LowGroup mapping mistakesA wrong group grants too much access. Mitigation: start read-only; review the access report before phase 3.
Phase 3 · Planned
Rollout
Weeks 8–13
Goal: Bring the whole company onto SSO, team by team, while the password fallback still exists. Breadth without breakage.
Tasks
Onboard apps and teams in waves (~2 departments per week)
Turn on SCIM auto-provisioning and de-provisioning
Migrate remaining "needs work" apps or grant exceptions
Stand up a self-service dashboard for status per team
Exit criteria
≥ 95% of staff active on SSO; remainder have a dated exception
Auto-deprovisioning verified: a removed user loses access within 1h
Help-desk ticket volume back to baseline
Risks & mitigations
HighLegacy app can't speak SSOAn old tool only supports passwords. Mitigation: front it with an access proxy, or grant a tracked exception with an end date.
MedHelp-desk overwhelmed by wavesToo many teams at once floods support. Mitigation: cap wave size; pause schedule if tickets exceed threshold.
Phase 4 · Planned
Enforce
Weeks 14–16
Goal: Remove the safety net. Turn off password login so SSO is the only way in — the step that actually delivers the security win.
Tasks
Disable password fallback, one app at a time, busiest last
Enforce MFA and conditional-access policies org-wide
Retire stale local accounts and rotate any leftover secrets
Keep the break-glass account; alert on any use of it
HighCutover locks out a critical roleDisabling passwords strands an unmapped account. Mitigation: stage cutovers off-peak; 30-min rollback window; on-call admin with break-glass access.
MedForgotten machine identitiesA cron job still uses a password. Mitigation: scan auth logs for non-SSO logins for 1 week before disabling each app.
What an exit criterion really is
An exit criterion is a measurable gate, not a feeling. "Pilot went well" is not a gate; "login success ≥ 99% over 2 weeks with the recovery flow tested" is. A phase cannot advance until every box is checked, which keeps the plan honest under schedule pressure.
Why the fallback survives until phase 4
The password path stays alive through Discovery, Pilot, and Rollout precisely so that a provider outage or a mis-mapped group never becomes a full lockout. Phase 4 ("Enforce") is the only phase that removes safety nets — which is why it carries the highest-severity risk and the tightest rollback window.
Reading the risk severities
High — can cause a company-wide lockout or data exposure; always paired with a rollback or break-glass mitigation.
Med — degrades the experience or floods support; mitigated by pacing and tooling.
Low — contained blast radius; mitigated by review steps.
The milestone bar as state machine
Each segment carries a status — done, active, or todo — and selecting one swaps the visible role="tabpanel". In a real lesson you'd drive these states from the project tracker so the bar reflects live reality rather than the plan as written.
Read left → right: each phase can only advance once it clears its exit gate. The password fallback (dashed) survives phases 1–3 and is finally cut at Enforce.