The Charter Was Signed Before the Scope Was Clear

About This Series

This is a 22-post series that follows a single fictional program, Project Falcon at Atlas Bank, from inception through closing. Each post covers one decision point, one framework, one template, and one AI prompt used to navigate the moment. Across the series, the same technology stack, the same stakeholder cast, and the same financial baseline carry through, so the program evolves as a traceable whole rather than twenty-two disconnected lessons.

Project Falcon at Atlas Bank

Atlas Bank, a mid-sized universal bank across three markets, is delivering a national digital banking platform. One platform, three markets, two channels (smartphone app and USSD). Three fixed commitments: core banking transactions across both channels, a KYC and AML pipeline tied to the national identity authority, and central bank regulatory reporting. Everything else is negotiable.

Five Days to Draft a Charter

The program sponsor was named on 28 January 2025. The sponsor expected to sign a charter by 2 February. That was five working days. Tight but not impossible for a charter of this size. The problem was not the clock. The problem was that the scope underneath the charter was still a rumour.

The three platform commitments were fixed. Core banking transactions across both channels. KYC and AML pipeline integration. Central bank regulatory reporting. These were in the business case, in the board minutes, and in the central bank directive. They were not going to move.

Everything underneath those three was still being negotiated. Which market went live first. Which features were in v1 versus v2. What the integration surface with the legacy core banking system actually looked like. Whether the USSD channel launched with the app or staged behind it. How much performance headroom the Kubernetes cluster needed on Day 1. None of these had clean answers yet. Several would not have clean answers until mid-Phase 2.

The Kubernetes cluster sizing debate, surfacing inside the engineering team that same week, made the problem concrete. It was the first real test of whether the charter could hold authority without forcing premature decisions.

How Big Should the Cluster Be on Day 1?

Every microservices program of this scale hits the same question early: how do you size the Kubernetes cluster when you do not yet know the real traffic shape? Under-size and Phase 2 stalls on provisioning. Over-size and three months of budget walks out the door before a single transaction runs on the platform.

On Falcon, the debate surfaced between two of the strongest technical voices on the program.

Both positions were defensible. The CTO was protecting the budget. The Technical Lead was protecting the delivery. Each was right about the risk they were pointing at. Neither was wrong.

The program manager's temptation in that moment was to pick a side. It was the wrong temptation. Picking a side on Day 21 commits the charter to a decision that should be made later in planning, after more data. But leaving it unresolved creates a charter that reads as evasive. Neither produces a document that a sponsor can sign with confidence.

The answer was in a different place. Not in the commitments, but in the tolerances.

Commit to Outcomes. Tolerate the Path.

On the afternoon of Day 21, the program manager sat with Ahmed Hassan in the PMO's corner office, looking at two versions of the charter draft. The first version was named a Day-1 cluster size. The second did not. Hassan, with twelve years of Atlas Bank governance experience behind him, read both and put the second down first.

"If you commit to a cluster size in the charter and it turns out to be wrong, every amendment after this goes through the Board Risk Committee. You will be explaining yourself for six weeks."

"And if I leave it out?"

"You write language that says the decision will be made, when it will be made, and who will make it. You anchor the outcome, not the path."

This is the move. It sounds obvious in retrospect. At the moment, with the sponsor expecting a signed document in three days and two executives holding defensible opposing positions, it did not feel obvious at all. The temptation was to split the difference and write a Day-1 number that nobody would love, but everybody could live with. That temptation is how charters become brittle.

The program manager chose to hold the line. The charter would commit to three things about the Kubernetes question and tolerate one.

The same logic resolved market sequencing, v1 versus v2 features, and USSD launch timing. Each is committed at the outcome level, tolerated at the path level. By the evening of Day 23, the charter was a four-page document with three firm commitments and seven explicit tolerances. The program manager sent it to Idris at 9:47 that night. She countersigned the following morning.

Drafting Charter Language from an Ambiguous Brief

A program charter of this scale typically takes three to five days to draft properly. The program manager had five days. Using AI to generate a first-pass draft from the structured inputs available (business case, sponsor interview notes, steering committee scope discussions, the three platform commitments) compressed the first-draft cycle from a day and a half to about three hours. Human review and revision still took the remaining time, which is where most of the quality actually lives.

Scope Boundaries, First Draft

The AI output for the Scope Boundaries section, showing the CRAFT framework produced content that distinguishes commits from tolerances in the structure the PM requested. This is an unedited first draft. Human revision followed.

The output was useful but not final. The program manager revised three things before the section went into the charter: the out-of-scope list was re-ordered so the most politically sensitive exclusion (corporate banking portal) was listed second, not third, to reduce skim risk; "end of Phase 1" was made explicit (15 April 2025) in every clause; and the capacity-review trigger was tightened to "sustained utilization over any 72-hour window at the service tier" after Priya Raman pointed out that looser wording could be gamed.

Program Charter, Version 1.0

The full Program Charter was signed on 2 February 2025 (Day 19). Every commitment, every tolerance, every date, and every named authority below carries forward into the rest of the series. This is the document the program executed against for the next 18 months.

What the Tolerances Bought

The charter was signed on 2 February 2025. Kick-off happened on 7 February (Day 24). Within three weeks of kick-off, the program had produced draft answers to everything the charter had tolerated: a market sequencing plan, a v1 feature allocation, and a joint-signed Scale Plan from Alemu and Raman (baseline cluster sized for 2x v1 projected load, documented expansion plan triggered at 70 percent sustained utilization).

None of this would have been possible if the charter had specified a Day-1 cluster size. The Scale Plan conversations were better conversations than the charter-draft conversations would have been, because they happened with more data and lower political stakes.

Ahmed Hassan pushed back during draft review on what he saw as under-specification: why not name market sequencing now, why not set the v1 feature list. The answer was the same for all. A charter that commits what detailed planning should commit has to be amended when planning disagrees with it. Amendments erode sponsor confidence. Tolerances, properly triggered, preserve it.