05 Relevant Experience

Relevant Experience

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

Use When

• Use this skill to draft or revise the relevant experience section of a proposal or EoI.
• Load it when evaluator confidence depends on comparable project evidence.

Do Not Use When

• The task is unrelated to past performance or comparable assignments.
• The user only needs supporting domain knowledge rather than this section.

Required Inputs

• The assignment brief and any evaluation criteria on experience.
• The selected proposer profile.
• Verified project examples, dates, roles, clients, scope, and outcomes.

Workflow

Stop or block the workflow when a required input, permission, or acceptance basis is missing. Recover by revising the scope, obtaining evidence, or returning the narrowest qualified draft before proceeding.

1. Read the bid requirements and determine what kinds of experience matter most.
2. Load the proposer profile and any procurement or sector context that shapes relevance.
3. Select the strongest comparable assignments and structure them using the guidance below.
4. Convert each selected assignment into a proof story: context, challenge, role, intervention, result, and relevance.
5. Emphasize outcomes, relevance, and evaluator-fit rather than raw volume.
6. Verify consistency with the profile, team, and methodology sections.
7. For premium proposals or public case studies, apply the premium commercial writing case-study pattern before finalising.

Quality Standards

• Keep examples directly relevant to the assignment and evaluation criteria.
• Use British English and East African professional tone unless the bid format requires otherwise.
• Prefer quantified outcomes, named roles, and clear similarity signals.

Anti-Patterns

• Releasing the section with an unresolved mandatory input. Fix: block release and name the evidence owner.
• Hiding a contradiction with another proposal section. Fix: reconcile the source sections before drafting resumes.
• Treating an unavailable check as passed. Fix: mark it not assessed and return a qualified draft.
• Do not list projects with no outcomes or no relevance logic.
• Do not exaggerate roles, scope, or contracting relationships.
• Do not overload the section with marginal examples that dilute the strongest evidence.
• Do not claim team-member work as firm work. Fix: attribute contracting entity and individual role.
• Do not publish confidential client details. Fix: secure consent or use an accurate permitted description.

Outputs

Evidence Produced

Capability and Permission Boundaries

Read and search are required; any edit or external action remains within the explicit authority and permission boundary stated below. Default to read-only evidence review. Do not contact references, disclose confidential terms, or change project facts without authority.

Degraded Mode

When reference evidence is unavailable or missing, return the narrowest qualified project longlist and evidence gaps. Mark relevance claims not assessed; do not convert anecdotes into verified cases.

Decision Rules

Worked Example

A project sheet states that the firm led requirements and training for a comparable MIS, names verified outputs and outcomes, and explains the precise relevance to the new ToR.

References

• Proposal skills router for repository-wide routing and mandatory quality gates.
• ../profiles/SKILL.md for proposer selection and voice.
• ../sectors/SKILL.md for procurement and sector routing.
• ../proposal-storytelling-and-evaluator-journey/SKILL.md and ../references/proposal-narrative-patterns-and-case-story-spine.md for case-story structure and evaluator relevance.
• ../premium-commercial-writing/SKILL.md for premium proof discipline, case-study relevance, and public-facing case-study polish.
• ../references/saas-win-themes-and-discriminators.md for SaaS-specific differentiator language to apply to project cards.
• ../references/vertical-saas-positioning-financial-services.md, ../references/vertical-saas-positioning-insurance.md, ../references/vertical-saas-positioning-public-sector.md, ../references/vertical-saas-positioning-healthcare.md, ../references/vertical-saas-positioning-education.md for vertical-specific proof anchors.
• For SaaS engagements, project cards should anchor outcomes on SaaS-relevant figures: time-to-value, activation rate, NRR / gross retention uplift, churn reduction, expansion revenue uplift, time-to-first-paying-customer, regulator dry-run outcomes, and tenant-isolation evidence.
• Relevant proposal-wide references when positioning or proof structure needs reinforcement.

This section is typically the most heavily weighted in evaluation scoring. It is where the firm proves — not claims — that it has done this before and can do it again.

What to Gather Before Writing

For each project to include:

• Client name and country
• Assignment title
• Duration and year
• The firm's specific role (lead, sub-contractor, individual consultant)
• Scope: what was actually done
• Quantified outcomes — this is the most important input
• A reference contact (name, title, phone or email)

Aim to gather at least four projects. Prioritise projects that are:

1. The same type of assignment as the current bid
2. In the same country or sub-region as the client
3. For the same type of client (government ministry, NGO, regulatory body, private sector)
4. The largest or most prestigious engagements available

Structure

Summary Table

Open with a table listing all included projects at a glance. This allows evaluators to quickly assess coverage before reading the detail.

Project Cards

Follow with a detailed card for each project using a consistent template:

CLIENT:     [Organisation name], [Country]
ASSIGNMENT: [Title]
PERIOD:     [Month/Year – Month/Year]
OUR ROLE:   [Lead implementor / Team leader / Sub-consultant]
SCOPE:      [Two to three sentences describing what was done]
OUTCOMES:
  • [Quantified result — e.g., "Reduced processing time from 14 days to 3 days"]
  • [Quantified result — e.g., "Trained 127 staff across four departments"]
  • [Quantified result — e.g., "System achieved 99% uptime in first six months"]
REFERENCE:  [Name, Title, Phone/Email]

Order project cards by relevance to the current bid, not by date.

For premium, digital, AI, website, service-design, or support-heavy proposals, add one line after each project card: Relevance to this assignment: [specific parallel in outcome, user group, technology, service journey, risk, operating context, or support model]. This helps evaluators see why the example matters, not only that it exists.

The Outcomes Rule

Every project card must contain at least one quantified outcome. If the user cannot provide numbers, ask specifically:

• How many users, staff, or beneficiaries were served?
• What changed as a result — processing time, error rate, cost, coverage?
• Was the project delivered on time and on budget?
• What did the client say after delivery?

If exact figures are unavailable, use ranges or relative measures: "reduced by approximately 30–40%", "served over 5,000 beneficiaries".

A project card without outcomes is significantly weaker than one with them. Never submit a card that only describes what was done without stating what was achieved.

Tone Rules

• Three to six pages depending on the number of projects
• Factual and specific — evaluators may contact references to verify claims
• Order by relevance, not chronology
• Never include projects that are not genuinely comparable — it weakens the section
• Follow east-african-english standards throughout