Fasil PM logoFasil PMProject & IT ConsultancyBook a call

Everyone Agreed on the Outcome. Nobody Would Sign for the Path.

A program roadmap built on three levels of commitment, the data-profiling work stream that made one of them possible, and the political pull-forward resolved before it reached the room.

Programme
Project Falcon
Organisation
Atlas Bank
Phase
Planning
Template
Program Roadmap
AI prompt
Roadmap Drafting (RTF)
Post 05 of 22 following Project Falcon at Atlas Bank. Full program context is in Post 01. Previously: charter signed (Post 02), Stakeholder Register tiered (Post 03), Engagement Plan published with alignment mechanism (Post 04).

"I Cannot Commit a Date I Cannot Defend"

Charter Milestone 2 required a committed roadmap by 15 April 2025. That was seven weeks away. The program manager had booked a two-hour working session with Dmitri Volkov, the platform integrator delivery lead, to walk through the core banking integration schedule and land a date. Forty-five minutes in, the session had produced no dates.

"I cannot commit a date I cannot defend. Your core banking system has never been queried at platform transaction volumes. The existing integration baseline is from monthly batch reconciliations, not real-time microservice calls. If I sign for eight weeks of integration testing and the core turns out to be query-latency-bound under load, I am on the hook for a miss I had no way to predict."

The program manager's first instinct was to push anyway. Vendors often say they cannot commit when what they mean is they would prefer not to. But Volkov was not refusing. He was telling the PM something specific about the technical substance. The PM asked Priya Raman, technical lead, to join the conversation the next morning.

Raman's read, delivered in her own fifteen-minute working session on Day 46, made Volkov's position legitimate.

The technical substance Raman surfaced

Atlas Bank's legacy core banking system, procured in 2007, was never architected for the access patterns a 19-microservice platform would generate. The existing integration baseline was 14 nightly batch jobs and roughly 2,000 daytime query calls per hour from branch systems. Falcon would issue roughly 40,000 real-time calls per hour at v1 baseline, rising under peak loads. Nobody in Atlas Bank had representative data on how the core would behave at those rates. Volkov was not stalling. He genuinely could not commit eight weeks of integration testing when the core's behaviour under platform load was unknown.

The PM had two options. Option one: push Volkov to commit a date with a substantial risk reserve, and accept that the reserve would hide the uncertainty from the roadmap. Option two: make the uncertainty visible on the roadmap itself, and commission the work required to reduce it before the 15 April commitment date.

The first option was faster. The second was honest.

Three Levels. Not One.

The program manager went to Ahmed Hassan with a proposal on Day 47. Rather than publishing a roadmap with single dates that hid uncertainty, the Falcon roadmap would carry a Commitment Level field for every milestone. Three levels, labelled plainly so no stakeholder could mistake one for another.

The three levels

Committed  — Dates the program will be held to. Stakeholders may plan against them. Amendments require charter change control, which runs through the Board Risk Committee. These are the anchors.

Proposed  — Dates the program intends, subject to explicitly named assumptions. Amendments require steering committee approval, documented in minutes, communicated to Tier 1 within 48 hours. Still governance-level, but faster to move.

Indicative  — Dates the program is targeting, subject to substantial uncertainty. Amendments are PMO-level with steering awareness but not approval. Used for milestones where the uncertainty is a known input to the work ahead, not a confession of weak planning.

Every milestone on the roadmap would carry one of these labels, visible to every stakeholder, with the assumptions that qualified a Proposed or Indicative date written next to it. A stakeholder reading the roadmap would know exactly which dates they could plan against, which they should treat as intent, and which they should treat as targets.

The Volkov question now had a clean home. The core banking integration milestone could be recorded as Proposed, with an explicit assumption: “Subject to core banking query performance within 20 percent of profiled baseline, data profiling work stream completing by 14 March 2025.” Volkov could sign that. The roadmap would carry it as Proposed until profiling data was in, then convert to Committed at the next steering if the baseline held.

The second half of the solution was commissioning the profiling work stream itself.

Data profiling work stream, 24 Feb to 14 Mar 2025

Three-week work stream led by Priya Raman, resourced with two Atlas Bank core banking engineers and one integrator database specialist. Objectives: establish a representative baseline of core banking query latency under simulated platform load, identify any query patterns exceeding 500ms at p95, document the core's behaviour under concurrent access from multiple microservices. Budget: $42,000 from program contingency. Output: signed baseline document feeding the 15 March steering and unblocking Volkov's integration commitment.

By the time the roadmap went to steering on 28 March, profiling had completed. The core performed within expected bounds at baseline load. Volkov signed. The integration milestone converted to Committed at the 3 April steering, two weeks before the charter's 15 April deadline.

The Pull-Forward That Never Reached the Room

Samuel Osei had learned from kickoff. The direct scope request (Post 04, USSD-later) had not worked. On 18 March, three days before the roadmap workshop, Osei sent the program manager a note in Slack: “Worth checking if Market A can pull forward three weeks. Retail's Q2 board story needs an anchor date. Happy to discuss in the workshop.”

This was the out-of-cycle protocol doing its work. The Engagement Plan (Post 04) routed scope-adjacent requests to PMO written response, not to workshop agendas. Hassan saw the message, flagged it to the PM the same afternoon.

The pull-forward request was not unreasonable in isolation. Retail's Q2 board cycle ran mid-June. An anchor date in the Falcon roadmap would be valuable to Osei's own governance. But pulling Market A forward three weeks meant compressing UAT, which was the go-live gate Okonkwo held veto on, which meant the central bank certification window shrank from six weeks to three. That trade was not Osei's to make alone. It was a steering decision.

The program manager made a seven-minute phone call to Fatima Idris on the evening of 19 March. The call did three things: surfaced Osei's request, explained the UAT-compression consequence, proposed handling it upstream rather than in workshop.

"If this comes up in the workshop, Amara has to publicly defend the six-week UAT window against Samuel's P&L pressure. That puts her in a position I don't think she should be in on Day 73. I would rather you and I have a call with Samuel before Friday, make the trade-off visible privately, and publish the roadmap with Market A committed to its current window."

Idris agreed. The Idris-Osei-PM call happened on 20 March, thirty-five minutes. Osei understood the trade immediately, asked for a quarterly retail-specific readout he could use in his own board cycle (granted, added to the comms plan), and dropped the pull-forward request. The roadmap workshop on 21 March did not relitigate Market A dates.

What the Engagement Plan actually prevents

If the 18 March Slack note had been missed, Osei would have raised the pull-forward in the workshop. Okonkwo would have had to defend the UAT window in a public forum, potentially with mobile operators in the room. The conversation would have framed compliance as an obstacle to business delivery, which is the exact framing a regulated bank program cannot afford to normalize. The Engagement Plan's out-of-cycle protocol caught the request at the right altitude. Hassan flagged, PM resolved upstream with Idris, workshop ran clean.

Drafting the Roadmap

Prompt framework: RTF

The prompt below uses RTF: Role, Task, Format. Lightest of the frameworks used in the series so far. Roadmap drafting does not need CRAFT's context elaboration or RISEN's stepwise structure. The real discipline sits inside the Task: forcing the model to state what it does not know, not just what it knows. “Surface all assumptions and uncertainty drivers per milestone” is the instruction that does the work. Framework complexity matches task complexity; this task's complexity is an instruction, not a structure.

Prompt
ROLE. Experienced program manager drafting the first-pass roadmap for a $14.2M 18-month digital banking platform across three markets, 19 microservices, regulated environment. TASK. Build a roadmap covering Phases 1 to 4 (Initiation/Planning, Build/Integration, UAT/Certification, Controlled Rollout). For each major milestone, return: milestone name, target date or date range, dependencies, and COMMITMENT LEVEL (Committed, Proposed, Indicative). Use: - COMMITTED for milestones where all inputs are known, dependencies are under program control, and date defense would survive steering scrutiny today. - PROPOSED for milestones where the date depends on specified assumptions (name the assumptions explicitly) and is expected to hold if assumptions do. - INDICATIVE for milestones where substantial uncertainty remains, the date is a target rather than an intent, and planning should treat it as such. SURFACE ALL ASSUMPTIONS AND UNCERTAINTY DRIVERS per milestone. Do not hide uncertainty in reserves. If a date is a guess, label it Indicative. If a date depends on an upstream milestone or external condition, name the dependency. Flag any milestone where the commitment level is ambiguous based on the inputs provided. FORMAT. Markdown table: Milestone / Phase / Target / Commitment Level / Assumptions-Dependencies / Owner. Separate flagged items in a list at the end with rationale for the flag.

Roadmap Draft, Extract

A representative extract of the AI output, showing the commitment-level discipline at work. The full output covered 14 milestones across the four phases; the six shown below are where the commitment levels differed meaningfully and where the flagged items landed.

AI Response  ·  Roadmap Draft (Extract)
MilestoneTargetLevelAssumptions / Dependencies
Scale Plan signed
M2a
15 Apr 2025CommittedCharter tolerance deadline; both Alemu and Raman available.
Core banking integration complete
M3a
30 Sep 2025ProposedCore query performance within 20% of baseline. Profiling completing 14 Mar.
KYC pipeline live
M3b
15 Oct 2025ProposedNational ID SLA stabilizing at 4s per call by 1 Mar 2025.
UAT commencement
M4a
1 Jan 2026CommittedFixed by charter; buffer sized from integration completion.
Central bank certification
M4b
Mar 2026IndicativeCertification timing controlled by regulator, not program.
Market A go-live
M5a
14 Jul 2026CommittedCharter-fixed; board-approved.
Flagged for program manager review:

1. M3b (KYC pipeline live). National ID SLA assumption is optimistic. Public sources suggest typical SLA across comparable programs is 6 to 8 seconds at peak, not 4 seconds. Consider flagging this as an assumption-at-risk and requesting a fallback design (async KYC with pending-verification queue) before the assumption is tested in Phase 2.

2. M3a and M3b dependency chain. The draft treats these as parallel tracks, but central bank UAT (M4b) requires both to be complete and integrated. If either slips, UAT window compresses. The draft does not name this cross-dependency. Consider an explicit “M3a+M3b integrated” gate before M4a begins.

Program Roadmap, Extract

Extract of the published Program Roadmap v1.0, 28 March 2025. Six milestones shown from a total of fourteen. Every milestone carries its commitment level as a first-class field.

Program Roadmap
Version 1.0  ·  28 Mar 2025
Project Falcon: Phase 1 through Go-Live
Atlas Bank  ·  14 milestones, three commitment levels
Committed  Program will be held to. Amendments require charter change control (Board Risk Committee).
Proposed  Program intends, subject to named assumptions. Amendments require steering approval; minutes within 48hrs.
Indicative  Program targets, substantial uncertainty remains. Amendments PMO-level, steering informed.
MilestoneTargetLevelAssumptions & Dependencies
M2a Scale Plan signed 15 Apr 2025 Committed Charter tolerance deadline. Co-signed by CTO and Technical Lead.Profiling output feeds content; both signatories available.
M3a Core banking integration complete 30 Sep 2025 (±2 wk) Proposed Core query performance within 20% of baseline. Converts to Committed at 3 Apr steering if profiling (14 Mar) confirms baseline.Owner: Volkov. Converted 3 Apr 2025.
M3b KYC pipeline live 15 Oct to 30 Oct 2025 Proposed National ID SLA stabilizing at 4s p95 by 1 Mar. Fallback design (async KYC with pending-verification queue) required as Risk Register item R04.Owner: Okonkwo. Date range reflects SLA stabilization uncertainty.
M3x Integration gate (M3a + M3b) 7 Nov 2025 Proposed Explicit integration gate before UAT commencement. Added post-AI review. Both M3a and M3b must be signed off before M4a begins.Owner: PM. Human-added dependency.
M4a UAT commencement 1 Jan 2026 Committed Charter-fixed. UAT window 1 Jan to 31 Mar 2026.Owner: PM; Compliance gate on readiness.
M5a Market A go-live 14 Jul 2026 Committed Charter-fixed; board-approved; regulatory directive anchor.Owner: Sponsor; all upstream milestones feed this.
What the human changed from the AI draft
  1. Converted single dates to date ranges for Proposed and Indicative milestones. AI produced single dates with assumptions attached. PM converted to ranges (e.g., M3b “15 Oct to 30 Oct 2025”) where the assumption uncertainty translated directly to a date window. Committed milestones kept single dates.
  2. Added M3x, the explicit integration gate. AI flagged the M3a+M3b cross-dependency. PM elevated it to a named milestone with its own commitment level. Removed the “parallel tracks that happen to meet” ambiguity.
  3. National ID SLA fallback escalated to Risk Register. AI correctly flagged the optimistic assumption. PM routed it to Risk Register as R04 with the async-KYC pending-verification queue as response strategy (surfaces in Post 06). The roadmap references it by ID, keeping the roadmap itself concise.
  4. Osei pull-forward resolved upstream, not in workshop. This was a human move the AI had no visibility into. Resolution documented in roadmap appendix: Market A remains Committed to 14 Jul 2026; retail-specific quarterly readout added to comms plan.
August 2025 (month 7), what happened

The vendor dispute (first described in Post 01) centred on Volkov's integration team missing two consecutive milestones. Because M3a had been recorded as Proposed with explicit assumptions (core query performance within 20 percent of baseline) and then converted to Committed on 3 April after profiling confirmed those assumptions, the question at the month-7 dispute was not “did the program know this was uncertain” but “did the Committed date hold under the conditions Volkov signed for.” That is a contract question with a clean answer, not a credibility question with a political answer. The commitment-level discipline removed the scope-ambiguity defense that vendor disputes normally hide behind.

The Takeaway
A roadmap that hides uncertainty loses credibility. One that names it earns it.
Single-date roadmaps are a habit. They look decisive, they survive the first review, and they fall apart at the first contact with reality, at which point the program manager is defending dates that should never have been committed. Three commitment levels, assumptions named explicitly, and a mechanism to convert Proposed to Committed as uncertainty resolves, produces a roadmap that holds. Not because the dates are more accurate, but because the stakeholders know what to plan against.

A fictional case study for teaching purposes. Atlas Bank, Project Falcon and all named individuals are invented. Technologies are industry-standard and publicly available.