Every technology contract that ends in a dispute has a moment, usually months in, when someone produces the original proposal and reads out an assumption. "Integration with existing systems is limited to three interfaces." The supplier says that was the basis of the price. The client says there were always seven. Both are telling the truth as they understood it, and neither can show where their number came from.
That dispute was not caused by bad faith or bad estimating. It was caused by an estimate built on a description of the current state that nobody had checked. The fix is unglamorous: before anyone writes a proposal or a price, establish the facts the price depends on, from evidence, and carry them through every document so that a reviewer can trace each line back to its source.
Cedarberg Logistics is fictional, and its systems and figures are illustrative. The health check in Part 1 and the gap analysis in Part 2 gave the Cape Town cold-chain firm something most organisations going to market do not have: an evidence file describing its current estate. This part follows what that did to its request for proposal for a live temperature-visibility platform, and to the bids it received.
Where estimates usually come from
A typical request for proposal describes the current state from the latest architecture document, a few workshops and the memory of whoever is writing it. Suppliers then estimate against that description, adding contingency for what they suspect is missing. The client compares prices that rest on different guesses about the same estate, picks one, and discovers the real estate during delivery.
Cedarberg's own architecture document, the newest of three conflicting diagrams found in Part 3, showed three integrations around the transport management system. The health check had counted seven live ones: the telematics platform, the warehouse management system, the finance system, the customer portal, the data warehouse, an email and SMS notification service, and a scheduled export to one large customer. Four of the seven were not in any document.
Had the request gone out describing three, every bid would have been priced against an estate that did not exist.
Carry one counted fact all the way through
The discipline is simple to state. Each material fact about the current state is established from evidence once, given an identifier, and then referenced, not restated, wherever it drives a decision.
For Cedarberg, the integration count became a single traceable chain:
- Finding. Seven live integrations, with the configuration exports as evidence.
- Assumption. The request for proposal stated that all seven remained in scope and listed them.
- Scope. Each became a scope item: rebuild, rewire through the new platform, or leave untouched and test for regression.
- Effort. Suppliers were asked to estimate each scope item separately, as a range, rather than a single integration line.
- Price. The commercial schedule priced the same seven items, so the price and the scope could not drift apart.
- Acceptance. The acceptance criteria named the same seven interfaces and the test each had to pass.
When one of the bidders queried the scheduled export to a large customer, Cedarberg could answer in a day, with evidence, instead of issuing a vague clarification. The same structure is the client-side mirror of the supplier discipline described in architecture and price must describe the same solution.
Contradictions are cheaper before the bid
Evidence does a second job. It exposes contradictions between the documents that are meant to describe the same programme. Most organisations write the architecture, the scope, the schedule, the business case and the acceptance criteria at different times, with different authors. Each is internally reasonable. Together they disagree.
Cedarberg's pre-release review found four:
- Architecture against evidence. The design assumed three integrations; the estate had seven.
- Schedule against operations. The plan proposed a weekend cutover, but depots run around the clock and pharmaceutical consignments move on Sundays. There was no quiet weekend to cut over in.
- Cost against scope. The business case licensed 120 users, but the scope put the new driver app in the hands of all 180 drivers, plus controllers.
- Acceptance against architecture. The acceptance criteria required temperature data visible to customers within fifteen minutes, while the architecture retained the nightly file transfer for older trailers.
Each contradiction cost a meeting to resolve before the request went out. Found after award, each would have been a change request, a schedule slip or a dispute. The same check is worth running from the supplier side when reading a client's documents, as the hidden architecture of a good proposal argues.
Assumptions become a register, not a paragraph
Most proposals bury assumptions in a paragraph near the end. An evidence-led approach turns them into a register with four fields: the assumption, the evidence behind it, the consequence if it is wrong, and who confirms it. Cedarberg asked bidders to submit assumptions in that format and committed to confirming or correcting each one during clarification.
| Assumption | Evidence | If wrong | Confirmed by |
|---|---|---|---|
| Seven integrations in scope | Configuration exports, health check | Effort and price change per interface | Integration owner |
| Telematics vendor exposes a streaming feed | Vendor API documentation, version noted | Integration design changes | Fleet operations head |
| Cutover can run depot by depot | Operations calendar | Schedule and staffing change | Operations director |
| Vehicle-to-trailer record of truth is decided before integration testing | Gap analysis, conflict still open | Customer view shows the wrong trailer | Data owner, once named |
That table did more to reduce delivery risk than any amount of contingency. It also made the bids comparable, because every supplier was pricing the same confirmed facts. For a fuller treatment of the supplier side, see requirements, assumptions and traceability and the Architecture and Proposal Writing 101 series.
The trade-off
Evidence costs time before the procurement starts, and procurement timetables are often fixed by budget cycles. Cedarberg's evidence file existed because of the health check; an organisation without one has to decide whether a short discovery phase is worth delaying the release. The arithmetic usually favours it: a few weeks of discovery against months of change requests. Where the timetable cannot move, a smaller step still helps. Name the facts the price depends on, mark which are evidenced and which are assumed, and ask bidders to price the assumed ones as options. Discovery protects the date makes the same argument for delivery schedules.
A test for your next request for proposal
Choose the three facts about your current estate that would move the price most if they were wrong. For each, ask where the evidence is, whether every document that depends on it uses the same value, and who will confirm it to bidders. If any of the three has no evidence, you are about to run a procurement on a guess.
Next: Part 6, An audit finding is not a corrective action. All parts are on the series page.
How CloudNala can help
We help organisations establish the current-state facts a procurement depends on, carry them into the request for proposal as traceable assumptions, and check that architecture, scope, schedule, cost and acceptance criteria agree before release. On the supplier side, we review bids so that every line of the estimate can be traced to evidence or to a declared assumption.
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 a Technology Health Check or write to us at consult@cloudnala.co.za