RFP Process Improvement — Priorities

Derived from: Issue Tree

Purpose

This document translates the issue tree into a small number of recommended starting priorities for the next phase of work.

The aim is not to redesign the whole RFP process upfront. The aim is to start with the few pieces of work that are most likely to generate real learning, reduce blindness, and support better decisions on pricing, compliance, and process design.

Recommendation at a Glance

Key logic: don't redesign the whole process before diagnosing what's actually broken. Priorities 1–2 produce the evidence; priority 3 prevents the same blindness recurring; priority 4 uses the evidence to decide where deeper investment is justified.

Priority 1: Build the win/loss picture

Issue tree branches: 4.1, 4.2, 5.4, 5.5

Why this is a top priority

Right now we do not have a reliable enough picture of what happened across recent submitted bids. We know the headline problem is poor win rate, but we do not yet know with confidence:

• which submitted bids are confirmed wins/losses
• which are only assumed losses
• where outcome tracking is missing
• what patterns exist across buyer type, bid type, deal size, or relationship context

Without this, discussion about pricing, proposal quality, or bid selection stays too speculative.

What to do

Use GitHub issues as the source of truth. Do not build a heavy separate spreadsheet or mini-database unless later analysis clearly requires it.

Do a light pass over recent submitted RFPs and record only the minimum needed:

• won / lost / no bid / missed / still pending / assumed lost
• estimated value if already available
• one-line reason if known

Focus on recent and relevant bids first, especially 2025-2026 submissions.

Output

• A usable win/loss picture from the existing GitHub tracker
• A list of bids with missing or uncertain outcomes
• First cut of patterns worth testing

Estimate

0.5-1 day

This should be timeboxed. The goal is directional clarity, not perfect historical reconstruction.

Priority 2: Retrospective on representative bids

Issue tree branches: 2.1, 2.2, 2.3, 4.2, 4.3

Why this is a top priority

A simple win/loss picture will show what happened. It will not by itself explain why.

To move from tracking to diagnosis, we need to review a small number of bids closely and test the main hypotheses already visible in the issue tree and offsite discussion:

• are we losing on price
• are we missing mandatory criteria
• are we bidding into low-probability situations
• are some bids weak on proposal quality or fit

The UAE bid is especially important because it already suggests two specific failure modes: compliance and commercial competitiveness.

What to do

Review 3-5 bids:

• at least one competitive win
• at least one clear loss
• at least one no-bid or missed bid
• one or two ambiguous or representative recent cases

For each one, answer only a few questions:

• Did we meet the mandatory criteria?
• Did we understand and address the client need well?
• Was pricing competitive relative to risk and strategic value?
• Was this the sort of bid we should have pursued in the first place?
• What should we repeat or change next time?

Output

• Short review notes for 3-5 bids
• First evidence-backed view of the biggest causes of loss
• Initial candidate fixes for pricing, compliance, and selection discipline

Estimate

1-1.5 days

Assumes source material is accessible in Drive/GitHub and that the review is concise rather than exhaustive.

Priority 3: Add a minimal post-submission closeout ritual

Issue tree branches: 4.1, 4.2, 4.3, 5.5

Why this is a top priority

The current process effectively stops at submission. That creates the same blindness again and again. Even if we learn something from the retrospective work above, we will lose that benefit unless we add a small recurring mechanism for outcome tracking and learning.

This does not need to be heavy. It only needs to be reliable.

What to do

Keep GitHub as the operating source of truth and introduce a lightweight closeout loop for submitted bids.

Suggested elements:

• distinguish confirmed losses from assumed losses
• record one-line reason for outcome when known
• add a very short retrospective note for meaningful bids
• run a short recurring review of submitted bids that still have no clear outcome

This should be designed to fit the current resourcing reality and should not create significant extra admin overhead.

Output

• A lightweight ongoing process for keeping the tracker alive
• Better future data with minimal maintenance burden
• A foundation for learning over time rather than one-off cleanup

Estimate

Design: 0.5 day

Recurring operating cost: 20-30 min every 2 weeks

Priority 4: Decide the next deeper process investments

Issue tree branches: 1.2, 1.3, 2.1, 2.3, 3.1, 3.2, 5.1, 5.2, 5.3

Why this comes fourth

There are several plausible deeper improvements:

• pricing framework
• compliance / mandatory-criteria checklist
• bid/no-bid criteria
• better proposal content reuse
• AI support
• process tooling

However, these should be sequenced after the first diagnostic work above. Otherwise we risk spending time improving the wrong parts of the system.

What to do

Once priorities 1-3 are complete, decide which one or two investments are most justified by evidence.

Most likely candidates at present:

• a mandatory-criteria control before submission
• clearer pricing/risk discipline by bid type and client type

Output

• A sharper second-phase roadmap
• Better rationale for where to invest limited team time

Estimate

0.5 day to decide and frame next-phase work

Suggested Sequence

Week 1

1. Build the lightweight win/loss picture
2. Pick and review 3-5 representative bids

Week 2

1. Put in place the minimal closeout ritual
2. Decide the next deeper process improvements based on what the first pass showed

Total Estimate for First Phase

2.5-3.5 days of focused work

This is intended to be small enough to execute within current resourcing while still producing meaningful diagnostic value.

What This Phase Will Answer

If completed, this phase should give us much better answers to:

• Are we mostly losing on price, compliance, fit, or weak positioning?
• Are there patterns in the kinds of RFPs we do or do not win?
• Are invited / relationship-led bids materially different from cold competitive bids?
• Is the biggest gap in selection, pricing, compliance, or post-submission follow-up?
• What is the smallest process change that would materially improve learning and discipline?

What This Phase Will Not Yet Do

This phase is not intended to:

• redesign the entire RFP process end to end
• produce a perfect historical record of every bid
• build a full analytics system
• solve pricing, compliance, and bid/no-bid in one pass

It is a first diagnostic and operating step, not the full solution.