There is a moment in many bid evaluations when an evaluator puts the architecture diagram next to the price schedule and starts ticking boxes. The integration layer is on the diagram: is it in the price? The data migration is mentioned in section 7: which work package pays for it? Training is promised: for how many people, and where is it costed?
When the two documents describe different solutions, one of three things is true. The diagram is aspirational, the price is incomplete, or the bidder has not noticed. None of those help the evaluator trust the bid.
This part is about making the architecture, the delivery plan and the price describe exactly the same thing.
We are still following Rivermark Water, a fictional regional water utility buying a Customer Self-Service and Case Management Platform, and Ridgeline Digital, the fictional delivery partner bidding for it. The RFP gives an indicative budget of about R36 million over three years: roughly 12 months to build and transition, then 24 months of managed service. All figures in this article are illustrative.
Why the drawing and the bill must match
In building work, the architect produces the drawings and a quantity surveyor produces the bill of quantities: every brick, window and hour of labour, priced. If the drawing shows a second bathroom and the bill does not include one, either the house will be built without it or the builder will pay for it out of their own pocket. Both end in an argument.
A technology proposal works the same way. The architecture is the drawing. The estimate and price are the bill. Every component on the diagram needs work to design, build, test, run and eventually retire it, and that work needs to appear somewhere in the price.
Work packages: where architecture becomes work
A work package is a bounded chunk of delivery with a clear outcome, the activities needed to reach it, the deliverables it produces, what it depends on and how it will be accepted. Work packages are the bridge between “what we will build” and “what it will cost and when”.
The basic structure for any work package is simple:
| Work package | Outcome | Activities | Deliverables | Dependencies | Acceptance |
|---|---|---|---|---|---|
| Discovery | Approved scope and baseline | Workshops and validation | Backlog and baseline views | Client experts and access | Outcomes approved |
| Foundation | A governed environment | Identity, network, deployment pipelines, logging and policy | Landing zone and pipelines | Cloud tenancy and licences | Automated control tests pass |
| Capability increment | A usable business function | Design, build, integrate and test | A working increment | APIs, data and decisions | Functional and non-functional tests pass |
Ridgeline’s plan for Rivermark had eight work packages, each tied to part of the architecture and to the transition in Part 9:
| ID | Work package | Outcome | Main dependency | Accepted when |
|---|---|---|---|---|
| WP-01 | Discovery (6 weeks) | Scope, baseline and assumptions validated | Access to Rivermark’s subject experts and billing views | Rivermark approves the backlog and baseline |
| WP-02 | Foundation | Secure cloud environment in South Africa | Cloud tenancy and staff identity integration | Control tests pass |
| WP-03 | Fault reporting increment | Customers report faults, see status and view balances; field jobs created | Field job app API and billing read-only views | User acceptance tests pass |
| WP-04 | Billing queries increment | Queries, disputes, payment arrangements and complaints handled as cases, including the monthly complaints report (FR-044) | Back-office posting process agreed with Rivermark | User acceptance tests pass |
| WP-05 | Agent console and WhatsApp | Agents work every channel in one place | Messaging provider approval | Contact centre sign-off |
| WP-06 | Open-ticket migration | Open tickets moved from the old tool | Clean export from the ticketing tool | Reconciliation shows no gaps |
| WP-07 | Service transition and hypercare | Rivermark ready to operate | Trained staff and runbooks | Exit criteria met |
| WP-08 | Managed service (24 months) | Agreed service levels met | Support model agreed | Monthly service reports |
Hypercare (WP-07) is the period straight after go-live when the delivery team stays close, fixing problems quickly and watching the new service more intensively than normal operations would.
Estimates come with a confidence level
A number without a confidence level is a trap for both sides. Estimates mature through four levels during a pursuit:
- Rough order of magnitude (ROM): a wide range used to decide whether to bid at all. It answers “is this a R5 million job or a R50 million job?”
- Assumption-based proposal estimate: a specific figure built on stated assumptions, used in the bid.
- Validated estimate: the proposal estimate re-tested once discovery has replaced assumptions with facts.
- Fixed commitment: a price you will stand behind, possible only when scope and acceptance are controlled.
At qualification (Part 1), Ridgeline’s ROM for Rivermark was R28 million to R45 million. The proposal estimate was R34.2 million. That figure looked precise, but a precise number does not remove uncertainty. So the proposal stated what would change it:
- if the billing system’s read-only views cannot be queried in near real time (evidence item E-01 from Part 3), the portal needs a caching design and more integration effort;
- if weekly fault reports in a storm exceed the assumed peak of 30,000 (E-02), capacity and messaging costs rise;
- if the chosen WhatsApp provider cannot confirm how it handles customer data, a different provider and extra integration work may be needed.
Stating these openly does not weaken the bid. It shows the evaluator exactly where the risk sits, and it protects both parties when one of them turns out to be true.
The work everyone forgets
Most under-priced bids are not wrong about the obvious work. They miss the unglamorous work around it. Check every estimate against this list:
- architecture and technical governance throughout delivery;
- setting up environments, arranging access and getting security approvals;
- data discovery, cleansing and at least one rehearsal of any migration;
- coordinating third parties, such as other suppliers whose systems you integrate with;
- non-functional testing: performance, load, security, recovery and accessibility;
- privacy impact work, threat modelling (thinking through how the system could be attacked) and collecting evidence that controls work;
- monitoring, runbooks (step-by-step operating instructions) and the formal handover to operations;
- training and adoption support;
- cutover, rollback planning and hypercare;
- programme management;
- contingency tied to named risks, not a blanket percentage added at the end;
- cloud consumption, software licences and vendor support;
- decommissioning old systems and planning an exit at contract end.
When Ridgeline’s delivery lead walked through this list for Rivermark, five items were missing from the first estimate:
- Migrating about 18 months of open tickets from the old tool, which became WP-06.
- After-hours cutover. A utility cannot close its contact centre during office hours to switch systems.
- Training 60 agents across two shifts, which means running every session twice and backfilling agents while they train.
- SMS and WhatsApp messaging fees, which are charged per message and rise sharply during a storm week.
- Per-agent licences in years two and three, which had been priced for the build year only.
None of these were exotic. All of them would have come out of Ridgeline’s margin, or become an awkward conversation with Rivermark, if they had not been found before submission.
Mandatory, recommended, optional and future
Not everything in a proposal carries the same weight. Making the difference explicit helps evaluators compare bids fairly and helps the client make informed choices.
| Category | Meaning | In the Rivermark bid |
|---|---|---|
| Mandatory foundation | Required to operate safely and meet the requirements | Backups, security monitoring, runbooks, recovery testing |
| Recommended enhancement | Improves value or reduces risk, and can be deferred under a clear condition | A short customer research sprint before the portal design is frozen |
| Optional alternative | Selectable scope with its own outcome and price | Automated matching of duplicate fault reports; a customer chatbot, which no requirement asked for |
| Future consideration | Named, but not priced or committed | Switching the billing adapter to the future billing system |
One rule is not negotiable: do not make essential security, backup or operations optional to lower the headline price. It is tempting when price carries 80 points, as it does in Rivermark’s RFP. But an evaluator who spots backups listed as an optional extra will reasonably wonder what else has been hollowed out, and a client who declines them will own the consequences of a decision they should never have been offered.
Checking the diagram against the price
Before submission, put the architecture diagram next to the price schedule and trace every component to a price line, and every price line back to a component.
Ridgeline ran this check during its red-team review (Part 12). Almost everything matched. One thing did not: the WhatsApp channel was on the diagram, and building it was priced in WP-05, but the monthly messaging fees it would generate were not priced anywhere. A new consumption line was added, with the assumed volumes stated beside it.
The reverse check matters too. A price line with no matching component suggests either work that the architecture has not explained or padding an evaluator will question.
Commercial checks
The last layer is commercial. These questions are easy to skip under deadline pressure and expensive to get wrong:
- Are third-party prices current, and valid for the whole contract? Supplier quotes often expire in 30 to 90 days, while the bid may be evaluated for months.
- Are currency and consumption assumptions visible? Rivermark’s case management licences were quoted in US dollars, so the proposal stated the exchange rate used and how currency movement would be handled.
- Is tax treatment clear? Rivermark’s price schedule asked for prices including VAT. Mixing inclusive and exclusive figures is one of the most common avoidable errors.
- Do milestones align with acceptance and cash flow? A payment should follow something the client can accept, not simply the passage of time.
- Are travel, environments, migration and after-hours cutover included?
- Is warranty or hypercare bounded? “We will fix any issues” without a time limit is an open-ended liability.
- Are penalties aligned with what the bidder controls? Ridgeline proposed that availability penalties exclude outages caused by Rivermark’s own billing system, and explained why.
- Is intellectual property treatment fair? Rivermark should be free to use what it pays for, and Ridgeline should keep the right to reuse its general-purpose integration adapters.
- Can change be priced against a clear baseline? If the scope is vague, every change request becomes a dispute.
What to take from this part
The architecture and the price are one solution. Every component needs a price line, and every price line needs a component.
Work packages connect design to cost. Each has an outcome, dependencies and a test for acceptance.
State the confidence level of every estimate. A precise number still carries uncertainty, so say what would change it.
Hunt for the forgotten work. Migration, cutover, training, messaging fees and later-year licences sink more margins than any headline item.
Never make safety optional. Security, backups and operations are the foundation, not the upsell.
Next in the series: Write for two readers: assembling and presenting the proposal.
How CloudNala can help
We review bids by putting the architecture, the delivery plan and the price schedule side by side and tracing every component to the work and cost behind it. The output is a short list of mismatches, forgotten work and commercial exposures to fix before submission, while fixing them is still cheap.
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 Bid Review or write to us at consult@cloudnala.co.za