--- name: research-proposal-and-scope-development description: > Turns an agreed approach into a proposal a client can buy and a team can deliver. Use for "write the research proposal", "respond to this RFP", "how do I explain this approach to a non-researcher", "what should be in scope and what should be excluded", "the client wants more than the budget covers", "should we decline this brief", "how do I rescope this request". Covers proposal structure, approach articulation, scope and exclusions, the assumptions register, deliverable specification, timeline with client dependencies, how scope drives effort, and declining or rescoping professionally. Does not cover pricing methodology. category: 01 Research Strategy and Design ref: "01.08" tier: 2 inherits: [K2, K3, K4, K5] --- # Research Proposal and Scope Development ## 1. One-line description Turns an agreed approach into a proposal a non-researcher can evaluate and a team can deliver: the question restated better than the client wrote it, the approach explained by why it answers that question, a scope with explicit exclusions, an assumptions register, specified deliverables, and, where necessary, a professional decline or rescope. ## 2. What this skill is used for **The research problem it solves.** Proposals fail in two directions and both are expensive. A proposal that under-specifies wins work whose scope is then negotiated in delivery, one accommodation at a time, until the team is running a study nobody planned and the margin is gone. A proposal that over-promises wins work by proposing what is easiest to sell rather than what the question needs, and the disappointment arrives at the debrief, where it damages the relationship more than a lost pitch would have. Between them sits a third failure, the most common of all: a proposal that is methodologically correct and unreadable by the person who has to approve it, because it explains what will be done without ever explaining why that answers their question. This skill produces a document a non-researcher can evaluate, with a scope that holds because its exclusions are written down, and it treats declining or rescoping a request as a normal professional act rather than a last resort. **Where it sits in the research lifecycle.** After the brief has been interrogated (01.01), the question set built (01.02), the method selected (01.04) and the work planned internally (01.05). The internal plan comes first: a proposal whose timeline was never planned is a promise nobody has tested. **Typical use cases.** - A brief or tender must be responded to with a written proposal. - An internal study needs approval and funding from people who are not researchers. - The request exceeds what the budget or timeline can honestly support and must be rescoped. - A request should be declined, and the decline needs to be professional and specific. - A repeat client wants a study whose scope has drifted across three previous projects. - A proposal must set expectations that will survive contact with a difficult finding. **Who uses it.** Agency and consultancy researchers and directors writing proposals, independent researchers responding to briefs, client-side insight leads writing internal business cases, and evaluation teams responding to funder calls. Useful to a newer researcher as a structure and to an experienced one mainly as a discipline about exclusions and assumptions. ## 3. When to use it - A written proposal is required and the approach has been settled internally. - The buyer is not a researcher and the approach must be justified in their terms. - Scope needs to be fixed in writing before work starts, because it will otherwise be negotiated during delivery. - The request cannot be delivered as briefed and the response has to say so constructively. - Several scope options exist and the buyer should choose between them rather than negotiate quality invisibly. - A previous project overran on scope and the next proposal must prevent a repeat. - An internal study competes for funding against other calls on the same budget. ## 4. When NOT to use it - **For pricing methodology.** Rate construction, margin, commercial terms and price positioning are commercially specific and deliberately outside this library. This skill covers how scope drives effort, so that a buyer can trade scope knowingly, and it stops there. Where a price is required, it is produced by the organisation's own commercial process and this document supplies the scope it prices. - **When the plan is internal and no external buyer exists.** The execution document (activities, dependencies, owners, risk register, the honest internal timeline) is **01.05 Research Plan Development**. This skill produces the client-facing offer, and it depends on 01.05 having been done first. Where the two conflict, the internal plan is the truth and the proposal is corrected. - **When the question is not settled.** A proposal for an unformed question sells an ambiguity, and the ambiguity is discovered during delivery at the supplier's cost. Route to **01.01 Research Brief Interrogation** and **01.02 Business Problem to Research Question**. - **When the method is not settled.** Proposing a method chosen for saleability is the failure this skill exists to prevent. Use **01.04 Research Method Selection**, and if its honest verdict is that no primary research is needed, that verdict goes into the proposal rather than being suppressed. - **When you cannot deliver what is being asked for.** Capability, capacity and access are not negotiable by optimism. The correct output is a decline with the reason, or a proposal for the part you can deliver with the remainder named explicitly as out of scope. - **When responding would create a conflict of interest, or when the research as briefed could not be conducted ethically.** Route to **13.05 Research Ethics and Consent Design** before responding, and where the conflict is commercial, disclose or decline. A proposal is not the place to defer an ethics question. - **For an academic funding application.** Grant and doctoral proposals have their own conventions of theoretical framing, contribution to knowledge and reviewer expectations. Use the academic skills in **Category 15**. - **To reopen a lost pitch.** A revised proposal sent after a decision is rarely read and frequently damages the relationship. The useful act is a debrief request, not a resubmission. ## 5. Required inputs **Required.** - **The interrogated brief** (01.01): the decision, the assumptions register, the stakeholder map, the scope boundary and the blocking questions with their answers or stated defaults. - **The agreed question set and objectives** (01.02). - **The selected method and its design specification** (01.04), including what the design cannot answer, which is a required section of the proposal and not an optional caveat. - **The internal plan** (01.05): the real timeline, the dependencies, the resource requirement and the risks. Without it, the proposal's timeline is a guess presented as a commitment. - **The buyer's evaluation criteria**, where they are stated. A tender with published criteria is answered against them, and a proposal that ignores them loses to a weaker one that did not. **Optional, and what each one adds.** - **The sampling design (01.06).** Turns "a nationally spread sample" into a specification the buyer can evaluate, and makes the base limitations visible before rather than after. - **The analysis plan (01.07).** Lets the proposal specify what will be tested and reported, which is a strong differentiator and prevents the post-hoc cut request arriving as a scope surprise. - **Previous work with this client**, including anything that overran. The best guide to which assumptions will fail and which review cycles will slip. - **The buyer's procurement and contracting requirements.** Determine format, mandatory sections and what a deliverable definition must contain to be enforceable. - **The decision-making group and its composition.** Determines the register the document is written in: a proposal read by a procurement panel, a marketing director and a data scientist needs one narrative and three depths of detail. ## 6. Questions to ask before starting 1. **Should we respond at all?** Why it matters: it is a real question with three legitimate negative answers (cannot answer the question as briefed, cannot deliver, should not deliver). Default if unanswered: run the Step 1 check explicitly and record the result, because an unexamined yes is how undeliverable work is won. 2. **Who reads this, and what do they need to be convinced of?** Why it matters: the approach section is written for the least technical decision maker, and the detail is written for the person who will check it. Default: assume a mixed audience with a non-researcher holding the decision, and structure accordingly. 3. **What is fixed: the budget, the date, or the scope?** Why it matters: it determines whether the proposal offers one design or a set of scope options. Default: assume budget is fixed and scope is the variable, and present options. 4. **What will the client have to do, and when?** Why it matters: client obligations that are invisible in a timeline become supplier delays. Default: state a standard set (instrument sign-off, sample provision if applicable, review turnarounds, availability for the debrief) with dates, and flag them as assumptions. 5. **What are we not doing?** Why it matters: the exclusions list is the commercially important half of the scope and the one most often omitted. Default: draft it yourself from the Step 4 boundary and put it in the document. 6. **What could make this cost or take more than we are proposing?** Why it matters: it becomes the assumptions register, which is the mechanism that makes a scope change a conversation rather than an argument. Default: list at least incidence, sample availability, number of review rounds, language coverage and stimulus provision. 7. **What will this study not be able to answer?** Why it matters: it belongs in the proposal, not in the report's limitations. Default: import it directly from 01.04 and state it plainly. ## 7. Step-by-step methodology **Step 1. Run the go, rescope or decline check before writing anything.** Three grounds for not proposing as briefed, each with its own response. **The method requested cannot answer the question**: propose the approach that can, explain the substitution in the understanding section, and let the buyer compare. **The constraints make any honest design impossible**: the budget, the date or the access will not support a study that could carry the claim required. Say which constraint bites, what would have to change, and offer the largest honest study that fits, clearly labelled as answering a narrower question. **The work should not be done**: a conflict of interest, an ethics problem, a decision already taken, or a question already answered by evidence the client holds. Decline with the reason. A correct result is a recorded decision, because the most expensive proposals in any consultancy are the ones nobody decided to write. This judgement carries a `RESEARCHER DECISION REQUIRED` marker where the ground is ethical (K5 §2.4) and a sign-off requirement where a decline is the recommendation. **Step 2. Write the understanding section, and write it better than the brief did.** Restate the decision, the question and the context in the client's own language, more clearly than they managed. This is the section that decides whether the rest is read. Three things must appear: the decision the research serves with its owner and date, the question in evidence terms rather than action terms, and the thing the client did not say but is true, which demonstrates that the brief was read rather than parsed. Where the interrogation found an assumption that matters, name it here as something to be tested rather than as a correction of the client, because a proposal is not the place to win an argument. A correct result is a section the client would recognise as an improvement on their own brief. **Step 3. Articulate the approach as a because-chain.** For each objective, write three linked statements: what we will do, what that produces, and why that answers your question. The third is the one usually missing and the only one a non-researcher can evaluate. "Twenty depth interviews with lapsed users, purposively spread across tenure and region" is a specification. "Twenty depth interviews with lapsed users, spread across tenure and region, which will produce reconstructed accounts of the decision to stop using the service, which is what tells you whether the cause sits in the product or in the alternatives available to them" is an approach. Two rules make this section work. No method term appears without its purpose attached in the same sentence. And no more technical detail appears in the main narrative than the least technical reader needs, with the rest moved to a specification appendix where the technical reader will find it and the buyer will not stumble over it. **Step 4. Define scope positively and negatively, and name the boundary cases.** Three lists. **In scope**: the objectives, populations, markets, languages, sample structure, session or interview counts, analyses and deliverables that are included, specified precisely enough to be enforceable. **Out of scope**: what is excluded, written plainly rather than defensively. **Boundary cases**: the things a reasonable person could read either way, resolved explicitly. The exclusions and boundary cases are where the commercial risk lives, and both are a service to the buyer as well as a protection for the supplier. Typical exclusions worth stating explicitly: additional markets or languages; re-cuts of the data for a different audience; additional presentations beyond the number specified; raw data, transcripts or working files; translation of deliverables; workshops and activation sessions; and further analysis of the dataset after delivery. A correct result is an exclusions list long enough to be slightly uncomfortable, because every item on it is a conversation that will otherwise happen during delivery under time pressure. **Step 5. Build the assumptions register.** Every assumption that, if wrong, changes effort, timeline or feasibility, each with three fields: the assumption, what happens if it is wrong, and when it will be verified. The standard set recurs across projects and should be present unless positively excluded: incidence of the target audience; availability of a sample source and, where the client supplies it, its size, quality and timing; the number of review rounds and the turnaround on each; client sign-off dates; provision of stimulus in final form; language coverage; access to internal data referenced in the approach; availability of named participants where interviews are with client-side stakeholders; and any required approval. The register does two jobs. It makes a scope change a factual conversation ("this rests on assumption four, which has not held") rather than a negotiation about goodwill. And it discloses honestly that a proposal is an estimate under stated conditions, which is what it is. **Step 6. Specify the deliverables to an acceptance standard.** For each: form, audience, approximate length or level of finish, the number of revision rounds included, the format of any data handover, and the acceptance criterion. "Report" is not a deliverable. "A written report of approximately twenty-five pages answering the four objectives, with an evidence appendix, delivered as a document and presented once to the programme board, including one round of revisions, accepted when the sponsor confirms the four objectives are addressed" is. Then state what is not delivered, separately from the general exclusions, because deliverable ambiguity is the single largest source of unbilled work: raw data files, transcripts, recordings, the analysis workbook, additional cuts, and re-versions for other audiences. Where a deliverable will carry a named researcher's name or be published externally, note that it requires sign-off (K5 §2.8). **Step 7. Present the timeline as a mutual commitment.** Take the internal plan's timeline (01.05) and convert it, without compressing it. Two rules distinguish a proposal timeline from a wish. Client obligations appear on the chart with their own durations and dates: instrument sign-off, sample provision, review turnarounds, stakeholder availability, approvals. And the dependencies are visible, so the buyer can see that a delay in their review moves the delivery date rather than being absorbed. State the assumed review turnaround explicitly (it belongs in the assumptions register too), because a timeline that assumes instant client response is a timeline that will slip and be blamed on the supplier. Where the requested date cannot be met honestly, say so here with the options, rather than proposing it and managing it later. **Step 8. Show how scope drives effort, and present options rather than a single number.** Without pricing, and without inventing costs, name the drivers that move effort and let the buyer trade against them: the number of objectives; the number of subgroups that must be separately reportable, which drives sample and therefore most of the cost of a quantitative study; the number of markets and languages, which multiplies design, fieldwork, translation and analysis rather than adding to them; the number of stimulus items; session count and length in qualitative work, where analysis effort scales with volume more steeply than fieldwork does; the number of deliverables and revision rounds; and the degree of integration required in mixed-method work, since two strands genuinely integrated cost more than two strands reported side by side. Then present two or three scope options, each answering a stated subset of the objectives, with what each does and does not deliver. This is the mechanism that lets a buyer reduce cost by reducing scope knowingly, instead of the alternative, in which the same money buys a quietly thinner study. Never present the options as good, better and best, which is a sales frame; present them as answering different questions. **Step 9. State what the study will not answer, in the proposal.** Import it directly from the method selection (01.04) and write it in plain language near the front, not in an appendix. The commercial argument for this is stronger than the ethical one, though both hold: a study is judged against what its audience assumed it covered, and the cheapest possible protection against a disappointed client is a list they read before they bought. Where the design carries a known limitation that a stakeholder is likely to challenge (a non-probability sample, a base that will not support a regional cut, an inability to attribute cause), name it here with the reason it is acceptable for this decision. **Step 10. Add the governance section, and keep it short.** Four items, briefly: data protection and the lawful basis for processing personal data in this design; ethics and consent arrangements, with any approval named as a dependency; AI involvement in the work, disclosed in a form appropriate to the buyer, stating what AI does and what a human verifies (K5 §7); and the named individuals accountable for the work. Buyers increasingly require all four, and a proposal that treats them as boilerplate is easy to distinguish from one that does not. **Step 11. Write the decline or the rescope, where that is the answer.** The structure that works is short and specific. What was asked. Why it will not answer the question, in one or two sentences of reasoning the buyer can follow. What would answer it. What that costs in scope terms (more time, fewer objectives, a different audience, a different claim). And, where you cannot deliver it, saying so plainly. Two things make this land: it must contain something useful the buyer can take away even if they go elsewhere, and it must not read as a negotiating position. A decline that gives the buyer a better way to frame their next brief is remembered favourably; a decline that reads as a bid for more budget is not. ## 8. Analytical framework Decision (from 01.01) → Question and objectives (01.02) → Approach: what we do → what it produces → why it answers the question → Scope: in / out / boundary cases → Assumptions: what this rests on, and what happens if it fails → Deliverables: form, audience, revisions, acceptance criterion → Timeline: our obligations and yours → Effort drivers: what the buyer can trade → What this will not answer Read downward when writing. The because-chain in the third row is the load-bearing element: every row beneath it is a commitment, and a commitment made without the reasoning above it is a scope item nobody can defend when it is challenged. Read upward when reviewing. Take any commitment in the document and ask what objective it serves and what decision that objective feeds. Anything that cannot answer is either unnecessary scope, which should be removed and offered as an option, or an assumption pretending to be a commitment, which belongs in the register. ## 9. Output format A **Research Proposal**, in this order. Section names may be adapted to a buyer's template; the content requirements do not move. **1. Understanding.** The decision, its owner and date; the question; the context, including what the brief did not say. **2. Objectives.** As agreed, in the client's language, each traceable to the decision. **3. Approach.** The because-chain per objective. Method terms carry their purpose. Technical specification is referenced, not embedded. **4. Scope.** | In scope | Out of scope | Boundary cases and how they are resolved | **5. Deliverables.** | Deliverable | Form and length | Audience | Revision rounds | Acceptance criterion | Plus an explicit "not delivered" list. **6. Timeline.** | Stage | Duration | Our obligations | Your obligations | Dependency | **7. Assumptions register.** | Assumption | If it does not hold | Verified by / when | **8. What this study will not answer.** Plain language, near the front rather than at the back. **9. Scope options.** | Option | Objectives answered | Included | Not included | Relative effort drivers | **10. Governance.** Data protection, ethics and consent, AI involvement and human verification, named accountability. **11. Team and roles.** Who does the work, with the specific relevant experience, and who is accountable. **When the evidence is thin.** A proposal is written under uncertainty, and the honest handling is the assumptions register rather than confident specificity. Do not state incidence, feasibility, response rates, durations or sample availability as established unless they were supplied or verified; state them as assumptions with their consequence (K4 §2.1). Where feasibility is genuinely unknown, propose a short feasibility stage as the first phase rather than pricing a study that may not be runnable. Where the honest answer is that no primary research is required, or that the question cannot be answered, that is the proposal. ## 10. Quality checks Run before the proposal is sent. These sit on top of K4 §8. 1. Was the go, rescope or decline decision made explicitly and recorded? 2. Does the understanding section restate the decision better than the brief did, with an owner and a date? 3. Does every method term in the narrative carry its purpose in the same sentence? 4. Could a non-researcher read the approach section and explain, in their own words, why it answers their question? 5. Is every objective traceable to the decision, and every scope item traceable to an objective? 6. Is the out-of-scope list present and specific, and does it include the items most likely to be assumed in? 7. Does every deliverable have an acceptance criterion someone could apply? 8. Is there an explicit "not delivered" list covering data, transcripts, additional cuts and re-versions? 9. Does the timeline show client obligations with dates, and does it match the internal plan without compression? 10. Does the assumptions register include incidence, sample availability, review rounds and any required approval? 11. Is "what this study will not answer" present, in plain language, and near the front? 12. Are scope options framed as answering different questions rather than as tiers of quality? 13. Is any figure, duration or feasibility claim stated as fact that was not supplied or verified? 14. Does the governance section address data protection, ethics, AI involvement and named accountability? 15. If the recommendation is to decline or rescope, is it stated as plainly as a positive proposal would have been? ## 11. Common failure modes | Failure | How to recognise it | How to prevent it | |---|---|---| | **The methodological wall** | Three pages of correct method that the buyer cannot evaluate | Step 3's because-chain, with technical detail moved to an appendix | | **Silent scope** | An in-scope list and no exclusions | Step 4's three lists, with boundary cases resolved explicitly | | **The undefined deliverable** | "Report and presentation" with no length, revisions or acceptance criterion | Step 6, and a separate "not delivered" list | | **The heroic timeline** | A schedule shorter than the internal plan, with no client obligations on it | Step 7: convert the internal plan without compressing, and show both sides | | **Assumptions as fine print** | Feasibility, incidence and review turnaround stated confidently in the body | Step 5's register, with consequences and verification points | | **Selling what is easy** | The same method proposed regardless of the question | Step 1, and the method comes from 01.04 rather than from the proposal | | **Limitations deferred** | The "cannot answer" list appears in the final report for the first time | Step 9: it belongs in the proposal, near the front | | **Good, better, best** | Three tiers differing in quality rather than in question answered | Step 8: options answer different subsets of objectives | | **Scope creep by kindness** | Every additional request absorbed during delivery because refusing is awkward | The exclusions list and the assumptions register make refusal factual rather than personal | | **AI: invented specifics** | Confident incidence, feasibility, durations or achievable sample nobody supplied | K4 §2.1. Assumptions register, or absent | | **AI: template completeness** | A polished proposal for a question that was never clarified | Step 1 and the required inputs. A proposal cannot repair an unformed question | | **AI: over-promising the design** | A short or generic "cannot answer" section | Import it from 01.04 unchanged. Every design has a substantial residual | | **AI: pricing drift** | Effort discussion sliding into rates, day counts or cost estimates | Effort drivers only. Pricing is the organisation's own commercial process | ## 12. AI guardrails Skill-specific. K4 applies in full and is not repeated here. 1. **Never state a price, rate, day count or cost estimate**, and never let the effort discussion imply one. This skill names the drivers that move effort and stops there. 2. **Never state incidence, feasibility, achievable sample, response rate or duration as established unless supplied or verified.** These belong in the assumptions register with their consequence. 3. **Never propose a method because it is saleable.** The method arrives from 01.04, and where its honest verdict is that less research or no research is needed, that verdict goes into the proposal. 4. **Never omit the "what this study will not answer" section, and never make it generic.** A short residual list is a sign the design was not examined, not a sign that it is strong. 5. **Never write a timeline that differs from the internal plan without saying what changed and why.** A proposal that promises a date the plan does not support is a commitment nobody has tested. 6. **Never present scope options as tiers of quality.** Options answer different questions; quality is not a variable a buyer should be able to purchase less of. 7. **Never name or imply a supplier, platform, panel or software product**, including in the credentials or approach sections. Capability is described in methodological terms. 8. **Never leave an ethics, consent or data protection question to be resolved after award.** Where it is unresolved, it is a stated dependency or the proposal is not sent (K5 §2.4). 9. **Never soften a decline into a hedge.** If the work should not be done as briefed, the document says so plainly and offers what would work. 10. **Never present AI involvement ambiguously.** State what AI does in the work and what a human verifies, in terms the buyer can evaluate (K5 §7). **Human review points** (see K5 §2 for the classes): - **Researcher sign-off required** on the whole proposal before it is sent. It is an external commitment carrying professional accountability. Class 2.8. - **Researcher decision required** where the recommendation is to decline or rescope. Class 2.4 where the ground is ethical, Class 2.1 where it is commercial judgement about the client relationship. - **Researcher decision required** where the honest timeline does not meet the requested date, and the choice is between a narrower study, a later one, and not proposing. Class 2.7. ## 13. Best-practice principles 1. **Restate the question better than the client wrote it.** It is the fastest available demonstration of competence and it costs one paragraph. 2. **Every method term carries its purpose.** A buyer cannot evaluate "purposive sampling across three tenure bands". They can evaluate "so that we can tell whether the problem is specific to new customers". 3. **The exclusions list is the proposal.** Everything else describes what you will do; the exclusions describe what the money buys, and they are the reason the scope holds under pressure. 4. **Propose what the question needs, then offer what the budget buys as a stated narrowing.** The order matters: showing the right answer first makes the compromise legible, and it survives the moment when the study is judged. 5. **Client obligations belong on the timeline.** A schedule that hides the reviewer's five days will slip, and the slip will be attributed to you. 6. **An assumption written down is a conversation; an assumption unwritten is an argument.** The register is the cheapest commercial protection available and it reads as professionalism rather than defensiveness. 7. **Deliverable ambiguity is where unbilled work lives.** Length, audience, revision rounds and an acceptance criterion, every time. 8. **Put the limitations in the sale.** A client who bought a study knowing what it would not answer is a different client from one who discovers it at the debrief, and the difference shows up in the next brief. 9. **Declining well is a business development activity.** A specific, useful decline is remembered; a vague one and an overreaching yes are both forgotten for different reasons. 10. **Write for the least technical decision maker, and satisfy the most technical reader in an appendix.** Both are reading, and they need different documents bound together. 11. **Do not negotiate quality invisibly.** When the budget will not stretch, reduce the scope openly rather than the sample, the analysis time or the number of sessions quietly. 12. **The proposal is the first deliverable.** It is the only evidence the buyer has of how you think, and it will be read more carefully than anything you produce afterwards. ## 14. Worked example Fictional scenario, digital product and user experience. All figures are illustrative and belong to the scenario. INPUT A membership organisation issues a short brief: "We want to redesign our member portal. We need user research: eight focus groups across our four member categories, and a usability study, delivered in six weeks, within a fixed budget. Please propose." **Process.** *Step 1, go, rescope or decline.* The interrogated brief (01.01) had established the decision: the board approves a redesign scope in eleven weeks, and the open question is which member categories the redesign prioritises. Method selection (01.04) had already found two problems. Focus groups are the wrong instrument for individual portal journeys, which are private, task-based and frequently involve members' own financial or professional information, and group dynamics would suppress exactly the accounts of failure that matter. And a usability study on the existing portal would answer where the current design fails, which is useful, but not which categories to prioritise, which is what the board decides. The response is a rescope, not a decline: the question is answerable, but not by what was asked for. *Step 2, understanding.* The proposal opened by restating the decision the brief had not mentioned: the board's category prioritisation in eleven weeks, and the fact that the redesign scope depends on it. It named the thing the brief had not said, which the interrogation had surfaced: two of the four member categories account for most portal support contacts, and the organisation's own service data already establishes where the volume sits, which removes an objective from the study rather than adding one. *Step 3, approach as a because-chain.* Three objectives, each written as do, produces, answers. For example: "Sixteen individual task-based sessions with members across the four categories, observed on the live portal, which will produce a record of where each category fails and what they do next, which is what tells you whether the categories fail in the same places or in different ones. That distinction is the board's decision." A member of the board's finance committee could evaluate that sentence, which was the test applied to every one. *Step 4 and the judgement call.* The brief's eight focus groups were out of scope, and saying so required care. The exclusions list named them explicitly with one sentence of reasoning, placed after the approach so that the buyer had already seen what was being offered instead. The boundary cases mattered more than expected: whether members who had abandoned the portal entirely were in scope (they were, as a separate recruitment stream, because they are the group the redesign is meant to recover), and whether staff who support members by telephone were in scope (they were not, and were offered as a scope option because their account is second-hand evidence of member experience, useful and weaker). *Step 7 and 8, timeline and options.* The internal plan (01.05) showed that six weeks was achievable only by removing the pilot and compressing recruitment, and that recruitment of the abandoned-user stream had no float. The proposal therefore offered two options rather than accepting the date. Option one delivered all three objectives in eight weeks, still three weeks ahead of the board. Option two delivered in six weeks by dropping the abandoned-user stream, which was stated as removing the study's ability to say anything about members the portal has already lost. Both were framed as answering different questions, not as different levels of quality. *Step 5, assumptions.* Eleven, of which four were material: that the organisation could supply a member contact list with category flags within five working days; that two rounds of review at five days each were the maximum; that the live portal would not change during fieldwork, which would invalidate earlier sessions; and that incidence of members who had used the portal in the last three months was as the service data implied, which was supplied by the client and labelled as client-supplied per K2 §6. OUTPUT A proposal with: an understanding section naming a decision the brief never mentioned; three objectives with because-chains a non-researcher could evaluate; sixteen individual sessions replacing eight focus groups, with the substitution explained once and without argument; an exclusions list naming the focus groups, staff interviews, additional member categories and any re-cut for the communications team; two scope options answering different questions; a timeline showing the client's five-day obligations on their own row; an eleven-item assumptions register; a plain-language statement that the study would not establish how common each failure is across the membership, and would not evaluate the redesign once built; and a governance section covering member data handling and the AI-assisted analysis steps with their human verification. ## 15. Advanced usage **Responding to a tender with closed access.** Where questions cannot be asked, every unresolved ambiguity becomes a stated assumption in a visible register, and the scope is written against those assumptions explicitly. Evaluators comparing bids can then see what each bidder assumed, which favours the honest response. Where the tender's specified method is wrong for its stated objectives, propose compliantly and add a clearly separated alternative with the reasoning, rather than substituting silently and risking disqualification. **Multi-phase proposals with a genuine gate.** Where feasibility, incidence or the shape of the second phase is genuinely unknown, propose phase one with a decision gate rather than pricing a whole programme on assumptions. Specify what phase one must establish for phase two to proceed, and what happens if it does not. Buyers generally prefer this once it is explained, because it converts their risk into a smaller commitment. **Proposals for repeat clients where scope has drifted.** Where three previous projects each absorbed additions, the new proposal is the moment to reset. List what has historically been delivered outside scope as explicitly included or explicitly excluded, and price the difference in scope terms. Doing it in the proposal is a normal commercial act; doing it in the middle of delivery is a dispute. **Internal business cases.** The same structure works, with two changes. The competition is other calls on the same budget, so the "what this study will not answer" section is where credibility is won against a rival proposal that promises everything. And the client obligations section is more important, not less, because internal stakeholders assume their own review time is free. **Writing the proposal that recommends less work.** Where the honest answer is that the question is partly answered by internal data, propose the smaller study and say what the client already knows. This loses some revenue and wins a disproportionate amount of trust, and it is the clearest available demonstration that the approach is driven by the question rather than by the sale. **Setting up for a difficult finding.** Where the study is likely to produce an unwelcome result, the proposal is the right place to establish that findings are reported whichever way they come out, and to agree the review and escalation process. Establishing it before the result exists costs nothing; establishing it afterwards is impossible. ## 16. Skill chain **Recommended previous skills** - **01.01 Research Brief Interrogation.** Hands over the decision, the assumptions, the stakeholder map and the scope boundary that this document formalises. - **01.04 Research Method Selection.** Hands over the approach, the rejected alternatives and the "cannot answer" list, all of which are required sections. - **01.05 Research Plan Development.** Hands over the tested internal timeline, the dependencies and the risks. Plan first, propose second. **Recommended next skills** - **01.06 Sampling Strategy** and **01.07 Analysis Plan Development**, where the proposal has been accepted and the specification must be built out. - **Category 02 Instrument Design**, once scope is agreed. **Runs well alongside** - **01.02 Business Problem to Research Question**, whose question set the objectives are drawn from. - **13.05 Research Ethics and Consent Design**, for the governance section and for any consent arrangement that is a dependency. - **13.06 AI Research Governance**, for the AI involvement disclosure the proposal must carry. --- A Yazi Supplied Skill and resource.