Use when drafting the proposal's interpretation of context, objectives, scope, constraints, stakeholders, or ToR gaps. Unlike 06-methodology, this skill proves understanding of the problem before prescribing the delivery approach.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use when drafting the proposal's interpretation of context, objectives, scope, constraints, stakeholders, or ToR gaps. Unlike 06-methodology, this skill proves understanding of the problem before prescribing the delivery approach.
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
Use this skill to draft or revise the assignment-understanding section of a proposal.
Load it when the bid requires interpretation of the background, objectives, scope, or ToR comments.
Do Not Use When
The task is unrelated to understanding the assignment or commenting on the ToR.
The user only needs supporting domain knowledge rather than this section.
Required Inputs
The ToR, RFP, advert, or assignment brief.
The selected proposer profile and any client or sector context already gathered.
Any explicit evaluator expectations about ToR comments, assumptions, or observations.
Artefact
Source
Required?
If absent
Complete ToR, criteria, clarifications, and verified context
Official tender sources
required
Return questions and a bounded interpretation; do not fill gaps as fact.
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.
Read the assignment materials and identify the real problem, scope, and evaluator concerns.
Load relevant profile, sector, procurement, and supporting domain skills before drafting.
Use discovery questions to expose missing assumptions on outcomes, users, data, support, budget, approvals, and decision criteria.
Use the structure below to translate the brief into a clear, client-aware interpretation in your own words.
Add substantive comments on the ToR where the format or evaluator expectations reward them.
Check the section against the methodology and work plan so the logic flows cleanly into delivery.
Quality Standards
Keep the section analytical, client-specific, and grounded in the actual brief.
Use British English and East African professional tone unless the bid format requires otherwise.
Show insight, structure, and practical judgement rather than simply rephrasing the ToR.
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 restate the ToR mechanically with no interpretation.
Do not make comments on the ToR that create unnecessary compliance risk or contradict later sections.
Do not describe problems, assumptions, or scope elements that the proposal does not address.
Do not add unsourced context. Fix: cite or label each external premise.
Do not hide material ambiguity. Fix: state the assumption, consequence, and clarification need.
Outputs
Artefact
Consumer
Acceptance condition
Understanding and ToR-comment section
Evaluator and methodology writer
Distinguishes facts, interpretation, assumptions, constraints, stakeholders, and delivery implications.
Evidence Produced
Evidence
Consumer
Acceptance condition
Requirement and assumption map
Traceability table
Each interpretation points to ToR evidence or is explicitly labelled.
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 analysis. Do not alter official requirements or submit clarifications without authority.
Degraded Mode
Without the complete ToR or clarification record, provide a qualified interpretation and missing-evidence register. Never treat ambiguity as agreement.
Decision Rules
Finding
Action
Risk avoided
Requirement is explicit
Explain its implication
Mechanical paraphrase
Ambiguity changes scope or price
Raise clarification or assumption
Hidden exposure
Insight has no method response
Remove it or repair methodology
Orphan diagnosis
Worked Example
If national rollout has no site count, state the planning consequence and request or price a site assumption rather than inventing locations.
Root references/ files for persuasion, logic structure, and proposal patterns.
This section proves the firm has read, analysed, and thought critically about the Terms of Reference. It is not a paraphrase of the ToR — evaluators wrote the ToR and will notice if it is simply copied back at them. The firm must restate the assignment in its own words and add professional insight.
What to Gather Before Writing
The full Terms of Reference or Request for Proposals
The client's institutional context — ministry, department, agency, or organisation
The broader programme or reform the assignment sits within
Any publicly available background documents (sector reports, previous studies, policy frameworks)
Issues, gaps, or ambiguities in the ToR that the firm has identified
Structure
Background and Context
One to two pages. Describe:
The client's institutional mandate and the sector context
The broader programme, reform, or initiative this assignment supports
The current situation — what has been done so far, what gap remains
Why this assignment is being procured now — the trigger or urgency
Write this in the firm's own words. Demonstrate that the firm understands the environment the client operates in, not just the task list in the ToR.
Objectives of the Assignment
Half a page. Restate the objectives from the ToR, but frame them in terms of the outcomes the client expects — not just the activities to be performed.
If the ToR lists objectives and expected outcomes separately, synthesise them into a coherent statement. If the ToR is vague on objectives, state what the firm understands the objectives to be and note this as a clarification point.
Scope of Work
One page. Describe the full scope in the firm's own language:
What services will be provided
What deliverables will be produced
What is in scope and what is explicitly out of scope
Geographic coverage if the assignment spans multiple locations
The beneficiary groups or stakeholders involved
Comments on the Terms of Reference
Half a page to one page. This is the most valuable part of this section — it shows the firm is thinking critically, not just complying.
For each comment, use this format:
ToR Reference: [Section or clause number]
Observation: [What the firm has noticed — an ambiguity, a gap, a risk, or a suggestion]
Recommendation: [What the firm proposes — a clarification request, an alternative approach, or an additional activity]
Common types of comments:
Scope items that overlap or conflict
Timelines that appear tight given the scope
Dependencies on client inputs that are not specified
Missing deliverables that would normally be expected
Suggested additions that would strengthen the assignment's outcomes
If the ToR is well written and has no issues, state this briefly and note that the firm is fully aligned with the stated scope and approach. Never fabricate comments for the sake of appearing thorough.
The Baseline Logic: S1 → S2 → B
Every understanding-of-assignment section must walk through a clear logical arc. This arc has three elements:
S1 — Current State
Describe the client's current situation as stated or implied in the ToR. Three components make up S1:
Triggering event — the specific event, decision, or deadline that brought this problem to consciousness and prompted the procurement. This may be a policy directive, an audit finding, a donor requirement, an expiring contract, or a crisis.
Overriding problem — the single highest-level problem the client faces. There is always one overriding problem, even when the ToR lists many issues. Identify it and state it clearly.
Effects — the downstream consequences of the overriding problem. These are the symptoms the client experiences day-to-day: delays, cost overruns, non-compliance, service failures, stakeholder dissatisfaction.
S2 — Desired State
Describe what will be different at the end of the project. S2 is the result the client is purchasing — not the activities or deliverables, but the changed condition. If the ToR describes expected outcomes, synthesise them into a single coherent picture of the desired end-state. If the ToR is silent on outcomes, infer S2 from the objectives and state the inference explicitly.
B — Benefits
State the good things that accrue from achieving S2. Benefits sit beyond the project boundary — they are the lasting value the client and its stakeholders receive. Examples include reduced costs, improved service delivery, enhanced compliance, stronger institutional capacity, or better policy outcomes.
Applying the Logic
The understanding section should explicitly walk through this arc in its narrative:
"The [institution] currently faces [S1 — overriding problem and its effects, triggered by the triggering event]. The Terms of Reference seek to move toward [S2 — the desired end-state]. Achieving this will [B — the benefits that follow]."
This logic provides the backbone of the narrative. Every sentence in the understanding section should serve this arc. If a sentence does not connect to S1, S2, or B, it is filler and should be removed.
The Overriding Question
Every assignment has one overriding question that the project must answer. The overriding question is the pivot of the entire proposal — if it is wrong, the objective is wrong; if the objective is wrong, the methodology is wrong; and if the methodology is wrong, the proposal fails regardless of how well it is written.
The overriding question is derived from the overriding problem (identified in S1), not from the ToR's list of tasks. Tasks are activities; the overriding question is the intellectual challenge the firm must resolve.
How to Derive It
Identify the overriding problem from S1.
Frame it as a question that, if answered correctly, would resolve the problem and move the client to S2.
Ensure the question is specific enough to guide methodology design, but broad enough to encompass the full scope of the assignment.
Example
If the ToR asks for "a review of the procurement function", the overriding question is not "What is the current state of procurement?" — that is merely descriptive. The overriding question might be:
"What specific changes to [institution]'s procurement processes, systems, and capacity would reduce procurement cycle times to within [benchmark] while maintaining compliance with [regulatory framework]?"
This question drives the methodology: it tells the team what data to collect, what to analyse, and what the deliverable must contain.
Stating It in the Proposal
The understanding section should identify the overriding question explicitly. This signals to the evaluator that the firm has moved beyond surface comprehension to genuine analytical engagement with the assignment. Place it after the S1–S2–B narrative, as a bridge to the methodology.
For website, software, SaaS, AI, service design, support, or transformation assignments, the overriding question should include the operating reality: which users are affected, which service or workflow moments fail today, which data or systems constrain delivery, and which measurable outcome will prove the change worked.
Problem Analysis — Three Facets
A strong understanding section analyses the client's problem from three facets, based on the Wickham framework. Most proposals address only the first; proposals that address all three demonstrate a mature grasp of organisational consulting.
Rational Facet
The logical and economic dimension of the problem. This is the facet most consultants address instinctively:
What is the measurable cost of the current problem? (Financial losses, time delays, compliance gaps, service failures.)
What is the economic value of resolving it? (Cost savings, efficiency gains, revenue increases, risk reduction.)
What does the evidence say? (Data, benchmarks, audit findings, performance metrics.)
The rational facet provides the business case. It answers the question: "Why is this worth spending money on?"
Cognitive Facet
How individual managers, staff, and stakeholders perceive the problem. This may differ substantially from the rational reality:
Do stakeholders agree on what the problem is, or do different groups define it differently?
Are there misconceptions, blind spots, or outdated assumptions shaping how the problem is understood?
Is there awareness of the problem's full scope, or do stakeholders see only their portion of it?
The cognitive facet matters because solutions that ignore how people perceive the problem will face resistance regardless of their technical merit. The understanding section should signal awareness of these perceptual differences.
Political Facet
Who gains and who loses from the proposed change. Every assignment that recommends change creates winners and losers within the client organisation:
Which units, departments, or individuals benefit from the current state and may resist change?
Which stakeholders stand to gain from the proposed reforms and can be mobilised as champions?
Where are the power dynamics that will shape whether recommendations are implemented or shelved?
The political facet is rarely stated openly in a ToR, but evaluators — particularly senior ones — know it exists. A proposal that acknowledges organisational dynamics (tactfully and professionally) demonstrates that the firm will not produce technically sound but politically naive recommendations.
Applying the Three Facets
The understanding section need not label these facets explicitly. Instead, weave them into the narrative:
The rational facet appears in the description of the problem and its costs.
The cognitive facet appears in references to stakeholder perspectives, differing interpretations, or change readiness.
The political facet appears in references to institutional dynamics, competing priorities, or implementation risks.
The effect is an understanding section that reads as organisationally intelligent, not merely technically competent.
The Story Component
The understanding section should read as a compelling narrative of the client's situation, not as a restatement of the Terms of Reference. Evaluators read dozens of proposals; the ones that stay with them tell the client's story in a way that resonates. The Freed framework provides three components for structuring this narrative.
Story
Tell the evaluator where the client is now, from the client's own perspective. This is not the firm's analysis — it is an empathetic rendering of the client's experience:
What pressures is the client facing?
What has the client already tried?
What constraints limit the client's options?
Why has the problem persisted despite previous efforts?
The story component draws on S1 but goes further — it humanises the situation. It shows the evaluator that the firm has listened, not just read.
Questions
State the key questions that must be answered by the assignment. These are not simply the tasks listed in the ToR — they are the analytical questions generated from the methodology logic:
What must be understood before solutions can be designed?
What evidence must be gathered to support recommendations?
What trade-offs must be examined?
The questions component bridges the understanding section and the methodology. It tells the evaluator: "We know what we need to find out, and our methodology is designed to find it out."
Closing
State the project's objectives clearly and concisely, then end with the benefits. The closing ties the narrative back to the S1–S2–B arc:
Restate the objectives in one to two sentences.
End with the benefits, briefly stated — what the client and its stakeholders will gain.
The closing should leave the evaluator with a clear sense of purpose and value. It should feel like the natural conclusion of a well-told story, not a bureaucratic summary.
Tone Rules
Three to four pages total
Never copy-paste from the ToR — evaluators will notice immediately
Show insight, not just comprehension
Comments on the ToR must be professional and constructive — never critical of the client
Frame suggestions as "we recommend" or "the firm suggests", not "the ToR should have included"
