Sequencing and reconciliation prove I can plan. This page is where I show the parts of the job that are harder to fake: who I managed, what I watched for, and what I got wrong.
Stakeholder management
The RACI in Phase 01 tells you who was accountable for what. It doesn't tell you that a high-influence, low-interest CIO needs a different cadence than a high-interest, high-influence engineering lead — treating every stakeholder the same is how you either annoy your sponsor with detail they didn't ask for, or blindside a business owner who needed more.
Without a written stakeholder register, engagement defaults to whoever emails me first. Mapping interest against influence up front is what let me protect executive time while still giving hands-on owners the detail they actually needed.
| Stakeholder | Interest | Influence | How I engaged them |
|---|---|---|---|
| VP, Enterprise Analytics (Sponsor) | High | High | Bi-weekly steering deck; direct escalation path to me, no filtering through layers |
| CIO | Medium | High | Monthly one-page executive summary — budget and risk only, no operational detail they didn't ask for |
| Data Engineering Lead | High | High | Daily standup plus joint sprint planning — this relationship carried the technical risk of the whole program |
| Sales Finance SME | High | Medium | Weekly working session; named as field owner so decisions had a face, not just a role |
| Function business owners (×8) | Medium | Medium | Monthly function-specific update plus mandatory presence at their own UAT sign-off |
| QA Lead | High | Low | Daily standup — low formal influence, but the first person to know if the numbers were wrong |
The pattern I leaned on: match cadence and detail to the quadrant, not to who's loudest. The CIO got a page, not a deck. The QA Lead got a daily seat at the table despite no line-item authority, because they were my earliest warning system on data quality.
Risk management
The register itself lives in Phase 02, scoped to the technical risks that could break reconciliation. Here's the discipline behind it: how I scored, how often I reviewed, and what happened when a risk actually landed.
A risk register nobody revisits is just a document I wrote once to feel prepared. Scoring by probability × impact and reviewing weekly is what forced re-scoring as reality changed — R3 moved from Medium to High once the first wave's conversion sprint ran over.
| Severity | Probability | Impact | My review cadence |
|---|---|---|---|
| High | >40% likely | Threatens schedule, budget, or reconciliation accuracy | Weekly, named owner reports status to me directly |
| Medium | 15–40% likely | Recoverable with effort; no scope/date impact if caught early | Weekly, reviewed in RAID session |
| Low | <15% likely | Contained; monitoring is enough | Bi-weekly spot check |
The full register — including R1 through R6 and how each was mitigated — is in Phase 02: Architecture. Two risks materialized during the program: R2 (financial metric fails reconciliation) surfaced as the 6% grain-mismatch issue in Phase 03, and R3 (code conversion underestimated) is what led to the Wave 3 decoupling decision in Phase 03. Both were on the register before they happened — neither was a surprise I hadn't already named.
Lessons learned
The Phase 05 retrospective covers the program-level retro. These are the lessons that sit a level below that — the ones about how I personally ran things, not just what the program delivered.
A lessons-learned list that only names what went well is a highlight reel, not a retro. I kept the misses in here on purpose, because the next program is where they'd actually get fixed — or repeated.
| What happened | What I learned | What I do differently next time |
|---|---|---|
| SME time wasn't booked far enough ahead; it caused my one schedule slip | Availability is a resource I have to plan like headcount, not assume like goodwill | Reserve SME capacity per wave at planning, not at UAT |
| I initially ran change management as a Phase 05 activity in my head, even though the plan said day one | Plans don't protect against my own instinct to prioritize the technical build first when time gets tight | Put a change-management checkpoint on my own weekly review, not just the program's |
| Executives asked to waive the 0.003% variance for a date | "Small enough to wave through" is exactly the kind of ask that erodes a zero-tolerance standard if I don't hold it the first time it's tested | State the non-negotiables out loud in the charter, not just in my head, so I have something to point back to under pressure |