Red-team, submit and learn from evidence

The people who write a proposal are the worst-placed people to review it. They know what they meant, so they read what they meant. They remember the conversation that explains an odd assumption, so they do not notice the assumption is unexplained. After five weeks inside a bid, its gaps have become invisible to them.

That is why the final stage of a serious pursuit brings in people who have not been living in it, and asks them to read the bid the way an evaluator and a future delivery team will. Then comes the submission itself, which deserves more care than it usually gets, and finally the part most organisations skip entirely: learning from the result.

This is the last part of the series. We are still following Rivermark Water, a fictional water utility buying a Customer Self-Service and Case Management Platform, and Ridgeline Digital, the fictional delivery partner bidding for it. By now the proposal is drafted, the price reconciled and the presentation planned. All figures are illustrative.

Why the writers cannot review their own bid

Think of proofreading your own email. You read it three times, send it, and the recipient spots the typo in the first line, because your brain filled in what you intended. Proposals suffer the same effect at scale: missing prices, contradictory numbers and claims that feel proven to the author, who remembers evidence that never reached the document.

Independent review fixes this by changing who is reading. The reviewer should read like a sceptical evaluator looking for reasons to mark down, and like the future delivery team asking whether they could actually build what is being promised, for the price, in the time.

Pink, red and gold: three reviews, three questions

Many bid teams use colour names for their reviews. The names are a convention rather than a standard, and organisations vary them, but the idea is consistent: each review happens at a different stage and asks a different question.

• Pink team reviews the structure and argument early, while changing direction is still cheap.
• Red team reviews a near-final draft as a sceptical evaluator would.
• Gold team checks consistency and gives final approval to submit.

After that comes the submission compliance check itself.

The pink review asks whether the bid is built on the right skeleton:

• Does the outline follow the scoring model?
• Is the client’s problem genuinely understood?
• Are the win themes specific and provable?
• Does every section have an owner and a source of evidence?

Rivermark’s pink review found that Ridgeline’s outline followed Ridgeline’s preferred document order, not the order of Rivermark’s scoring sheet. It was restructured the same day, so that each scorer would meet the sections in the order they score them.

The red review asks whether an evaluator can score every point and would trust what they find:

• Can every mandatory and weighted requirement be scored?
• Does the solution work end to end?
• Do the text, diagrams, scope, estimate and price agree with each other?
• Are the assumptions fair and visible?
• Which claim would a competitor attack?
• What would make a risk-conscious evaluator hesitate?

Ridgeline’s red team found four real problems:

1. The WhatsApp channel appeared on the integration diagram, but the monthly messaging fees were not priced anywhere (the check described in Part 10).
2. The proposal committed to 99.5% monthly availability without explaining that the portal depends on Rivermark’s own billing system, which Ridgeline does not control.
3. Evidence item E-01, that the billing system’s read-only views can be queried in near real time, was still unverified, but section 5 described it as fact.
4. The executive summary still opened with company history, despite everything in Part 11.

All four were fixed. NFR-004, the 99.5% availability requirement, moved to “partially comply” in the compliance matrix, with the billing dependency explained and a clear description of how the portal behaves when billing is unavailable. E-01 was rewritten as a stated assumption, with its impact if false. The first draft had said neither, which is exactly why the red team exists.

The gold review checks that everything agrees and that the right people approve: price totals match the price schedule, diagrams match the text, the commercial lead and delivery lead sign off, and the bid owner approves submission.

The architecture challenge: ten questions

Alongside the colour reviews, someone with architecture experience who did not design the solution should put these questions to it:

1. Which outcome does each component support?
2. Which requirement lacks architecture or delivery coverage?
3. Which component is not priced?
4. Where are the data, identity and trust boundaries?
5. What happens when a provider, network, integration or process fails?
6. Who owns the service after launch?
7. Are availability, recovery, scale, performance and accuracy stated in ways that can be tested?
8. Does disaster recovery move data somewhere unacceptable?
9. Which assumption changes the solution most if it is wrong?
10. Can the bridge states stay safe if the transition takes longer than planned?

For Rivermark, question 8 was worth asking explicitly. The RFP required hosting in South Africa, so a recovery design that copied data to a region outside the country would have broken a requirement in the one situation, a disaster, where nobody would be checking. Ridgeline’s design kept recovery copies within South Africa and documented the trade-off that this limits geographic separation.

Submission is its own piece of work

A bid can be excellent and still be disqualified for a missing signature. Before submission, verify:

• the correct version of every document, with the right file names;
• signatures, forms and declarations, all complete;
• totals, tax treatment and cross-references;
• annexures and diagrams, readable at normal zoom;
• no leftover comments or tracked changes;
• portal limits on file size and format;
• the deadline, and proof of receipt.

Assign one submission owner, and preserve the exact package that was submitted, so there is never a question later about what the client received.

Ridgeline’s submission owner uploaded the Rivermark bid 40 minutes before the portal closed. The signed pricing form had arrived late, and one large annexure uploaded slowly. The receipt was saved and the bid was valid. But it was a near miss, and that matters later in this article.

After the result: learn from evidence

Rivermark shortlisted Ridgeline, invited the team to present and, about ten weeks after submission, awarded it the contract ahead of the old ticketing tool’s supplier and a large systems integrator.

The easy lesson is “we won, so we did it right”. That lesson is often wrong. A win may contain poor habits that simply were not punished this time. A loss may contain strong work that was defeated by price or an incumbent. Learn from evidence, not only from the result.

After every result, win or lose, record:

• the score by criterion, where the client shares it;
• any mandatory or administrative failures;
• client feedback;
• competitors’ strengths;
• your price position;
• the effort the bid consumed;
• whether the qualification decision in Part 1 was accurate;
• evidence gaps you had to work around;
• material that can be reused;
• delivery lessons, if you won.

Ridgeline’s lessons log for Rivermark included entries like these:

The near-miss upload sits in the bottom-right quadrant: a poor habit inside a winning bid. It cost nothing on Rivermark; on the next bid, a late signature and a slow portal could cost everything. A “we won” debrief never records that lesson.

The one-page bid architecture canvas

Across this series, the same dozen areas have kept coming back. They fit on one page, and filling that page early in the next pursuit is the fastest way to see what is missing.

Final bid checklist

Use this before any submission. Every unticked box is either a fix or a risk the bid owner accepts knowingly.

Qualification

• Mandatory gates pass.
• The right to win is specific and evidenced.
• One owner controls the pursuit.
• Delivery and commercial leaders accept the opportunity.

Understanding

• Outcome, users, measures and urgency are explicit.
• Stakeholders and evaluation criteria are mapped.
• Current facts are separated from assumptions.
• Blocking questions have answers, or block commitment.

Solution

• Business, data, application, integration, technology, security and operations agree.
• Each diagram has a purpose and an audience.
• Mandatory, recommended, optional and future elements are clear.
• Important business and technical flows are shown.
• As-is, bridge and to-be states are credible.
• Ownership after launch is explicit.

Delivery and commercials

• The architecture maps to work packages, roles, estimate and price.
• Dependencies and client responsibilities are scheduled.
• Acceptance is testable.
• Cloud, licence, third-party and support costs are clear.
• Assumptions and exclusions are fair.
• Risks have owners and treatments.

Evaluation and submission

• Every requirement maps to a response and evidence.
• The executive summary states the recommendation and the value.
• An independent review challenged the response.
• Totals and cross-references reconcile.
• Forms, signatures and attachments are complete.
• Diagrams are readable at normal zoom.
• The exact submission and its receipt are retained.

Practising: a learning path

Reading about bids builds vocabulary. Doing the work builds judgement. These ten exercises can be run on a fictional RFP, or on a past bid with the names removed, and each has a clear sign that the skill has landed.

What to take from this part

Writers cannot review their own bids. Bring in reviewers who read like a sceptical evaluator and a future delivery team.

Each review asks one question. Pink checks structure, red checks whether points can be scored and trusted, gold checks consistency and approval.

Treat submission as a task with an owner. Collect signatures early, check the portal limits and keep the exact package and receipt.

Learn from evidence, not only the result. Record what happened, win or lose, and fix the habits a win did not punish.

Carry the canvas and checklist forward. One page at the start and one checklist at the end catch most of what goes wrong in between.

That completes the series. If you are starting a new pursuit, go back to Part 1: Win before you write, or browse all twelve parts on the series page.

How CloudNala can help

We run independent red-team reviews for bid teams: reading the draft as a sceptical evaluator and as the delivery team who would inherit it, tracing the architecture to the price, and returning a prioritised list of fixes while there is still time to make them. After the result, we help turn the debrief into a short lessons log that the next bid actually uses.

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