Process or luck: a maturity self-check for tendering teams
Ask two people on your bid team when the compliance matrix gets started, and see whether you get the same answer. Sound familiar?
A tendering process is mature when the same tender would be run the same way regardless of who picked it up. Five markers show whether yours is: a bid/no-bid made against criteria, a kick-off that produces artefacts, one named owner per obligation, review milestones fixed in the programme, and a feedback loop that changes the next bid. Score each as absent, ad hoc or standing.
Most teams are strong in the middle and weak at both ends, which is also where the cheapest fixes are. The reading load is usually why: when the pack takes days to understand, the kick-off gets skipped. Elora Grid removes that load by returning the register, dates and risk clauses cited to source; the process itself is yours to run.
What does a mature bid process actually look like?
Repeatability. A mature process means the tender is handled the same way whether your best bid manager picks it up or your newest engineer does, because the steps sit in the process rather than in one person's habits.
It is not about documentation volume. A team with a two page checklist it always follows is more mature than a team with a procedure manual nobody has opened since it was written.
What are the five markers?
Entry, kick-off, ownership, reviews and the loop. Entry is whether you decide what to chase against criteria or against enthusiasm. The kick-off is whether the pack gets turned into artefacts before anyone prices. Ownership is whether every obligation has one name against it.
Reviews are whether checkpoints exist in the programme with enough room to act on what they find. The loop is whether anything from the last outcome changes the next bid. Score each one absent, ad hoc, or standing, and be honest about the difference between ad hoc and standing: ad hoc means it happens when someone remembers.
Why are the ends weaker than the middle?
Because the middle is where the visible work is. Nobody forgets to price a tender or to write the technical response; those have deadlines attached and a person whose job title matches them.
The ends have neither. Nobody chases you for a bid/no-bid record, and no client asks whether you held a win/loss review. They are the first two things dropped when the next pack lands, and dropping them is invisible until you notice the team keeps bidding work it cannot win and re-learning the same lesson.
What should you fix first?
The ends, because they are cheap and they change what the middle works on. A bid/no-bid scorecard is one page and an agreed set of weights, and a win/loss review needs nothing more than an hour and a template. Neither needs a system, a budget, or anyone's permission.
Fix the middle only where the reading load is the blocker. When a kick-off gets skipped, it is almost never because the team thinks kick-offs are useless; it is because understanding the pack takes days the calendar does not have.
The five markers, and what standing looks like
| Marker | The honest question | Standing looks like |
|---|---|---|
| 1. Entry | Can you say why you are bidding this one, in criteria rather than adjectives? | A scored bid/no-bid on every pursued tender, declines recorded too |
| 2. Kick-off | Does the pack become a register, a date list and a risk list before pricing starts? | A fixed agenda that produces artefacts, run on every tender |
| 3. Ownership | Does every returnable and risk clause have exactly one name against it? | A compliance plan the whole team works from |
| 4. Review milestones | Are the review dates in the programme, with room to act on findings? | Pink, Red and Gold booked at kick-off, not squeezed in at the end |
| 5. Feedback loop | Did anything from the last outcome change this bid? | A win/loss review that edits the price book, answer library and weights |
- 01Score the five markers separately, alone. Bid manager, estimator and engineer each score without discussing it first.
- 02Compare the scores before debating them. Where the three of you disagree is the real finding; a marker scored differently is not standing.
- 03Test each claim against the last tender. Not what should happen: what actually happened on the most recent bid you submitted.
- 04Fix one end first. Entry or the loop, whichever is weaker, and give it a one page artefact rather than a procedure.
- 05Re-run it after three tenders. Maturity shows up as agreement between people, not as a higher score you gave yourself.
Common questions
How do you assess bid process maturity?
Score five markers as absent, ad hoc or standing: the bid/no-bid decision, the kick-off, ownership of obligations, review milestones, and the feedback loop. Score them against what happened on your last tender rather than against the process you intend to follow.
Is a mature process slower?
It front-loads time and removes it later. A scored entry decision saves the estimating hours you would have spent on a tender you were never going to win, and a kick-off replaces the fragmented reading everyone does separately. You spend more in the first week and less over the whole bid.
Does a small team need this?
More than a large one, because a small team has less slack to absorb a missed returnable. The markers scale down cleanly: the artefacts get shorter, the reviews get fewer people, and the discipline of running them every time matters more, not less.
What if the reading load is what breaks the process?
That is the usual cause of a skipped kick-off. Hand the pack to Elora Grid and it returns the document register, the dated deliverables and the commercial risk clauses cited to source, which is the input the kick-off needs. Running the process, and owning the decisions in it, stays with your team.