03-understanding-of-assignment

name	03-understanding-of-assignment
description	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.
metadata	{"portable":true,"compatible_with":["claude-code","codex"]}

Understanding of the Assignment

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, [phone].

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.

1. Read the assignment materials and identify the real problem, scope, and evaluator concerns.
2. Load relevant profile, sector, procurement, and supporting domain skills before drafting.
3. Use discovery questions to expose missing assumptions on outcomes, users, data, support, budget, approvals, and decision criteria.
4. Use the structure below to translate the brief into a clear, client-aware interpretation in your own words.
5. Add substantive comments on the ToR where the format or evaluator expectations reward them.
6. 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.

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.
• ../references/discovery-question-bank-for-proposals.md for clarification questions and assumption discovery.
• ../references/saas-discovery-question-bank.md for SaaS-specific discovery (ICP, Critical Event, pain chain, impact per role, decision process).
• ../references/meddic-and-command-of-message-for-saas.md for SaaS qualification logic and Six-Lens Value Claim.
• ../service-design-proposal-strategy/SKILL.md when the assignment involves journeys, touchpoints, support, citizen/customer experience, or service quality.
• ../references/ethical-persuasion-and-evaluator-psychology-gate.md for evaluator concern, risk perception, and ethical persuasion checks.
• ../saas-discovery-and-qualification/SKILL.md for SaaS-specific Understanding of the Assignment content (pain chain, Critical Event, ICP, decision process).
• 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

1. Identify the overriding problem from S1.
2. Frame it as a question that, if answered correctly, would resolve the problem and move the client to S2.
3. 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"
• Follow east-african-english standards throughout