Open almost any technology proposal and you will find the same order. Who we are. What we can do. Our methodology. A reference architecture. A great many diagrams. The team. The price. It is a perfectly logical order for the person writing it, because it follows how a supplier thinks about itself. It is a poor order for the person reading it, because it is not how a decision gets made.
A decision-maker, whether an investment committee approving an internal programme or a bid evaluation panel scoring a tender, works through a sequence of questions. Is there a real problem? What is the evidence? What are the options? Which one do you recommend, and why? How do we get there? What will it cost, what could go wrong and what do we get? A proposal that answers those questions in that order is easy to approve. One that makes the reader assemble the argument from forty diagrams is not, however good the diagrams are.
This final part connects the discovery work of the first five parts to the document that has to carry it.
The decision path
Business problem. The problem statement, in the client's terms, with its baseline and target. If the reader does not agree with this step, nothing above it matters.
Evidence and constraints. What discovery found, and what cannot change. This is what makes the problem credible rather than asserted.
Options and trade-offs. The realistic alternatives, including doing less, and why each was or was not preferred. This is the step most proposals skip, and skipping it makes the recommendation look like the only idea anyone had.
Recommended design. The option chosen, explained through the views from Part 5, starting with the journey.
Transition plan. How to get from today to the target, through which bridge states, with what rollback.
Cost, risk and value. What it costs, what could go wrong, and what the business gets, measured against the problem statement at the bottom of the staircase.
Each step depends on the one beneath it. A proposal that opens with the recommended design asks the reader to start on the fourth step without the three that justify it.
Klipspringer's paper to the investment committee
Klipspringer Bank is fictional, and its systems and figures are illustrative. The board's original request, in Part 1, was an 18-month programme to modernise the loan application and move it onto a cloud platform, with an illustrative budget of R95 million. After discovery, the architecture team went back to the investment committee with something rather different. The paper followed the decision path.
The problem, in numbers. Of about 6,200 completed applications a month, 35% leave before a decision. Decisions take five to seven working days, of which roughly two hours is actual work. Each lost applicant has already cost about R1,900 to acquire. The target: same-day decisions for at least 60% of applications and abandonment under 15%, with credit losses, fraud referrals and affordability documentation held at their current levels.
The evidence. The joined-up funnel, the waiting-time split, twenty calls to customers who had left, and the finding that existing customers were being asked to upload bank statements the bank already held.
Three options. The paper set out three, honestly:
| Option | What it does | Why it was or was not preferred |
|---|---|---|
| A. The original request | Rebuild the application and migrate the journey to cloud | Highest cost and longest timeline; improves the form, which is not where customers leave |
| B. Process fixes only | Assign queue ownership, review the two-signature threshold, chase documents faster | Cheap and quick, but cannot reach same-day decisions without changing how documents and rules are handled |
| C. Targeted change | Option B, plus upload-time document checks, internal data for existing customers and a versioned decision service | Moves both measures, reuses the two largest systems, and can be delivered in stages |
Including option B mattered. It showed the committee that the team had considered spending less, and several of its process changes were folded into option C anyway, because they cost almost nothing and started reducing waiting time within weeks.
The recommended design. Option C, presented journey first, then target components, trust boundaries and the operations view.
The transition. Four bridge states over about nine months, the first of them, queue ownership and upload checks, live within ten weeks.
Cost, risk and value. An illustrative R34 million, against the R95 million originally requested. The main risks named plainly: the loan system's nightly batch, adoption by underwriters, consent handling for the use of transaction data, and the broker migration. The value stated in the problem statement's own terms: if abandonment falls from 35% to 15%, about 1,240 more completed applications a month reach a decision, and at current approval and acceptance rates that is roughly 700 more loans a month.
The committee approved it in one meeting. Not because it was cheaper, though it was, but because every question they would have asked was answered in the order they would have asked it.
The same content in a different order
What is striking, putting the first version next to the final paper, is how much of the content was the same. Both described the systems. Both had a target architecture. Both had costs. The difference was almost entirely order and emphasis.
The diagram-led version began with the bank's technology strategy and the cloud platform, and reached the abandonment figures on page fourteen. The decision-led version began with them. Nothing was hidden in either. One simply made the reader do the work of building the argument.
When you are the bidder
Everything above applies with more force when you are a supplier responding to a tender or a request for proposals. The evaluator is often reading several submissions against a scoring scheme, under time pressure, and cannot ring you to ask what you meant.
A few adjustments help.
Restate the problem in the client's numbers, not yours. If the tender includes data, use it. If it does not, show you understood the problem better than the specification did, and say how you would confirm it in the first weeks. Our proposal-writing series covers how to read the client, the procurement and the room.
Show options even when the tender specifies a solution. You may have to bid what was asked for. You can still show, briefly and respectfully, that you considered alternatives and why the specified approach does or does not fit the outcome. Evaluators notice bidders who think.
Map every section to the evaluation criteria. The decision path is the logic; the scoring scheme is the structure the panel has to use. Make it trivially easy to find where each criterion is answered.
Price the same solution you described. A surprising number of proposals describe one design and price another. Our piece on how to estimate and price the same solution covers this.
And before any of it, decide whether to bid at all. If discovery tells you that the tender is asking for a technology rather than an outcome, and that you would be delivering the request rather than solving the problem, that is useful information for the bid/no-bid decision.
The thread through the series
This series started with a bank that asked for a cloud migration and needed faster decisions. Everything after that was about keeping hold of the real problem as the work moved from discovery to design to the document that asks for approval: turning words into numbers, running business discovery before technical discovery, deciding each capability's fate on its merits, choosing views that let a decision be made, and presenting the argument in the order decisions are actually taken.
None of it is new, and none of it needs a framework licence. It needs the discipline to locate the delay before choosing the technology. Most of the time, the technology then turns out to be a smaller and better-defined part of the answer than anyone expected.
Key points
Follow the reader's questions, not the writer's. Problem, evidence, options, recommendation, transition, cost and value.
Always show options, including doing less. It makes the recommendation credible and often improves it.
Most of the content does not change. The order and emphasis decide whether a proposal gets approved.
Bidders need the same discipline, mapped to the scoring scheme. Restate the problem, show alternatives, price what you describe.
Locate the delay before choosing the technology. The thread through all six parts.
Back to the start: Part 1, The client asked for cloud. The problem was approval time. All parts are on the series page. For the proposal craft in depth, see Architecture and Proposal Writing 101, and for what happens when the technology does involve AI acting on your cloud estate, see AI for Cloud Operations.
How CloudNala can help
We help internal teams and bidders turn discovery into a document that gets a decision: a problem statement in the client's numbers, honest options, a recommendation explained through the views that matter, a staged transition and a cost case tied back to the outcome. Whether it is an investment committee paper or a tender response, the aim is the same, to make the decision easy to take.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Discovery Sprint or write to us at consult@cloudnala.co.za