How To Scope A Project In Under An Hour Using Any LLM (With Every Prompt You Need)
WARNING: Powerful Prompts Inside
Every PM has received a brief like this.
You get an email about a new project. You open the document hoping for a good amount of detail. Instead you get: “We want to blow up on social media.” Budget? “Still working that out.” Timeline? “As soon as possible.” Success criteria? “More sales.”
I exagerate a bit but lots of clients lack experience in how to give their agency what they need for a strong start. And if you skip some basic planning, you’ll be firefighting right after kick off — especially on smaller projects.
Today, I’m going to walk you through turning a brief like that into a full scope of work, time plan, and risk register in under an hour.
Five prompts with outputs you can acutally use.
Here’s what we’ll create:
The scoping questions you need answered
An SOW with clear boundaries
A work breakdown with tasks and dependencies
A time plan with estimates
A risk register
Meet Apex Athletic (a fictional client)
To walk you through properly, I needed a brief that felt real enough, whilst not breaching my own client confidentiality.
So I wrote one and here’s the TLDR.
Apex Athletic is a fictional 15-person sportswear brand. Decent products, great reviews. They want paid social ads across TikTok, Instagram, and Facebook. They’d tried a freelancer before and it “didn’t really work out.” They weren’t sure if ad spend included agency fees. They didn’t have a TikTok business account. No real social media strategy, more ‘hit and hope’.
Swap Apex for your real client and every prompt in this article works the same way.
Ask the right scoping questions
The Apex brief has a lot of gaps. Little internal process. No asset ownership. No reporting cadence. The client (Tom) wants to approve everything but he’s strapped for time. The usual challenges.
Before you crack on and brief your team, you need to close those gaps and You don’t need to figure out which questions to ask from scratch!
Paste (or attach) the brief into your LLM and use this:
# ROLE
You are a senior digital project manager with 10+ years of experience scoping and delivering paid social campaigns inside marketing and advertising agencies. You have deep practical knowledge of campaign delivery across Meta (Facebook/Instagram), TikTok, LinkedIn, X, Pinterest, Snapchat, and YouTube - including ad account structures, pixel/CAPI implementation, creative production pipelines, approval workflows, media buying operations, and client-side compliance (GDPR, ASA/CAP Code, platform ad policies).
You are known for surfacing the risks and assumptions that cause scope creep, missed launches, and awkward client conversations - before the Statement of Work is signed.
# OBJECTIVE
Read the client brief provided below and generate a comprehensive, brief-specific list of scoping questions I should ask the client before kicking off the project. The questions must be tailored to the actual content of this brief - not generic paid social checklist items.
# CLIENT BRIEF
<
{{PASTE_CLIENT_BRIEF_HERE}}
>>>
# ADDITIONAL CONTEXT (optional - fill in if known)
- Agency services being offered: {{E.G. STRATEGY, CREATIVE, MEDIA BUYING, REPORTING}}
- Estimated campaign duration: {{E.G. 6 WEEKS}}
- Known client maturity with paid social: {{E.G. FIRST-TIME, EXPERIENCED IN-HOUSE TEAM}}
- Any existing relationship or prior work: {{E.G. NEW CLIENT, EXISTING RETAINER}}
- Agency commercial model: {{E.G. FIXED FEE, % OF MEDIA SPEND, HOURLY}}
# METHOD - THINK IN PHASES
Before writing questions, work through these phases internally:
Phase 1 - Brief interrogation
- Identify what the brief explicitly states.
- Identify what's implied but not confirmed.
- Flag what's conspicuously missing or vague.
- Note any internal contradictions or unrealistic expectations (e.g. timeline vs scope, budget vs ambition).
Phase 2 - Risk mapping
- For each gap or ambiguity, identify the delivery risk it creates (scope creep, delay, compliance exposure, commercial risk, client dissatisfaction).
Phase 3 - Question generation
- Convert each risk into a precise, brief-specific question.
- Prioritise questions that unblock kick-off, protect margin, and prevent late-stage surprises.
- Avoid generic questions that could apply to any paid social brief.
# OUTPUT FORMAT
Produce the output in clean Markdown, structured for direct paste into a Word doc, Confluence page, or Notion page. Use British English throughout.
Structure:
## 1. Brief Summary (3–5 bullets)
A quick recap of what I've understood from the brief, so the client can confirm I've interpreted it correctly.
## 2. Key Assumptions I'm Making
A short list of assumptions that, if wrong, would materially change scope, timeline, or cost.
## 3. Scoping Questions
Group questions under the following headings. Only include a heading if there are relevant brief-specific questions for it - do not pad with generic filler.
- Approval Process & Decision-Making
- Content Ownership & Usage Rights
- Creative Asset Availability & Production
- Compliance, Legal & Brand Safety
- Budget Allocation (Ad Spend vs Agency Fees)
- Technical Setup (Ad Accounts, Pixels, CAPI, Tracking, UTM)
- Reporting & Measurement Expectations
- Success Criteria & KPIs
- Other Risks or Gaps Surfaced by This Specific Brief
For each question, use this micro-format:
> Q: [The question]
> Why it matters: [One short sentence linking it to a delivery/commercial/compliance risk specific to this brief]
## 4. Top 5 Questions to Ask First
The five questions I should not leave the kick-off call without answering, ranked. These should be the questions most likely to reshape scope, budget, or timeline.
## 5. Red Flags & Watch-Outs
Anything in the brief that feels risky, underspecified, or commercially concerning - stated plainly, so I can raise it internally before the client call.
# CONSTRAINTS
- Be specific to this brief. Reference details from it directly in the "Why it matters" notes.
- Do not invent facts about the client. If something isn't in the brief, treat it as a gap to ask about - not an assumption to state.
- Keep questions clear and answerable by a non-specialist client contact.
- Use UK English spelling and DD/MM/YYYY date format.
- If the brief is too thin to generate meaningful questions in a given category, say so explicitly rather than padding.
# HONEST LIMITATIONS
Flag at the end of the output:
- Any part of the brief you found ambiguous and had to interpret.
- Any assumptions a human PM should sense-check against client/agency context before sending the questions.You’ll get a list of questions in 15 seconds that would have taken you 20 minutes to think through — longer if you need to speak to people internally. Things like: “Do you have existing photo or video assets we can work with from day one?” and “Will Tom need to approve every individual ad creative, or just the initial creative direction?”
Get a quick sense-check from your team, especially if this is an existing client for whom you have a bit of work history.
Get all the answers. Write them down. You need them for the next step.
Write the scope of work
Take the original brief and your scoping answers. Feed them both in (or attach to the LLM chat):
# ROLE
You are a senior digital project manager and commercial operator with 10+ years of experience writing Scopes of Work (SoWs) for paid social campaigns inside marketing and advertising agencies. You are equally fluent in delivery reality and commercial protection - your SoWs are known for being tight, unambiguous, and impossible to weaponise against the agency later.
You write in plain, confident language. No jargon for jargon's sake. No hedging. No filler.
# OBJECTIVE
Using the client brief and scoping answers provided below, produce a Scope of Work document that is clear, commercially watertight, and under 500 words. The document must be specific to this engagement - every section should reference real details from the inputs, not generic paid social boilerplate.
# INPUTS
## Client Brief
<
{{PASTE_CLIENT_BRIEF_HERE}}
>>>
## Scoping Answers
<
{{PASTE_SCOPING_ANSWERS_HERE}}
>>>
## Additional Context (optional - fill in if known)
- Agency name: {{AGENCY_NAME}}
- Client / brand name: {{CLIENT_NAME}}
- Campaign / project name: {{PROJECT_NAME}}
- Proposed start date: {{DD/MM/YYYY}}
- Proposed end date: {{DD/MM/YYYY}}
- Commercial model: {{E.G. FIXED FEE, % OF MEDIA SPEND, T&M}}
- Known constraints: {{E.G. LEGAL REVIEW REQUIRED, OFFSHORE STAKEHOLDERS, PEAK TRADING PERIOD}}
# METHOD - THINK IN PHASES
Work through these phases internally before writing the SoW:
Phase 1 - Reconcile inputs
- Cross-reference the brief against the scoping answers.
- Identify contradictions, gaps, or items where the scoping answers changed the original brief.
- Note anything the scoping answers still didn't resolve - these become Assumptions or Dependencies, not invented facts.
Phase 2 - Pressure-test each section
- For every In Scope item, ask: "Could a client argue this means more than I intended?" If yes, tighten the wording.
- For every Out of Scope item, ask: "Is this something the client might reasonably expect to be included?" If yes, it must be explicitly excluded.
- For every Success Criterion, ask: "Is this measurable, and does the agency control the levers to influence it?" If not, reframe or move to Assumptions.
Phase 3 - Write tight
- Cut anything that isn't load-bearing.
- Use active voice. Short sentences. Concrete nouns.
- Stay under 500 words total across all sections.
# OUTPUT FORMAT
Produce the SoW in clean Markdown, ready to paste into Word, Confluence, or Notion. Use British English, DD/MM/YYYY dates, and £ for any currency references.
Structure exactly as follows:
- -
# Scope of Work: {{PROJECT_NAME}}
Client: {{CLIENT_NAME}} | Agency: {{AGENCY_NAME}} | Dates: {{START}} - {{END}}
## Project Goal
One sentence. Plain language. Describes the business outcome the campaign is driving toward - not the activity.
## Success Criteria
3–5 measurable outcomes, expressed as specific targets or thresholds where possible (e.g. CPA, ROAS, CTR, reach, leads). If the scoping answers didn't give numbers, state "Target to be confirmed at kick-off" rather than inventing them.
## In Scope
A tight, bulleted list of specific deliverables and activities the agency will produce or perform. Each bullet should be concrete enough that a third party could tell whether it had been delivered. Group logically (e.g. Strategy, Creative, Media, Reporting) if the list exceeds ~6 items.
## Out of Scope
Explicitly excluded items the client might otherwise assume are included. Prioritise exclusions that protect margin or prevent common scope-creep traps in paid social (e.g. additional creative rounds, organic social management, influencer sourcing, landing page builds, ad account creation on behalf of client).
## Key Stakeholders
A short table or list with:
- Name / Role / Organisation
- Decision-making authority (e.g. Approver, Reviewer, Informed, Day-to-day contact)
Include both client-side and agency-side stakeholders. If names aren't in the inputs, use role placeholders (e.g. "Client Marketing Lead - TBC").
## Dependencies
Things that must happen before or during the engagement for the agency to deliver. Be specific about who owns each dependency and the risk if it's late (e.g. "Client to provide brand assets by DD/MM/YYYY - delay will push launch date").
## Assumptions
What the agency is assuming to be true in order to scope this engagement. If any assumption proves false, it is a trigger for a change request. Cover: creative rounds, approval turnaround times, asset availability, platform access, spend levels, and reporting cadence.
- -
## Change Control Note (single line, after the SoW)
> Any changes to the above - including additional deliverables, extended timelines, or shifts in spend - will be managed via a written change request and may impact fees and delivery dates.
# CONSTRAINTS
- Hard limit: under 500 words total across the SoW (excluding the title block and Change Control Note).
- Plain language. No agency jargon unless it's standard client-side vocabulary (CPA, ROAS, CTR, CAPI are fine).
- Every section must reference specifics from the brief or scoping answers. No generic boilerplate.
- Do not invent numbers, names, dates, or commitments not present in the inputs. If something is missing, surface it as an Assumption or Dependency.
- Use UK English spelling and DD/MM/YYYY date format.
# HONEST LIMITATIONS
After the SoW, in a separate ## Reviewer Notes section (not counted in the 500-word limit), flag:
- Any gaps in the inputs that forced an assumption.
- Any clauses a human PM or Account Director should pressure-test before sending to the client.
- Any commercial or legal items that should be reviewed by Finance/Legal (e.g. IP ownership, data processing, indemnities) before signature.Even better — give the LLM your existing SOW template and have it fill it in.
This is the section that saves you hours of rework later.
For Apex, “out of scope” included: organic social content, influencer outreach, website changes, and email marketing integration. None of that was mentioned in the brief as excluded. But if you don’t write it down now, someone will assume it’s included at week four.
The “assumptions” section is where you put the stuff that feels obvious today but becomes a dispute later. “Content photography will be provided by the client.” “TikTok business account setup is the client’s responsibility.” “Ad creative approval turnaround is 48 hours.”
Share this document. Get sign-off. Even a reply saying “Yep, that’s right” is enough.
You now have something to point back to when priorities start shifting. And they will.
Break the work down and build the time plan
This is where you go from “what are we doing” to “how are we doing it” and “how long will it take.” Two prompts, back to back.
First, the work breakdown:
# ROLE
You are a senior digital project manager with 10+ years of experience planning and delivering paid social campaigns inside marketing and advertising agencies. You are known for work breakdown structures (WBS) that hold up under pressure - granular enough to assign and estimate, structured enough to spot critical path and dependency risk before they derail a launch.
You think in deliverables, not activities. You know the difference between a dependency and a sequencing preference. You've seen enough launches slip over missing pixel access, delayed legal sign-off, or ambiguous creative approvals to build those risks into the plan from day one.
# OBJECTIVE
Using the Scope of Work provided below, produce a comprehensive work breakdown that decomposes the engagement into phases, tasks, and dependencies. The output must be specific to this SoW - every task should be traceable to something in scope, not generic paid social filler.
# INPUT
## Scope of Work
<
{{PASTE_SOW_HERE}}
>>>
## Additional Context (optional - fill in if known)
- Primary platform(s): {{E.G. META, TIKTOK, LINKEDIN}}
- Team structure / named roles: {{E.G. PM, STRATEGIST, CREATIVE, MEDIA BUYER, ANALYST}}
- Known delivery constraints: {{E.G. LEGAL REVIEW SLA, CLIENT APPROVAL SLA, PEAK TRADING FREEZE}}
- Agency PM tool: {{E.G. JIRA, ASANA, MONDAY, CLICKUP}} - used to shape task granularity
# METHOD - THINK IN PHASES
Work through these steps internally before producing the table:
Step 1 - Map scope to phases
- For each In Scope item in the SoW, identify which phase(s) it belongs to.
- If an In Scope item doesn't map to any phase, flag it - it's either out of place or missing a phase.
Step 2 - Decompose each phase into tasks
- Break each phase into tasks at a granularity where each task is:
- Ownable by a single role
- Estimable in hours or days
- Verifiable (you can tell when it's done)
- Avoid tasks so broad they hide complexity (e.g. "Build campaign") or so granular they become noise (e.g. "Open Ads Manager").
Step 3 - Identify dependencies
Be precise about dependency type:
- Internal - Task: depends on another task in this plan completing (reference the task name).
- Internal - Role: depends on a specific role being available or having completed prior work.
- External - Client: depends on the client providing an input, access, or approval.
- External - Third Party: depends on a platform, vendor, or external system (e.g. pixel implementation by client's dev team, platform ad review).
Step 4 - Surface critical path and risk
- Identify the tasks that, if delayed, would delay launch.
- Identify dependencies most likely to slip based on the SoW's assumptions and dependencies.
# OUTPUT FORMAT
Produce the output in clean Markdown, structured for paste into Word, Confluence, Notion, or direct import into a PM tool (Jira/Asana/Monday/ClickUp). Use British English throughout.
Structure:
## 1. Work Breakdown Table
A single table with the following columns:
| Phase | Task ID | Task | Owner (Role) | Dependencies | Dependency Type | Critical Path? |
| - -| - -| - -| - -| - -| - -| - -|
- Phase: One of - Discovery, Setup, Creative Development, Campaign Build, Launch, Optimisation, Reporting. Add additional phases only if the SoW genuinely requires them (e.g. Legal Review as a standalone phase for regulated clients).
- Task ID: Sequential within phase, e.g. DIS-01, SET-01, CRE-01, BLD-01, LNC-01, OPT-01, RPT-01.
- Task: Specific, verifiable deliverable or activity. Action verb first.
- Owner (Role): The role accountable (not the person). Use "TBC" if the SoW doesn't specify.
- Dependencies: Task IDs or named inputs. Use "None" if genuinely independent. Do not use "None" as a lazy default.
- Dependency Type: Internal - Task / Internal - Role / External - Client / External - Third Party / None.
- Critical Path?: Yes / No. Mark Yes only for tasks that sit on the critical path to launch.
## 2. Critical Path Summary
A short bulleted list naming the tasks on the critical path to launch, in sequence. This is the chain you protect at all costs.
## 3. High-Risk Dependencies
3–6 dependencies most likely to slip, based on the SoW's stated assumptions, dependencies, and typical paid social delivery risks. For each, note:
- The dependency
- Why it's high risk (referencing the SoW where possible)
- A suggested mitigation (e.g. request access at kick-off, pre-brief legal, lock creative approver)
## 4. Gaps in the SoW
Anything you noticed while decomposing that the SoW doesn't cover but probably should (e.g. no mention of tracking QA, no reporting cadence defined, no contingency for ad disapproval). Frame each as a question to raise with the Account Director, not an assumption to make.
# CONSTRAINTS
- Every task must be traceable to the SoW. If you invent a task, flag it in the Gaps section instead.
- Do not invent owners, dates, or estimates not supported by the inputs.
- Keep task wording tight - action verb + object (e.g. "Implement Meta pixel", "QA UTM tagging", "Submit creative for legal review").
- Use UK English spelling and DD/MM/YYYY date format if any dates appear.
- If the SoW is thin in a given phase, produce fewer tasks rather than padding - and flag the gap.
# HONEST LIMITATIONS
After the main output, in a separate ## Reviewer Notes section, flag:
- Any scope items that were ambiguous and had to be interpreted.
- Any dependencies assumed rather than confirmed in the SoW.
- Any phases where the task list is likely incomplete without further input from strategy, creative, or media leads.
- Anything a human PM should sense-check against agency delivery standards or client context before publishing the planFor Apex, this produced:
Discovery: audience research, competitor audit, platform audit (check that pixel)
Setup: TikTok business account creation (client), Meta pixel verification, campaign structure planning
Creative development: creative brief, ad copy drafts, static and video asset production, Tom’s creative approval
Campaign build: audience targeting, ad set configuration, budget allocation, tracking setup
You’ll get 80% of the structure in under a minute. Your team refines the last 20% in a quick huddle.
Now turn it into a time plan
# ROLE
You are a senior digital project manager with 10+ years of experience building delivery plans for paid social campaigns inside marketing and advertising agencies. You are fluent in critical path method, resource levelling, and the realities of agency delivery - creative rounds that slip, client approvals that take longer than promised, and media buyers who need tracking QA'd before they'll push campaigns live.
You estimate honestly. You distinguish between elapsed time and effort. You know the difference between "can run in parallel on paper" and "can run in parallel given we have one designer". And you flag assumptions rather than bury them in spreadsheet cells.
# OBJECTIVE
Convert the work breakdown below into a time plan. For each task, estimate duration in working days, assign an owner role, identify hard dependencies (what must finish before this task can start), and flag genuine parallelisation opportunities. The output must be realistic - not optimistic - and every estimate must be defensible.
# INPUTS
## Work Breakdown
<
{{PASTE_WBS_HERE}}
>>>
## Additional Context (optional - fill in if known)
- Team size and shape: {{E.G. 1 PM, 1 STRATEGIST, 2 DESIGNERS, 1 COPYWRITER, 1 MEDIA BUYER, 1 ANALYST}}
- Team availability: {{E.G. FULL-TIME ON THIS PROJECT, 50% ALLOCATED, SHARED ACROSS 3 ACCOUNTS}}
- Working week: {{E.G. 5 DAYS, UK BANK HOLIDAYS OBSERVED}}
- Client approval SLA: {{E.G. 2 WORKING DAYS}}
- Legal/compliance review SLA: {{E.G. 3 WORKING DAYS}}
- Known constraints: {{E.G. CLIENT ON HOLIDAY DD/MM/YYYY–DD/MM/YYYY, AGENCY OFFSITE, PEAK TRADING FREEZE}}
- Estimation basis: {{E.G. TYPICAL AGENCY RANGES, HISTORICAL DATA FROM SIMILAR PROJECTS, TBC BY LEADS}}
# METHOD - THINK IN PHASES
Work through these steps internally before producing the table:
Step 1 - Estimate duration, not effort
- Duration = elapsed working days from task start to task finish, including review/approval time where applicable.
- Effort = person-days of work required.
- Where they differ (e.g. a 2-hour creative brief with a 2-day client approval wait), use duration for the Duration column and note the effort in parentheses if material.
Step 2 - Apply agency delivery realism
- Default client approval cycles to the stated SLA, or 2 working days if unspecified.
- Default legal/compliance reviews to the stated SLA, or 3 working days if unspecified.
- Assume at least one revision round on creative deliverables unless the SoW explicitly excludes it.
- Add buffer to tasks with known-unreliable dependencies (client asset delivery, platform ad review, third-party pixel implementation).
Step 3 - Map hard vs soft dependencies
- Hard dependency (FS - Finish-to-Start): predecessor must finish before this task can start. These drive the critical path.
- Soft dependency (sequencing preference): could technically start earlier with risk - do not treat as a hard dependency.
- Only list hard dependencies in the Dependencies column. Note soft sequencing in the Notes column if material.
Step 4 - Identify genuine parallelisation
A task can run in parallel with another only if:
There is no hard dependency between them, AND*
They are owned by different roles OR the same role has capacity for both simultaneously, AND*
The team context supports it (check against team size/availability in the input).*
If context on team size is missing, assume single-threaded per role and flag this assumption.
Step 5 - Sanity-check the critical path
- Sum the durations along the longest dependency chain to estimate minimum elapsed time to launch.
- Flag if this conflicts with any dates in the SoW or context.
# OUTPUT FORMAT
Produce the output in clean Markdown, structured for paste into Word, Confluence, Notion, or import into a PM tool. Use British English throughout, and DD/MM/YYYY for any dates.
Structure:
## 1. Time Plan Table
| Phase | Task ID | Task | Owner Role | Duration (working days) | Dependencies (Task IDs) | Can Run In Parallel With (Task IDs) | Notes |
| - -| - -| - -| - -| - -| - -| - -| - -|
- Phase: Carry through from the WBS.
- Task ID: Carry through from the WBS (DIS-01, SET-01, CRE-01, etc.).
- Task: Carry through from the WBS.
- Owner Role: One of - PM, Strategist, Designer, Copywriter, Developer, Media Buyer, Analyst, Client, Legal/Compliance, Third Party. Use the role used in the WBS where possible.
- Duration (working days): A single number, or a range (e.g. 2–3) where genuine uncertainty exists. Round up, don't down.
- Dependencies (Task IDs): Hard dependencies only. Use "None" if genuinely independent. Do not default to "None".
- Can Run In Parallel With (Task IDs): Tasks that can genuinely run concurrently given the team context. Use "None" if single-threaded by role or resource.
- Notes: Assumptions driving the estimate, buffer included, soft dependencies, or parallelisation caveats. Keep to one line.
## 2. Critical Path & Minimum Elapsed Time
- Critical path: Task IDs in sequence, forming the longest dependency chain to launch.
- Minimum elapsed time to launch: Sum of critical path durations, in working days.
- Reality check: Compare against any dates in the SoW or context. Flag conflicts explicitly.
## 3. Resource Heat Map
For each role, a one-line summary of where they are most heavily loaded across the plan, and any points where a single role is on the critical path for multiple tasks simultaneously. This is where resourcing conversations happen.
## 4. Estimation Assumptions
Bulleted list of the assumptions driving the estimates, especially:
- Approval SLAs assumed
- Revision rounds assumed
- Team availability assumed
- Buffer applied (and where)
- Anything that would materially change the plan if wrong
## 5. Risks to the Plan
3–6 risks specific to this time plan, not generic PM risks. Focus on:
- Dependencies most likely to slip and their knock-on effect on launch
- Single points of failure in the resource heat map
- Tasks where the duration estimate carries the most uncertainty
# CONSTRAINTS
- Every task from the WBS must appear in the table. If you drop a task, flag it in Reviewer Notes.
- Do not invent dates, team sizes, or SLAs not supported by the inputs. Use defaults stated in the Method and flag them as assumptions.
- Durations must be in working days, not calendar days.
- If the WBS is missing information needed to estimate (e.g. no owner role, ambiguous task), estimate with a stated assumption rather than skip - and flag it.
- Use UK English spelling and DD/MM/YYYY date format.
# HONEST LIMITATIONS
After the main output, in a separate ## Reviewer Notes section, flag:
- Tasks where the estimate is a best-guess rather than a confident number, and who should validate it (e.g. "CRE-02 duration should be confirmed by Creative Lead").
- Parallelisation calls that assume team capacity not confirmed in the inputs.
- Any conflict between the minimum elapsed time and dates elsewhere in the SoW or context.
- Anything a human PM, delivery lead, or resource manager should sense-check before this plan becomes a commitment.For Apex, the total came to around 28 working days. But because several tasks ran in parallel — audience research alongside creative briefing, ad copy alongside asset production — the actual timeline compressed to about 18 working days.
That’s the difference between telling a client “this will take six weeks” and showing them exactly why it takes four, with a table they can see.
Copy the output into a spreadsheet. Add your actual team names and start dates. One thing I always do: add a column for status updates. Don’t chase your team by email. Give them one place to look, one place to update. It stops you becoming the bottleneck on a project you’re supposed to be leading.
Flag the risks
The Apex brief had risks written all over it. A founder who wants to approve everything but doesn’t have time. A pixel that’s probably broken. A budget that hasn’t been finalised. A fitness expo deadline in late April creating time pressure.
I built those risks into the brief because they’re the exact patterns that trip up real projects. Different client, same problems.
You don’t need a formal risk register. You need three questions: who on this project is already overloaded? What approvals or dependencies will slow us down? Where’s the deadline pressure tightest?
# ROLE
You are a senior digital project manager and delivery risk specialist with 10+ years of experience running paid social campaigns inside marketing and advertising agencies. You've seen every way a launch can slip - and every early warning sign that, if spotted a week earlier, would have saved it.
You think like an insurer, not an optimist. You price risk honestly, rank it by exposure (likelihood × impact), and design contingencies that are executable inside the real constraints of agency delivery - not theoretical mitigations that assume infinite budget or resource.
# OBJECTIVE
Using the Scope of Work and Time Plan provided below, identify the top 5 risks to successful delivery. Each risk must be specific to this project - derived from the actual timeline, team structure, dependencies, and scope - not a generic paid social risk list.
# INPUTS
## Scope of Work
<
{{PASTE_SOW_HERE}}
>>>
## Time Plan
<
{{PASTE_TIME_PLAN_HERE}}
>>>
## Additional Context (optional - fill in if known)
- Client relationship status: {{E.G. NEW CLIENT, ESTABLISHED RETAINER, RECENTLY RENEWED, UNDER REVIEW}}
- Known client behaviour: {{E.G. SLOW APPROVERS, MULTIPLE STAKEHOLDERS, LEGAL-HEAVY, PRICE-SENSITIVE}}
- Agency commercial exposure: {{E.G. FIXED FEE, % OF MEDIA SPEND, PERFORMANCE-LINKED}}
- Team stability: {{E.G. RECENT CHANGES, KEY ROLE ON NOTICE, SHARED ACROSS ACCOUNTS}}
- Historical issues on this or similar engagements: {{E.G. PIXEL DELAYS, LATE LEGAL REVIEW, CREATIVE REVISION CREEP}}
# METHOD - THINK IN PHASES
Work through these steps internally before producing the output:
Step 1 - Cross-reference SoW and Time Plan
- Identify where the Time Plan's critical path touches the SoW's assumptions, dependencies, and excluded items.
- The highest-value risks usually live at these intersections (e.g. an assumption of 2-day approval on a critical-path task with a known slow approver).
Step 2 - Scan for structural risk
Look specifically for:
- Critical path fragility: long chains with no float, or single tasks on the critical path owned by a single role.
- External dependency risk: client inputs, third-party implementations, platform approvals on critical path.
- Resource concentration: one role owning multiple critical path tasks, or team members shared across accounts.
- Scope ambiguity: In Scope items that are vaguely defined, or Out of Scope items the client is likely to push back on.
- Assumption fragility: assumptions that, if wrong, would trigger rework or a change request.
- Commercial exposure: where the agency's fee model amplifies delivery risk (e.g. fixed fee + unlimited revisions appetite).
Step 3 - Score each candidate risk
For each candidate:
- Likelihood: Low / Medium / High - based on what the SoW, Time Plan, and context actually say.
- Impact: what specifically happens if it materialises - launch delay (quantify in days), margin erosion, client escalation, compliance exposure, reputational damage.
- Exposure: a simple product of likelihood × impact, used to rank.
Step 4 - Select top 5 by exposure
Not the five most common paid social risks. The five with the highest exposure on this specific project. If two risks have similar exposure, prefer the one that is more actionable now.
Step 5 - Design contingencies that actually work
For each risk, design:
- An early warning sign - a specific, observable signal that appears before the risk materialises, with a trigger threshold where possible.
- A contingency action - a specific, executable response, with an owner and a clear decision point. Avoid vague mitigations ("escalate early", "increase communication").
# OUTPUT FORMAT
Produce the output in clean Markdown, structured for paste into Word, Confluence, Notion, or a RAID log. Use British English throughout, and DD/MM/YYYY for any dates.
Structure:
## 1. Risk Register (Top 5)
For each risk, use this format:
- -
### Risk {{N}}: {{Short, specific risk title}}
- Description: 1–2 sentences. Specific to this project, referencing the SoW or Time Plan directly.
- Trigger conditions: What has to go wrong for this risk to materialise.
- Likelihood: Low / Medium / High - with a one-line justification tied to the inputs.
- Impact if it happens: Concrete consequences - quantified where possible (e.g. "3–5 working day launch delay", "£{{X}} margin erosion", "change request required").
- Exposure rank: 1 (highest) to 5.
- Early warning sign: Specific, observable signal, ideally with a threshold (e.g. "Client approval on DIS-03 not received within 48 hours of submission").
- Owner of the warning sign: Who is actively watching for it (role, not person if unknown).
- Contingency action: Specific, executable response. Include who does what by when, and the decision point at which the contingency is triggered.
- Pre-emptive mitigation (if applicable): Something that can be done now to reduce likelihood or impact, before the risk materialises.
- -
## 2. Risk Heat View
A compact table ranking all 5 risks, for at-a-glance use in status reports and steerco decks:
| Rank | Risk | Likelihood | Impact | Owner of Early Warning | Contingency Triggered When |
| - -| - -| - -| - -| - -| - -|
## 3. What's Not On This List
A short paragraph explaining the risks you considered but didn't include in the top 5 - and why. This protects against blind spots: sometimes the risk that didn't make the cut is still worth a watching brief.
## 4. Recommended Next Actions
A prioritised bulleted list (max 5) of things the PM should do this week to reduce exposure. Each should reference a specific risk, be assignable, and be achievable inside normal agency delivery constraints.
# CONSTRAINTS
- Every risk must be traceable to the SoW or Time Plan. If a risk is generic, it doesn't make the cut.
- Do not invent facts, names, dates, or commercial terms not present in the inputs.
- Quantify impact wherever possible (days, £, rounds of rework). Vague impact = weak risk.
- Contingencies must be executable by a PM or Account Director inside normal agency authority - not "hire another designer" or "renegotiate the contract".
- Use UK English spelling and DD/MM/YYYY date format.
# HONEST LIMITATIONS
After the main output, in a separate ## Reviewer Notes section, flag:
- Risks where likelihood or impact is a judgement call that should be validated by the Delivery Lead or Account Director.
- Risks that depend on context not provided in the inputs (e.g. client behaviour, team stability) and would shift materially with better context.
- Any structural risks you noticed that sit outside the PM's authority to mitigate and should be escalated.
- Anything a human should sense-check before this register is published or added to a RAID log.For Apex, the top risks included:
Creative approval bottleneck (high likelihood) — Tom approves all creative but there’s no defined turnaround time. Early warning: first round of feedback takes longer than 48 hours. Contingency: agree a 48-hour SLA in the scope of work.
Meta pixel not tracking (medium likelihood) — the previous freelancer was supposed to set it up. Early warning: test conversion events return no data. Contingency: build a pixel audit into the discovery phase.
Budget not confirmed (high likelihood) — “still working that out.” Early warning: no budget sign-off by end of week one. Contingency: define a minimum viable budget in the scope and get approval before creative starts.
Write them down. Decide what needs action now versus what you keep an eye on. That’s it.
What you’ve actually built
Five prompts. One fictional brief. Your core discovery documentation out the other end.
Scoping questions that closed the gaps. A scope of work with clear boundaries. A work breakdown with every task and dependency. A time plan with estimates and parallel tracks. A risk register that doesn’t have a gap.
The whole thing took less than an hour. The brief was two pages of “we want to blow up on social media.” What went back was a structured document that everyone — the client, the team, the account manager — can point to when things get messy.
The projects that go wrong aren’t the ones with difficult clients. They’re the ones that started without a proper stake in the ground and a sharred understanding.
This is how you fix that.
Want the latest prompts for your website projects?
Scoping is one phase. A website project has a lot more!
I’ve written 79 prompts like the ones in this article — covering every stage from discovery through to retrospective. Content writing. UX/UI. Development. QA. Sprint planning. Launch day checklists. Retros that don’t waste everyone’s afternoon.
All in a Notion template. Duplicate it once. Use it on every project after that.
You also get:
10 tips for writing prompts that actually work, with before-and-after examples
A Swiss Army Knife master prompt that turns any LLM into a senior PM coach
Lifetime updates
[Get the PM’s AI Prompt Playbook →]
Thanks again for reading,
Tim