---
name: research-plan-development
description: >
  Turns an agreed question and method into an executable plan. Use for "write the
  research plan", "build the project timeline", "how long will this actually take",
  "what are the dependencies", "the client wants it three weeks earlier, what
  breaks", "who is doing what on this study". Maps objectives to activities, phases
  the work against gate conditions, builds a timeline from the steps people forget
  (recruitment lead time, translation, review cycles, ethics approval), establishes
  the critical path, defines deliverables and roles, and prices compression in
  research quality rather than in money.
category: 01 Research Strategy and Design
ref: "01.05"
tier: 1
inherits: [K2, K3, K4, K5]
---

# Research Plan Development

## 1. One-line description
Converts an agreed question and method into an executable internal plan: objectives mapped to activities, phases with gate conditions, a timeline built backwards from the decision date, the critical path, defined deliverables, named roles, a risk register, and an honest statement of what compression costs the research.

## 2. What this skill is used for

**The research problem it solves.** Projects rarely fail on method. They fail on elapsed time, on a dependency nobody sequenced, and on the steps that are invisible until they are late: recruitment lead time for a low-incidence audience, translation and back-translation, the second and third rounds of client comment on the instrument, ethics approval, the pilot that changed the questionnaire, the week when the client's decision maker was unavailable. Plans built forward from today by adding up fieldwork and analysis produce timelines that are wrong in a predictable direction. The second failure is quieter: a compressed timeline is agreed and the compression is absorbed silently by the analysis stage, which is where the thinking happens, so the study is delivered on time and reasons badly. This skill builds the plan backwards from the decision date, names the invisible steps first, and makes every compression a stated trade rather than an absorbed one.

**Where it sits in the research lifecycle.** After the method is selected (01.04) and, where relevant, alongside sampling (01.06) and the analysis plan (01.07). It is the internal execution document. Where the work is being sold to an external buyer, the commercial proposal is a different artefact and belongs to **01.08 Research Proposal and Scope Development**.

**Typical use cases.**
- A study has been agreed and needs to be turned into something a team can run.
- A timeline has to be tested against a fixed decision date before anyone commits.
- A multi-strand or multi-market study needs its dependencies made explicit.
- A client asks for delivery three weeks earlier and the cost of that needs stating.
- A project is being handed to a team that did not design it.
- A study involves external approvals (ethics, legal, data protection) that must be sequenced rather than discovered.

**Who uses it.** Research managers and project leads, agency account and operations teams, client-side insight managers planning internal studies, UX research leads planning against a product cycle, and evaluation teams working to a funder's reporting calendar.

## 3. When to use it

- The method is agreed and someone has to work out whether it fits the time available.
- The decision date is fixed and the plan has not been tested against it.
- The study has more than one strand, more than one market, or more than one language.
- External approvals are required and nobody has established how long they take here.
- The team executing is not the team that designed, and the handover needs to be a document rather than a conversation.
- A previous project overran and you want to plan the same shape of work honestly this time.
- A compression request has arrived and you need to answer it with options rather than with yes or no.
- Several studies are running against the same internal resource and the contention needs to be visible.

## 4. When NOT to use it

- **When the method is not settled.** A plan built on an unchosen method plans the wrong work in convincing detail. Use **01.04 Research Method Selection** first, and return.
- **When the question is not settled.** Planning a study whose objectives are still a topic produces a schedule for an undefined activity. Route to **01.02 Business Problem to Research Question**, and if the brief itself is unclear, to **01.01 Research Brief Interrogation**.
- **When the deliverable required is a commercial proposal for an external buyer.** This skill produces the internal execution plan: activities, dependencies, roles, risks, and the honest internal timeline. It does not produce the client-facing approach narrative, the scope and exclusions statement, the assumptions register written for a buyer, or the commercial terms. That is **01.08**, and the two documents must be built in that order: plan the work, then write what you are offering. A proposal whose timeline was never planned internally is a promise nobody has tested.
- **When the sampling design is the open question.** This skill schedules recruitment and states its lead time. It does not set the frame, the size, the quotas or the subgroup bases. That is **01.06 Sampling Strategy**, and the plan should wait for it, because sample structure is the largest single driver of fieldwork elapsed time.
- **When the analysis specification is the open question.** The plan allocates analysis time and names who does it. What will be analysed, how, against what thresholds, belongs to **01.07 Analysis Plan Development**.
- **When the timeline cannot accommodate any honest version of the study.** The correct output is not a compressed plan. It is a statement that the study cannot be delivered to a usable standard by the date, the two or three things that would have to change, and the recommendation either to move the date, narrow the question, or not to run. Producing a plan that everyone can see is undeliverable makes the researcher complicit in the overrun.
- **When the work is a single short internal activity.** Planning apparatus for a two-day usability round with five participants is overhead that will not be read. Name the owner, the dates and the deliverable, and move on.
- **When ethics or data protection approval is genuinely in doubt rather than merely pending.** Do not plan around it. Resolve it first via **13.05 Research Ethics and Consent Design**; a plan that assumes approval is a plan with a single point of total failure.

## 5. Required inputs

**Required.**
- **The agreed method and design specification** (from 01.04): the method family, population, scale, channel, period and the analysis it implies. Without it there is no work to schedule.
- **The decision date**, and what happens by default if the research does not arrive in time. The plan is built backwards from this date, so an assumed one produces a plan that is wrong throughout rather than wrong at the end.
- **The objectives**, in the form 01.02 produces them, because the objective-to-activity map is the plan's backbone and its main quality control.
- **The hard constraints**: budget order of magnitude, fixed dates, the availability of the people who must review, and any approval that is mandatory before fieldwork.

**Optional, and what each one adds.**
- **The sampling design (01.06).** Converts recruitment from an estimate into a schedulable task, because lead time is driven by incidence and by the hardest quota cell, not by the total.
- **The analysis plan (01.07).** Makes the analysis allocation real rather than nominal, and frequently reveals that the analysis needs more elapsed time than the fieldwork.
- **Historical timings from comparable projects run by this team.** The only credible source of duration estimates. Without them, every duration is an assumption and must be labelled as one.
- **The client's or organisation's review and approval process**, with named reviewers and their typical turnaround. Review cycles are usually the largest hidden block in a research timeline and the one most often estimated at zero.
- **The organisation's calendar**: holidays, financial year end, seasonal periods when the audience is unreachable or atypical, and internal freeze periods.
- **The team's other commitments.** A plan that assumes full availability of people who are on two other studies is a fiction that will be discovered in week three.

## 6. Questions to ask before starting

1. **What is the decision date, and is it real?** Why it matters: everything is scheduled backwards from it, and a soft date and a hard date produce different plans. Default if unanswered: treat it as hard, plan to it, and state the assumption prominently.
2. **Who reviews, who approves, and how long do they actually take?** Why it matters: review cycles are the most under-estimated block in research planning and they sit on someone else's calendar. Default: assume two rounds of comment at five working days each, state the assumption, and mark it as the plan's largest uncertainty.
3. **What approvals are required before fieldwork can start?** Why it matters: ethics, legal, data protection, works council or client-side compliance are sequential blockers, not parallel tasks. Default: assume approval is required, ask early, and place it on the critical path until proven otherwise.
4. **How hard is the audience to reach?** Why it matters: recruitment lead time is driven by incidence and by the hardest cell, and it is the single largest source of schedule risk in most studies. Default: treat recruitment as unverified, plan a screening buffer, and mark the assumption for confirmation before commitment.
5. **What is fixed: the date, the scope, or the resource?** Why it matters: at least one usually gives, and knowing which determines whether the answer to a compression request is a narrower study, a later one, or a differently staffed one. Default: assume date fixed and scope flexible, and say so.
6. **Who is doing the analysis, and are they available in that window?** Why it matters: analysis is where the thinking happens and it is the stage most often compressed by upstream slippage. Default: name the analyst, protect the window explicitly, and flag any contention.
7. **What does the answer have to arrive as, and who signs it off?** Why it matters: deliverable form and level of finish drive a surprising share of the effort, and sign-off is a dependency with a person's calendar attached. Default: assume one written deliverable plus one presentation, one revision round, and state it.

## 7. Step-by-step methodology

**Step 1. Fix the anchors and plan backwards.**
Write three anchors: the decision date, the deliverable that carries the answer to that decision, and the date by which that deliverable must be in the decision owner's hands (which is earlier, because it has to be read, circulated and sometimes pre-briefed). Then schedule backwards. Forward planning from today produces a plan that ends when the work ends; backward planning from the decision produces a plan that shows immediately whether the work fits, and if it does not, it shows it on day one rather than in week six. A correct result is a backward schedule whose start date is either in the future (float exists) or in the past (the study is already late, and that is the finding).

**Step 2. Map objectives to activities in both directions.**
Build a two-column trace. For each objective, list every activity that contributes to answering it. Then reverse the read: for each activity, name the objective it serves. Two defects surface immediately and both are common. An **orphan activity** serves no objective and is cut, and it is usually a habit (a segment analysis nobody asked for, a deck section that exists because the template has one). An **unserved objective** has no activity behind it, which means it was agreed and never resourced, and it is the reason clients say the study did not answer their question. A correct result is a table with no orphans and no unserved objectives, or an explicit note of a decision to drop an objective, taken with the person who asked for it.

**Step 3. Phase the work by gate condition, not by calendar.**
A phase ends when a specific condition is met, not when a date passes. Write each phase with its gate: design ends when the instrument is signed off and any approval is granted; pilot ends when the decision to proceed, amend or re-pilot has been taken; fieldwork ends when the achieved sample meets the specification or the agreed shortfall is accepted; analysis ends when the findings are evidenced and checked; reporting ends when the deliverable is signed off. Gates matter because they are the only honest place to stop and reconsider, and a plan without them slides continuously rather than pausing at a decision point.

**Step 4. Build the timeline from the forgotten steps first, then add the obvious ones.**
This inversion is the practical heart of the skill. Enumerate the steps that are routinely omitted, before touching fieldwork and analysis. Recruitment and screening lead time, driven by the hardest cell. Instrument review cycles, internal and client-side, counted as rounds with named reviewers and realistic turnarounds. Translation, back-translation and the reconciliation conversation that follows, plus a cognitive check in each language, which is a separate task from translation. Ethics, data protection and legal approval, with their own submission windows. Programming and testing of the instrument, including the full logic test on every route. The pilot, and the decision point after it, which is a gate and not a formality. Incentive arrangements and their processing. Data processing, coding of open ends, and the checks that follow. Client review of findings, then review of the deliverable, as separate rounds. Sign-off on any quote or case study that names a person or an organisation. Public holidays, seasonal fieldwork dead zones, and internal freeze periods. Only after these are on the chart do you add design, fieldwork, analysis and writing. A correct result is a timeline in which the visible research activities occupy substantially less than the elapsed time, which is what a real research project looks like. Every duration is labelled as **historical** (from comparable work by this team), **supplied** (quoted by whoever will do it) or **assumed**. Never present an assumed duration as a known one (K4 §2.1).

**Step 5. Establish dependencies and find the critical path.**
Write the dependencies as relationships, not as an ordering: which tasks cannot start until another finishes, which can run in parallel, and which are constrained by a person's availability rather than by logic. Then trace the longest chain from start to the deliverable date: that is the critical path, and every task on it has zero float. Name the owner of each critical-path task explicitly, because the practical value of the critical path is knowing whose slippage matters. Then check for the two things a simple chain hides: resource contention, where two parallel tasks need the same person, which makes them sequential in practice; and external dependencies on people outside the project, which have no float and no accountability attached. A correct result names the three to five tasks whose slippage moves the delivery date, with an owner against each.

**Step 6. Define deliverables to an acceptance standard.**
For each deliverable: its form, its audience, its level of finish, the number of revision rounds included, and, most importantly, the acceptance criterion. "Topline report" is not a deliverable definition. "A written report of approximately twenty pages answering the four objectives, for the programme board, with an evidence appendix, accepted when the sponsor confirms the four objectives are addressed" is. An undefined deliverable generates rework, and rework consumes the analysis time of the next project. State also what is not delivered: raw data, transcripts, a workshop, a re-cut for a different audience. Where the deliverable will be attributed to a named researcher or published externally, mark it for sign-off per K5 §2.8.

**Step 7. Assign roles against activities, not against job titles.**
For every activity, name who does it, who reviews it, who decides where a judgement is required, and who is informed. Ambiguity here is discovered at the worst moment. Two roles are frequently left unassigned and should not be: who owns data quality decisions during fieldwork, and who owns the relationship with the person whose availability sits on the critical path. Mark the review points that fall into a K5 class (interpretation of ambiguous qualitative evidence, any recommendation, any external-facing claim) so they appear in the schedule as tasks with time attached rather than as assumptions.

**Step 8. Build the risk register, scored on impact to the decision.**
Each risk carries six fields: the risk, its likelihood, its impact **on the decision** rather than on the project, an early warning indicator that would be visible before it bites, the mitigation, and the trigger point at which the mitigation is enacted. The trigger is what distinguishes a register that works from one that is filed. Include the standard set, because they recur: incidence lower than assumed; response or cooperation below plan; attrition in any multi-contact design; data quality failure requiring exclusions; unavailability of a key reviewer or decision maker; scope change requested mid-project; loss of a key team member; failure or delay of an external service; an approval taking longer than assumed; and a finding that is politically difficult, which is a real project risk and is almost never written down. A correct result is a register in which every high-impact risk has an indicator that someone will actually observe.

**Step 9. Have the compression conversation with numbers rather than goodwill.**
When the plan does not fit, do not compress silently, and do not compress proportionally. Establish what is genuinely compressible and what is not. Usually incompressible: recruitment lead time for a low-incidence audience, statutory or institutional approval, translation quality, and the minimum fieldwork window needed to reach people who are not available on weekdays. Usually compressible, at a stated cost: number of objectives (cheapest, and the least damaging); depth of analysis; number of review rounds; the pilot; report finish; and the fieldwork window, which is compressible only by changing who ends up in the sample. Write each option as a cost sentence in research terms, not in money: "removing the pilot means the instrument goes live untested, and the most likely consequence is a question that does not work discovered in week one of fieldwork, when it can only be dropped rather than fixed"; "shortening fieldwork from three weeks to one changes the achieved sample toward people who respond immediately, which is a systematic difference and not a random one". Present two or three options with what each costs. This trade-off is a K5 §2.7 judgement, and it is marked `RESEARCHER DECISION REQUIRED`. The AI names the options and their costs; the researcher chooses and owns it.

**Step 10. Baseline the plan and control changes.**
Lock the plan with a date and a version. Then log every change: what changed, who asked, when, the effect on the critical path, and the effect on what the study will be able to say. That last field is the one that matters and the one usually omitted. A project that has absorbed four scope changes without recording their cumulative effect will deliver something nobody planned, and no one will be able to reconstruct how it happened (K2 §6).

## 8. Analytical framework

Two structures, crossed. The first is the trace that keeps the plan honest:

    Objective → Activity → Output → Deliverable → Decision

Read downward to build: each objective generates activities, which produce outputs, which are assembled into deliverables, which serve the decision. Read upward to check: every activity names its objective, every deliverable names the decision it feeds. Anything that cannot complete the upward read is removed at Step 2.

The second is the schedule structure:

    Phase → Gate condition → Dependencies → Duration (historical / supplied / assumed) → Float

Phases are separated by gates, not dates. Durations carry their provenance, so a reader can see which parts of the timeline are known and which are guessed. Float is what remains, and the tasks with zero float are the critical path.

Apply them together. The first structure tells you what work exists; the second tells you whether it fits. The plan is finished when every activity in the first appears in the second with an owner, a duration and a provenance label, and when the backward schedule from the decision date has a start point in the future.

## 9. Output format

A **Research Plan**, in this order.

**1. Anchors.** Decision, decision owner, decision date, the date the deliverable must land, and the default action if the research does not arrive.

**2. Objective to activity map.**

| Objective | Activities | Output | Deliverable it feeds |

Orphan activities and unserved objectives are listed explicitly beneath the table, with the decision taken on each.

**3. Phases and gates.**

| Phase | Starts when | Ends when (gate condition) | Owner |

**4. Timeline.**

| Task | Duration | Provenance (historical / supplied / assumed) | Starts after | Owner | Float |

The forgotten steps from Step 4 appear as named tasks, not as buffer.

**5. Critical path.** The three to five zero-float tasks, each with its owner and the effect of one week's slippage.

**6. Deliverables.**

| Deliverable | Form and length | Audience | Revision rounds | Acceptance criterion | Sign-off |

Plus an explicit "not included" list.

**7. Roles.** Per activity: does, reviews, decides, informed. K5 review points shown as scheduled tasks.

**8. Risk register.**

| Risk | Likelihood | Impact on the decision | Early warning indicator | Mitigation | Trigger point |

**9. Compression options**, where the plan does not fit. Each option with what it costs the research, carrying a `RESEARCHER DECISION REQUIRED` marker per K5 §2.7.

**10. Assumptions.** Every assumed duration, availability and approval, with the point at which it will be confirmed.

**11. Version and change log.**

| Version | Date | Change | Requested by | Effect on critical path | Effect on what the study can say |

**When the evidence is thin.** Durations that are not known are labelled assumed, not smoothed into a confident schedule. Where recruitment feasibility is unverified, the plan is presented as conditional on a feasibility check named as the first task. Where the plan does not fit the decision date under any honest configuration, the output is that statement plus the options, not a plan that fits on paper. Do not fill a timeline to make it look complete (K4 §1).

## 10. Quality checks

Run before the plan is circulated. These sit on top of K4 §8.

1. Was the schedule built backwards from the decision date, and does its start point lie in the future?
2. Does every objective have at least one activity, and every activity an objective?
3. Does every phase end on a stated condition rather than on a date?
4. Do the forgotten steps appear as named tasks: recruitment lead time, translation and its cognitive check, every review round, approvals, programming and logic testing, the pilot and its decision point, open-end coding, sign-off on named quotes, and calendar blackouts?
5. Does every duration carry a provenance label, and is the proportion of assumed durations visible?
6. Is the critical path identified, with an owner named against each zero-float task?
7. Has resource contention been checked, so that no two parallel tasks depend on the same person?
8. Do external dependencies (client reviewers, approval bodies) appear on the chart with their own durations?
9. Does every deliverable have an acceptance criterion a reader could apply?
10. Is there an explicit "not included" list?
11. Does every risk have an early warning indicator someone will actually observe, and a trigger point?
12. Is the analysis window protected, and would it survive a one-week slip in fieldwork?
13. Where compression is requested, is each option priced in what the study will be able to say rather than in money?
14. Does the change log record the effect of each change on the study's conclusions, not only on the schedule?

## 11. Common failure modes

| Failure | How to recognise it | How to prevent it |
|---|---|---|
| **Forward planning** | The plan starts today and happens to finish just before the deadline | Step 1: schedule backwards from the decision date |
| **The invisible middle** | Fieldwork and analysis are on the chart; translation, approvals and review rounds are not | Step 4's inversion: forgotten steps go on first |
| **Review cycles at zero** | Client comment appears as a two-day task, once | Count rounds, name reviewers, use their real turnaround or an explicit assumption |
| **Recruitment as a formality** | A single fieldwork bar with no lead time in front of it | Lead time is driven by the hardest cell, not the total (01.06) |
| **Analysis as the shock absorber** | Every upstream slip is absorbed after fieldwork closes | Protect the analysis window explicitly and test it against a one-week slip |
| **Silent compression** | A shorter plan appears with no statement of what was given up | Step 9: options with costs, routed to a human per K5 §2.7 |
| **Gate-free phases** | Phases end on dates, so nothing is ever reconsidered | Write the gate condition for each phase |
| **Unowned critical path** | The critical path is identified but nobody is named against it | Owner per zero-float task, always |
| **Approval assumed** | The plan runs as though ethics or legal sign-off will arrive | Approvals sit on the critical path until proven otherwise (13.05) |
| **AI: plausible durations** | Confident day counts for recruitment, fieldwork and translation that nobody supplied | K4 §2.1. Every duration is historical, supplied or assumed, and labelled |
| **AI: symmetric phases** | A tidy plan with equal-length phases that matches no real project | Durations come from the work, not from the shape of the chart |
| **AI: risk register as boilerplate** | Generic risks with generic mitigations and no indicators | Every risk needs an observable early warning and a trigger point, or it is deleted |
| **AI: compression resolved unilaterally** | The plan simply fits the requested date, with the trade absorbed | Name the options and their costs, then stop for the researcher (K5 §2.7) |

## 12. AI guardrails

Skill-specific. K4 applies in full and is not repeated here.

1. **Never state a duration, lead time, cost or availability as known unless it was supplied or drawn from stated historical data.** Label every other duration as assumed at the point it appears, not in a footnote.
2. **Never present a plan that fits the deadline by compressing a stage silently.** Compression is stated, priced in research terms, and routed to a human.
3. **Never omit an approval, translation or review step because it was not mentioned in the brief.** The plan's job is to surface what the brief left out; a missing step is a schedule failure waiting to happen.
4. **Never plan around an unresolved ethics or data protection question.** Escalate it; a plan that assumes approval carries a single point of total failure and disguises it as a task.
5. **Never assign a person to a task without their availability being established or the assumption being stated.** A named owner who is unavailable is worse than an unnamed one, because it looks resolved.
6. **Never produce a risk register of generic risks.** Each entry needs an early warning indicator specific to this study and a trigger point, or it is not a control.
7. **Never carry a plan forward once the decision or the method changes.** Re-run from Step 1: a plan is only correct relative to a decision date and a design.
8. **Never let the change log record schedule effects only.** Every scope change has a consequence for what the study will be able to say, and that field is the one a reader needs (K2 §6).
9. **Never present recruitment feasibility as established.** Unless incidence and reachability were verified, the plan is conditional and says so.

**Human review points** (see K5 §2 for the classes):
- **Researcher decision required** on any compression option, per Step 9. Class 2.7, methodological trade-offs under real constraints.
- **Researcher decision required** where an objective is to be dropped because no activity can be resourced for it. Class 2.1, business relevance and materiality.
- **Researcher sign-off required** on the final deliverable definition and on any output that will carry a named researcher's name. Class 2.8.

## 13. Best-practice principles

1. **Plan backwards from the decision, never forwards from today.** It is the difference between discovering the study does not fit on day one and discovering it in week six.
2. **The steps nobody schedules are the steps that overrun.** Translation, review rounds, approvals, programming and testing, open-end coding, and sign-off on named quotes. Put them on the chart first and the rest of the plan tells the truth.
3. **Recruitment lead time is set by the hardest cell.** A study is not recruited when most of the sample is in; it is recruited when the last difficult quota is filled, and that is where the elapsed time lives.
4. **Protect the analysis window like a fixed cost.** It is where the study's thinking happens, it is invisible when it is cut, and it is the default shock absorber for every upstream slip.
5. **Gates, not dates.** A phase that ends on a condition creates a moment to stop and reconsider. A phase that ends on a date creates a slide.
6. **A duration without a provenance is a guess with a number on it.** Label historical, supplied and assumed, and let the reader see how much of the plan is known.
7. **Name owners on the critical path, not just tasks.** The practical use of a critical path is knowing whose diary to protect.
8. **Client dependencies belong on the client's side of the chart, visibly.** A timeline that hides the reviewer's five days will slip, and the slip will be attributed to the researcher.
9. **Price compression in conclusions, not in days.** "Two weeks earlier" means nothing to a decision maker. "Two weeks earlier means no pilot and a sample skewed toward immediate responders" means something.
10. **Write the risk that nobody writes down.** That a finding will be politically unwelcome, that a key stakeholder will change role mid-project, that the decision date will move. These are the risks that actually materialise.
11. **A plan the team did not help build is a document, not a plan.** The people who will execute know where the durations are wrong, and they will tell you before it is expensive.
12. **Log the effect of every change on what the study can say.** Schedules recover; conclusions do not, and after four accommodations nobody remembers what was traded away.

## 14. Worked example

Fictional scenario, healthcare. All figures are illustrative and belong to the scenario.

    INPUT

    A regional health service has agreed a mixed-method evaluation of a new
    appointment reminder service for outpatient clinics. Two strands: depth
    interviews with patients who missed appointments, and a survey of clinic
    administrative staff. Three languages are in routine use across the
    catchment. The service improvement board takes its decision on whether to
    extend the service at its meeting in nineteen weeks.

**Process.**

*Step 1, anchors.* The board meets in nineteen weeks and papers circulate ten working days beforehand. The deliverable must therefore land at seventeen weeks and one day, not nineteen. Two working weeks were lost before any planning began, which is the most common single error in health service research planning and it was surfaced by the backward schedule.

*Step 4, the forgotten steps.* Placed on the chart before anything else. Research governance and information governance approval, submitted as one application, with a stated submission window and an assumed decision period labelled as assumed. Patient-facing materials translated into three languages, back-translated, reconciled, and cognitively checked with two speakers per language, which is a separate task from translation and was initially missing. Two rounds of clinical review of the interview topic guide, with named reviewers who are clinicians and therefore unavailable in blocks. Identification of patients who missed appointments, which requires an extract from the appointment system that must itself be requested and approved. Staff survey programming and full logic testing. A pilot of two interviews with a decision gate after them. Consent and sign-off on any quote naming a clinic. Together, these occupied more elapsed time than the fieldwork and analysis combined.

*Step 5, the critical path.* Approval, then patient identification, then recruitment of the hardest group (patients who missed appointments and are not currently engaged with the service, which is by construction a group that does not answer the telephone), then interviews, then analysis, then the deliverable. The staff survey sits entirely off the critical path and can run in parallel. Recruitment of the disengaged group has zero float and a single owner.

*The judgement call.* The backward schedule left three weeks of float in total, and the assumed approval duration consumed all of it if it ran long. Two options were built. Option A: submit the approval application before the topic guide is finally signed off, accepting a possible amendment later, which buys three weeks but risks a resubmission. Option B: reduce the patient strand from the planned range to its lower bound and start analysis on a rolling basis, which buys two weeks and costs coverage of one patient group.

> **Researcher decision required.** Neither option is free. Option A trades a
> resubmission risk for schedule certainty; Option B trades coverage of the
> group least likely to be reachable for the same. What turns on it: whether
> the evaluation can speak about disengaged patients, who are the group the
> reminder service exists to reach. This is a trade-off under constraint
> (K5 §2.7) and belongs to the researcher and the sponsor jointly.

*Step 8, risk register.* Nine risks, each with an indicator. The two with the highest impact on the decision: approval taking longer than assumed (indicator: no acknowledgement within ten working days of submission; trigger: escalate to the sponsor and enact Option B), and recruitment of the disengaged group falling short (indicator: fewer than four of the first twenty approaches converting; trigger: switch to an alternative approach route agreed in advance, rather than negotiating one under pressure in week nine).

    OUTPUT

    A Research Plan with: anchors showing a deliverable date two weeks earlier
    than the board date; an objective-to-activity map that removed one orphan
    activity (a demographic profiling analysis nobody had asked for) and flagged
    one unserved objective (staff workload effects, which had no activity and was
    formally dropped with the sponsor); five phases with gate conditions; a
    timeline in which approvals, translation and review occupied more elapsed
    time than fieldwork; a six-task critical path with owners; two compression
    options carrying a researcher decision marker; a nine-risk register with
    indicators and triggers; and eleven labelled assumptions, of which four were
    scheduled for confirmation in the first week.

## 15. Advanced usage

**Multi-market and multi-language studies.** Plan each market's chain separately and then find the joint critical path, which is usually the slowest market rather than the sum. The two things that break these plans are translation reconciliation, which needs a decision maker per language and cannot be parallelised at the end, and the assumption that approval processes are similar across markets. Build in a market-level gate before the whole set proceeds to analysis.

**Rolling analysis in qualitative work.** Where the timeline is tight, analysis can begin during fieldwork rather than after it, which recovers real elapsed time. The cost is that early sessions are coded before the frame has stabilised, which requires a re-pass. Plan the re-pass rather than pretending it will not be needed.

**Planning against a product or policy cycle.** Where the decision is a sprint boundary or a committee cycle, the date is genuinely immovable and the scope is the only variable. Build the plan at the minimum viable scope first and add objectives only where float exists. Doing it the other way round produces a plan that is cut in a hurry by whoever is least able to judge what matters.

**Contention across a portfolio.** Where several studies compete for the same analysts, moderators or reviewers, build the critical paths together and look for the weeks in which two zero-float tasks need the same person. That single view prevents more overruns than any individual project plan.

**Planning for a finding that will be unwelcome.** Where a difficult result is plausible, plan the handling: who is pre-briefed, when, and what the escalation route is. Adding this to the plan at the start is a normal professional act; adding it in week eleven looks like a manoeuvre.

**When the plan does not fit and the date will not move.** Present three honest configurations: the narrower study that fits, the full study that arrives late and what it would still be worth, and no study with the decision taken on judgement plus a monitoring plan. Naming the third option is what makes the first two credible.

## 16. Skill chain

**Recommended previous skills**
- **01.04 Research Method Selection.** Hands over the design specification: method, population, scale, channel, period and the analysis it implies. Without it, this skill schedules undefined work.
- **01.06 Sampling Strategy.** Hands over the sample structure that drives recruitment lead time, which is the largest schedule risk in most studies.
- **01.07 Analysis Plan Development.** Hands over the analysis specification, which determines how much analysis time is real rather than nominal.

**Recommended next skills**
- **Category 02 Instrument Design.** The plan schedules instrument development, review rounds and testing; 02.01 and 02.02 do the work.
- **01.08 Research Proposal and Scope Development**, where the plan must become a client-facing offer. Plan first, propose second.

**Runs well alongside**
- **13.05 Research Ethics and Consent Design**, wherever approval sits on the critical path.
- **12.03 Research Report Compilation**, which inherits the deliverable definitions and acceptance criteria set here.
- **13.01 Research Quality Review**, run against the plan before it is baselined.

---
A Yazi Supplied Skill and resource.