Fasil PM logoFasil PMProject & IT ConsultancyBook a call

A Business Case Promises Value. A Benefits Plan Is Where Value Gets Audited.

Three benefit categories with three owners, a $180K instrumentation bill nobody had budgeted for, and the attribution logic that separated program benefit from market tailwind.

Programme
Project Falcon
Organisation
Atlas Bank
Phase
Planning
Template
Benefits Plan
AI prompt
Benefits Draft (CIDI)
Post 08 of 22 following Project Falcon at Atlas Bank. Full program context is in Post 01. Previously, the Communications Plan (Post 07) was published with pre-approved templates and three operating modes, negotiated with Corporate Communications to bypass the 7-day review cycle on routine dispatches.

Three Owners, Nine Benefits, One Missing Baseline

The business case Atlas Bank approved in October 2024 listed nine benefits. The board had voted against those nine. The program had been delivering against three of them. The other six were somewhere between “assumed to follow from delivery” and “nobody has picked them up yet.” By Day 125, the Phase 1 closure gate had already slipped past, and the benefits question could no longer be deferred.

The program manager called a ninety-minute benefits working session on 20 May. Samuel Osei (Head of Retail), Thomas Richter (CFO), and Amara Okonkwo (Head of Compliance) were in the room, with Ahmed Hassan taking minutes. The agenda was simple: which benefits matter, who owns them, how are they measured. The meeting ran for two hours and twenty minutes, and for most of the first hour the three stakeholders were describing three different programs.

Three views, same business case

Osei (Retail). “The benefits that matter are customer acquisition, channel activation, transaction volume. Retail’s P&L depends on these. This is what the business case sold.”

Richter (CFO). “Acquisition is the glamorous number. The board approved Falcon on an 18-month payback model that depends on cost-to-serve reduction. Operational efficiency and channel migration are where the financial case actually lives. Those are what Finance will hold the program to.”

Okonkwo (Compliance). “Both of you are describing benefits that the central bank does not care about. The regulatory anchor for this program is the directive on digital financial inclusion. Financial inclusion reach, USSD uptake among underbanked segments, directive-aligned reporting quality. If these are treated as compliance checkboxes rather than first-class benefits, the program’s regulatory posture depends on outcomes nobody is tracking.”

All three were right. The business case promised revenue benefits, cost benefits, and regulatory benefits. The program had been instrumented for the first category and had quietly dropped the other two. That was not a scoping choice. It was an instrumentation failure that had been hidden by the absence of a benefits plan.

The PM recognised the pattern. A benefits plan that collapses into a single dollar figure will always be weighted toward the metrics the program is already instrumented to measure, because those are the numbers that can be argued for. The categories the program cannot measure drop off the register. That is how regulated programs deliver on paper and fail on audit.

Three Categories. Three Owners. Three Horizons.

The design that closed the working session, delivered by the program manager at the two-hour mark, had three structural commitments and refused to collapse them into one.

The three benefit categories

Revenue  Customer acquisition, channel activation, transaction volume. Owner: Osei. Realization horizon: first 12 months post-launch. Measurement: customer account opens by channel, active users by market, transaction count and value trends.

Cost  Cost-to-serve reduction, operational efficiency, channel migration from branch to digital. Owner: Richter. Realization horizon: 18 months post-launch. Measurement: cost per transaction, branch-to-digital migration rate, operations headcount re-deployed.

Regulatory  Financial inclusion reach, USSD uptake among underbanked segments, directive-aligned reporting quality. Owner: Okonkwo. Realization horizon: 24 months post-launch. Measurement: new accounts from underbanked geographic segments, USSD session volume as proportion of total, central bank reporting quality score.

Each category has its own owner, its own measurement methodology, its own baseline, and its own realization horizon. The plan refuses to aggregate them into a program-level benefits number because they mature on different clocks. Revenue benefits are visible in the first quarter post-launch. Cost benefits compound over eighteen months. Regulatory benefits take two years to demonstrate meaningfully because financial inclusion is a behaviour change metric, not a transaction metric.

The second structural commitment was attribution logic. Every benefit had to specify how the program’s contribution would be isolated from background market shift. If customer acquisition rises 15% in the first year post-launch and the regional mobile banking market grew 12% over the same period, attributing all 15% to Falcon is wrong. The plan required every benefit to specify its attribution method: comparable-market cohort, pre-post with control group, or direct-causal-trace where possible.

The third commitment was the one the PM had not anticipated coming in.

You cannot measure a benefit you have not baselined

Priya Raman raised it in the technical follow-up the next morning. The business case numbers had been built from directional estimates, not measured baselines. To actually demonstrate cost-to-serve reduction, the program needed the current cost-to-serve baseline by channel and transaction type, measured from live data rather than modelled from accounting summaries. To demonstrate financial inclusion reach, the program needed a baseline of current underbanked-segment reach, measured from branch and agent-network data.

None of that baseline existed in a form the benefits plan could use. The core banking system produced nightly batch reports. The branch systems produced manual reconciliation files. Raman estimated roughly $180,000 of instrumentation work across the reporting layer and the branch data feeds to stand up measurable baselines by 30 June 2025. That was work nobody had scoped. The program had two choices: defer the baselining (cheaper, but undermines the benefits plan) or pay for it now (draws on contingency, protects measurability).

The program manager authorised the instrumentation work the same afternoon. $180,000 drawn from the unallocated contingency reserve (Post 06), bringing the reserve from $530,000 down to $350,000. First drawdown against the reserve.

Why this is a preventive investment, not a scope expansion

The $180,000 is 8.5 percent of the unallocated reserve. It is large enough to justify explaining in the Benefits Plan itself, not just absorbing quietly. The framing that went to steering: benefits audit failure is a regulatory risk category tied to R01 (regulatory requirements change mid-build). A program that cannot demonstrate directive-aligned benefits at audit has the same regulatory consequence as a program that missed a directive change. Preventing that failure mode is preventive risk response, which is exactly what contingency is for. The revised contingency position would carry through to the next quarterly review, where the reserve level would be re-evaluated against new risk identifications (foreshadowed: Post 17 surfaces the quarterly review explicitly).

Drafting the Benefits Plan

Prompt framework: CIDI

The prompt below uses CIDI: Context, Instruction, Detail, Input/output example. CIDI earns its slot here because benefits planning has a non-intuitive output structure: categorised benefits with separate owners, attribution logic, and different realization horizons are not the default pattern an LLM produces when asked for a “benefits plan.” The default is a single consolidated list. The Input/output example dimension is the one that forces the model into the structure the PM actually wants. CIDI is less widely cited than CRAFT or RISEN, but for tasks where the structure is harder to describe than to demonstrate, the example dimension does the work other frameworks do not.

Prompt
CONTEXT. Project Falcon, a $14.2M digital banking platform at Atlas Bank, mid-Phase 1 (May 2025). Business case approved October 2024 listing nine benefits across revenue, cost, and regulatory tracks. Current state: program instrumented for revenue benefits only; cost and regulatory benefits have been treated as delivery byproducts rather than tracked outcomes. Three senior stakeholders (Head of Retail, CFO, Head of Compliance) hold partial views of what the benefits should be. INSTRUCTION. Produce a Benefits Plan that covers all nine benefits across three categories. For each benefit, specify: category, description, baseline value and baseline date, target value, measurement methodology, owner function, realization horizon, dependencies on program milestones, and attribution logic (how program-caused benefit is isolated from background market shift). Categories must remain separate; do not collapse to a single program benefits number. DETAIL. Three categories are REVENUE (acquisition, channel activation, transaction volume), COST (cost-to-serve reduction, operational efficiency, channel migration), REGULATORY (financial inclusion reach, USSD uptake among underbanked, directive-aligned reporting quality). Revenue horizon: 12 months post-launch. Cost horizon: 18 months post-launch. Regulatory horizon: 24 months post-launch. Each benefit should have a named single owner from the function that carries the consequence if the benefit does not land. INPUT/OUTPUT EXAMPLE. For benefit B01 (customer acquisition via smartphone app): Category = Revenue. Description = Net new customer accounts opened through the Falcon smartphone app. Baseline = 0 (new channel). Baseline date = N/A. Target = 60,000 accounts across three markets by month 12 post-launch. Methodology = Account-opens reporting feed from the core banking system, filtered to channel = Falcon App. Owner = Head of Retail. Horizon = 12 months post-launch. Dependencies = Market A go-live M5a, KYC pipeline live M3b. Attribution = Direct-causal; channel filter makes program contribution unambiguous. Return 8 to 10 benefits in the same structure. Flag any benefits where attribution logic is weak, measurement requires instrumentation the program does not yet have, or realization horizon depends on milestones not in the current roadmap.

Benefits Draft, Extract

The AI produced nine benefits. Six shown below across the three categories. Three flagged items are shown in full, including the one that surfaced the instrumentation gap.

AI Response  ·  Benefits Plan Draft (Extract)
IDBenefitCategoryTargetOwnerHorizon
B01Net new accounts via appRevenue60,000 accountsOsei12 months
B02USSD transaction volumeRevenue4.2M trans/qtrOsei12 months
B04Cost per transaction (digital vs branch)CostReduce 38%Richter18 months
B05Branch-to-digital migration rateCost45% of qualifying txnsRichter18 months
B07Financial inclusion reachRegulatory120,000 new accts underbankedOkonkwo24 months
B08USSD uptake underbanked segmentsRegulatory60% of underbanked activeOkonkwo24 months
Flagged for program manager review:

1. B04 (Cost per transaction reduction) baseline gap. The 38% reduction target requires a current cost-per-transaction baseline by channel and transaction type. Current finance reporting produces cost allocations at the department level, not per-transaction. This benefit cannot be measured against its target without instrumentation work on the cost-allocation model. Estimated scope: reporting layer changes and transaction-level cost mapping. Not in current plan.

2. B07 (Financial inclusion reach) attribution logic weak. “New accounts from underbanked segments” requires defining what underbanked means in each market, measuring the pre-program underbanked reach, and isolating Falcon’s contribution from general market mobile banking growth. Comparable-market cohort attribution is the most defensible approach but requires identifying a non-Falcon comparable for each of the three markets. Not trivial.

3. B05 (Branch-to-digital migration) and B08 (USSD uptake) interaction. These two benefits may compete: if underbanked customers are pulled into USSD rather than app, migration-to-digital looks strong but branch-to-digital migration looks weak. The plan should explicitly consider whether these benefits reinforce or undermine each other, and whether the targets are independently achievable.

Benefits Plan v1.0, Extract

Published 23 May 2025. Nine benefits across three categories, six shown below. Instrumentation work stream committed ($180K, 23 May to 30 June 2025). Contingency position updated.

Benefits Plan
Version 1.0  ·  23 May 2025
Project Falcon: Benefits Plan
Atlas Bank  ·  9 benefits, 3 categories, 3 owners
Program Contingency$2,130,000
Allocated to Named Risks$1,600,000
Unallocated Reserve$350,000was $530K; $180K drawn for instrumentation
Revenue Customer acquisition, channel activation, transaction volume Horizon: 12 months post-launch
Benefits Realization Owner: Samuel Osei, Head of Retail Banking
IDBenefitBaselineTargetMethodologyAttribution Logic
B01
Net new accounts via app
0 accounts
(new channel; baseline is structural)
60,000 across 3 marketsAccount-opens feed filtered to channel = Falcon AppDirect-causal. Channel filter makes program contribution unambiguous.
B02
USSD transaction volume
0 txns
(new channel)
4.2M txns per quarterUSSD gateway logs, aggregated quarterlyDirect-causal for USSD; pre-program baseline is zero.
B03
Active users by market
0 users
(at launch)
100K in 90 days (charter)Monthly active user count, 3 markets separatelyDirect-causal. Contributes to charter commitment.
Cost Cost-to-serve reduction, operational efficiency, channel migration Horizon: 18 months post-launch
Benefits Realization Owner: Thomas Richter, Chief Financial Officer
IDBenefitBaselineTargetMethodologyAttribution Logic
B04
Cost per transaction reduction
TBB 30 Jun 2025
To-be-baselined; instrumentation in flight
38% reduction vs baselineCost-per-transaction model, by channel and txn type (new instrumentation)Pre-post with control group: branch-heavy markets serve as partial control for channel migration effect.
B05
Branch-to-digital migration rate
TBB 30 Jun 2025
Branch txn volume by type
45% qualifying txnsBranch transaction volume tracked against pre-launch baseline; digital-eligible subsetPre-post with market growth adjustment; comparable-market baseline applied.
B06
Operations headcount redeployed
TBB 30 Jun 2025
Branch ops FTE count
85 FTE redeployedHR headcount tracking by role and marketDirect-causal within redeployment categories; defined list of affected roles.
Regulatory Financial inclusion reach, directive-aligned reporting Horizon: 24 months post-launch
Benefits Realization Owner: Amara Okonkwo, Head of Compliance
IDBenefitBaselineTargetMethodologyAttribution Logic
B07
Financial inclusion reach
TBB 30 Jun 2025
Agent-network reach
120K new accounts underbankedNew-account geodemographic classification against underbanked definition per marketComparable-market cohort: two non-Falcon regional markets as control; adjust for general mobile banking market growth.
B08
USSD uptake underbanked segments
TBB 30 Jun 2025
Current underbanked activity
60% underbanked activeUSSD session analytics cross-referenced with underbanked classificationDirect-causal for new USSD channel; comparable-market adjustment for general behaviour change.
B09
Directive-aligned reporting quality
Current CB score: 3.2/5
Last assessment Q4 2024
Score 4.5 of 5Central bank quarterly reporting quality score (existing methodology)Direct-causal; existing CB score is stable pre-program, program effect is visible.
What the human changed from the AI draft
  1. Categorised the nine benefits into three tracks with separate owners. AI produced a consolidated list. PM split into Revenue (Osei), Cost (Richter), Regulatory (Okonkwo), each with its own realization horizon. Benefits could no longer be silently de-prioritised by being averaged into a program-level number.
  2. Added attribution logic as a first-class field. AI produced targets and methodologies. PM added attribution column for every benefit: direct-causal, pre-post with control, or comparable-market cohort. No benefit could claim program contribution without a stated method for isolating it from market shift.
  3. Commissioned the $180K instrumentation work stream. AI flagged the cost baseline gap. PM authorised the full instrumentation: cost-per-transaction model, branch data feed, agent-network reach baseline. Work stream 23 May to 30 June 2025. Drew from unallocated reserve; reserve now $350K.
  4. Extended realization horizons differently per category. AI defaulted to “by go-live” for several benefits. PM set Revenue at 12 months, Cost at 18 months, Regulatory at 24 months. Different benefits mature on different clocks; pretending otherwise overstates what the program will demonstrate at any single point.
  5. Flagged B05 / B08 interaction for monthly review. AI correctly surfaced that branch-to-digital migration and USSD uptake among underbanked can compete. PM added a monthly review note: if USSD uptake exceeds target and branch migration lags, the benefit plan must reconcile whether the program is succeeding on inclusion at the cost of digital migration, and report both honestly rather than picking one narrative.
March 2026 (month 14), what happened

Richter’s Q4 2025 finance review, conducted in mid-March during UAT, found that cost-to-serve reduction (B04) was tracking at 22% against the 38% target at the twelve-month-progress mark. Because the Benefits Plan had Richter as named owner with an 18-month realization horizon and a defined pre-post-with-control-group methodology, the variance became a finance review agenda item with a clear resolution path (review the methodology, adjust the target if the market baseline had shifted, or accelerate the branch-to-digital migration lever). It did not become a program credibility crisis. It was not reported to steering as “Falcon is failing.” It was reported as “B04 is at 22% of 38%; trajectory suggests 30% at horizon; recommend methodology review.” That is what categorised benefits ownership does for a program: it keeps variance from being mistakenly attributed to the whole.

The Takeaway
A benefits plan is an audit commitment, not a sales narrative.
Collapsed into a single number, benefits become a marketing statement. Separated into categories with named owners, measurement methodologies, realization horizons, and attribution logic, benefits become something the program can actually be held to. Baselines require instrumentation; instrumentation costs money; the cost belongs in the plan. Variance in one category does not mean failure of the program. The discipline is to know which number is moving, why, and who owns the response.

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