A seven-line transformation programme, prototyped before any contract
How we outlined a seven-line operational transformation programme for a multilateral development bank and prototyped the cockpit and plan navigator to steer it. Proposal stage: none of it is contracted or in production.
Context
A multilateral development bank that finances public infrastructure was heading into sustained portfolio growth. By the client's own figures, the operations carried by each project lead had roughly doubled over several years while technical teams stayed about the same size. Hiring was authorised, but not in proportion.
Leadership set one condition: working faster could not cost process quality, because fiduciary responsibility is not negotiable. IT added a second. Earlier AI experiments built outside security policy had been paused for months while they were brought into line. Anything new had to start from IT's requirements.
The challenge
The pains ran along the lending lifecycle. Audited financial statements from executing agencies arrived in a seasonal wave and were read by a handful of specialists. Senior staff assembled loan documents by hand from scattered inputs, and execution dashboards were fed manually. Bidding documents were checked against procurement policy clause by clause before a no-objection could be issued.
That pattern invites a familiar failure: several promising pilots, no shared architecture, and no view of sequence, dependencies and load on people. Before asking which agent to build first, we asked what the whole programme looks like and how it would be steered.
Our approach
This was proposal-stage work, done before any contract. It rests on one in-depth session with an operations sponsor and a conversation with operations leadership and IT; technology leadership then reviewed it. We had seen no internal norms, templates or files, and pains were recorded as reported, not verified. What follows is a set of hypotheses to be tested.
- 1Group pains into workstreamsSeven candidate lines on one template: challenge, proposed solution, agent capabilities, expected impact. Three lanes: efficiency, data, risk and governance.
- 2Fix the rules for every lineFour pillars: fiduciary integrity, alignment with IT and security, an interface in the client's visual language, data governance.
- 3Show it instead of describing itA browser-based prototype replaced the slide deck: a cockpit with one view per workstream and a navigable plan.
- 4Propose a paid discovery before any buildShort and separately priced, with IT, compliance, legal and process quality at the table, before any construction budget is fixed.
What was proposed and prototyped
The programme
- Fiduciary supervision. Extraction from audited statements, deterministic reconciliation against the ledger, a drafted supervision report.
- Loan document drafting. A single source of truth for inputs; first drafts in institutional templates for senior staff to edit.
- Execution monitoring. Site evidence and progress reports turned into data, to compare physical and financial progress.
- Pre-committee quality gate. An in-house checklist tool evolved to test logical and economic consistency.
- Procurement conformity. Clause-by-clause comparison of bidding documents with policy; a drafted no-objection report.
- Environmental and social screening. Document and geospatial screening; a suggested risk category for a specialist to confirm.
- Institutional memory. Retrieval over completion reports that surfaces past risks, with citations, during drafting.
The plan navigator
The plan is one dataset shown three ways. The Gantt view places a discovery phase and the seven lines a month apart. Swimlanes group them by lane; the kanban lays milestones out by quarter. Clicking a line opens its month-by-month stages. The start date is an editable parameter: change it and every bar and quarter recomputes.
The cockpit
The prototype has eight views: one per workstream and a control tower showing operations by lifecycle stage and bottlenecks. The supervision view sets figures extracted from an audited statement beside the ledger, each row marked accept, justify or investigate. The drafting view cites the source page behind every generated suggestion. The monitoring view shows an alert when disbursement runs ahead of verified works. In the quality-gate view the certificate button stays disabled while a blocking item is open.
Those interaction patterns (source on click, human override, visible blockers) were the purpose of the prototype. The numbers on screen were invented.
Results and status
At the time of writing. The only work contracted afterwards was a separate discovery, outside this case.
From the plan navigator. Estimated before any internal document or system had been reviewed.
Proposal figure. The discovery the client later contracted separately was scoped at about twice that.
There are no outcome figures in this case: the table holds a status count and plan durations. Nothing was built against client data. What the work produced was one navigable picture of the programme, which the operations sponsor and technology leadership could question line by line in place of a slide deck.
The client's next step was to contract a separate discovery to test the hypotheses and reduce the candidates to a short list. That engagement is outside this case; we make no claim about its results. The start date assumed in the plan passed without a programme start. Our horizon was questioned as optimistic at the time, and we now agree.
The proposal described impact directionally: review cycles from months to days, no-objections from weeks to days. No measured baseline stood behind those statements. Our later review found two documents giving different magnitudes for one workstream, and wording that committed to outcomes before anything had been measured. The proposal's adoption calculator is left out here for the same reason: a slider position with no client baseline would be read as a result. We now set no numeric target before measuring the baseline and how often human reviewers disagree.
Governance and risk
Humans keep every material decision. In the design, agents extract, reconcile, pre-validate and draft; people accept, reject and sign. An early internal brief treated an adverse audit opinion as an automatic block. Our later review made it a recommendation with an accountable human decision, and the design logs every value a reviewer corrects.
IT sets requirements first. We offered a depth-of-stack menu: the enterprise cloud the institution already trusts, a private cloud, or its own models, which we advised against for this timeline. Models would be chosen per task by benchmark, client data used at inference only and not for training, and code owned by the client through technology transfer. These are proposal commitments, not yet exercised.
Reuse before replacing. The institution held barely used AI assistant licences and an in-house checking tool worth evolving. Our later review concluded that line cannot be sized responsibly without access to the code and a security review.
What we learned
- Outline the programme before the first agent. Sequence, dependencies and load across lines matter more to operations leadership than any single demo.
- Make the start date a parameter. Procurement at public institutions moves at its own pace; a plan that recomputes stays a working tool.
- Label every mock-up screen as a simulation and keep impact claims directional until a baseline exists. Precise-looking numbers get read as results.
Client identity, locations and identifying details are withheld under confidentiality. Figures are rounded. Measured figures come from engagement records; client-reported figures are attributed, not audited; modelled figures are projections from the engagement's business case and are labelled as such.