Project Breakdown SKILL.md

This is the exact file agents read, including the credit header and licence notice. Save it as project-breakdown/SKILL.md.

---
name: project-breakdown
description: "Turn any outcome into a plan someone can start today: a definition of done, scope, milestones, tasks small enough for one sitting, dependencies and owners, estimates with 20 to 30% buffer against the planning fallacy, a pre-mortem, a schedule and the first next action. Use whenever someone has a big project that keeps stalling, needs a project plan, wants to break down a goal or task, has a deadline to plan backwards from or asks where to start."
license: CC-BY-4.0
metadata:
  author: Afeez Adebayo
  author_url: https://afeezadebayo.com
  author_linkedin: https://www.linkedin.com/in/afeez-adebayo/
  author_x: https://x.com/za_icon
  source: https://afeezadebayo.com/skills-md/productivity/planning-tasks/project-breakdown/
  category: productivity
  subcategory: planning-tasks
  version: "1.0.0"
  created: "2026-10-10"
  updated: "2026-10-13"
---

# Project Breakdown

Big work stalls because it is shaped wrong, not because people are lazy. "Launch the new website" or "write the report" sits on a list for weeks because nobody can start a project; they can only start a next action. Projects also slip because the finish line is vague, dependencies surface late, estimates are optimistic and risks are discovered after they hit. Research on the planning fallacy shows people routinely underestimate how long their own tasks will take. [Research, Kahneman and Tversky; Buehler and colleagues]

This skill turns any outcome into a plan someone can start today: a clear definition of done, milestones, a breakdown into tasks small enough to finish in a sitting, dependencies, owners, realistic estimates with buffer, risks found in advance and the very first next action.

## Operating principles
1. **Define done first.** A project without a finish line never finishes.
2. **Work backwards from the outcome.** Milestones, then tasks, then the next action.
3. **Small enough to start.** Every task should take one sitting, roughly two hours or less.
4. **Make dependencies visible.** Know what waits on whom before the plan starts.
5. **Estimate with buffer.** Add time for the unknowns everyone forgets.

## Inputs
- The outcome or project name, and why it matters.
- Deadline or target date, and whether it is fixed.
- People involved and their availability.
- Constraints: budget, tools, approvals, other commitments.
- Anything already done or decided.

## When to use, and when not to
Use it for any outcome that needs more than one step: launches, reports, events, moves, job searches, courses, renovations or personal projects that keep stalling.

Don't use it for large programmes with many teams, budgets and formal governance (the Product Management category) or for choosing between projects (`prioritisation`).

## Workflow

### Step 1. Write the outcome and definition of done
One sentence on the outcome, then three to five checks that prove it is finished. "Website live" becomes: pages published, forms tested, analytics recording, old URLs redirected, team trained.

### Step 2. Set scope
What is in, what is out, and what would be nice later. Cutting scope is often the fastest way to hit a date.

### Step 3. Define milestones
Three to six checkpoints that each produce something visible, such as "draft approved" or "beta with five users".

### Step 4. Break milestones into tasks
Verb-led tasks of two hours or less. Larger tasks are split again.

### Step 5. Map dependencies and owners
Which tasks wait on others, which wait on people outside the team, and who owns each task.

### Step 6. Estimate
Size each task (small, medium, large or hours), add them up, add 20 to 30% buffer, and compare with the deadline and available hours.

### Step 7. Run a pre-mortem
Imagine the project has failed and list why. This technique, described by Gary Klein, surfaces risks people are reluctant to raise. [Reference, Klein] Add a response for the top three risks.

### Step 8. Schedule
Place milestones on a calendar, book the first focus blocks and add check-ins.

### Step 9. Name the next action
The single first step someone can do today, added to the task list.

## Project plan template
```
# Project: <name>
Outcome: <one sentence>
Done when: <3 to 5 checks>
In scope / Out of scope / Later
Milestones:
1. <milestone> | target date | owner
Tasks (by milestone):
- [ ] <verb-led task> | size | owner | depends on
Estimate: <total> + 25% buffer = <total>; fits deadline? yes/no
Risks (pre-mortem): <risk> -> <response>
Check-ins: weekly in the weekly review
Next action: <first step today>
```

## Splitting large tasks
| Too big | Split into |
|---|---|
| Write the report | Outline sections; gather data for section 1; draft section 1; review with Sam |
| Plan the event | Choose three venue options; get quotes; confirm date with speakers |
| Learn Python | Install Python; complete lesson 1; write a script to rename files |
| Find a new job | Update career profile; set daily job search; tailor CV for first role |

## When the deadline does not fit
1. Cut or defer scope to the Later list.
2. Add people or move other work.
3. Move the date, explaining the trade-off early.
Never silently squeeze estimates to make the plan fit.

## Output format
```
1. Outcome and definition of done
2. Scope: in, out, later
3. Milestones with dates and owners
4. Task list with sizes, owners and dependencies
5. Estimate, buffer and fit with the deadline
6. Pre-mortem risks and responses
7. Schedule and check-ins
8. Next action
```

## Estimating more accurately
- Compare with similar past work rather than imagining the best case.
- Ask how long it took last time, not how long it should take.
- Estimate in ranges (best, likely, worst) for uncertain tasks and plan on the likely figure plus buffer.
- Include reviews, approvals, waiting time and rework, which are easy to forget.
- Re-estimate at each milestone with what has been learned.

## Keeping the project moving
Check the project in each weekly review: tick finished tasks, confirm the next action, chase dependencies and compare progress with the next milestone. If a milestone slips, decide immediately whether to cut scope, add time or move the date, and tell anyone affected.

## Project file
Keep each project in its own file, such as `projects/booking-launch.md`, with the plan template at the top and a short log of decisions and changes below. The agent can then update tasks from meeting notes and prepare status summaries on request.

## Status updates
A one-paragraph update works for most audiences: progress against the next milestone, what is done since last time, what is next, risks or help needed, and whether the date still holds. Sending it on a fixed day builds trust and surfaces problems early.

Keep updates short; link to the project file for detail.

Celebrate finished milestones briefly; momentum keeps long projects alive.

## Edge cases and judgement calls
| Situation | What to do |
|---|---|
| Unclear outcome | Ask what success looks like and who decides |
| Many unknowns | Plan the first milestone in detail and the rest roughly; add a research task first |
| Waiting on others | Make the request the first task, with a date to chase |
| Personal project with no deadline | Set a target date and a weekly slot |
| Project keeps stalling | Check the next action is truly small; check it still matters |
| Team project | One owner per milestone; share the plan in one document |

## Handoffs to related skills
- Choosing which projects to do: `prioritisation`
- Task list and next actions: `task-system-setup`, `task-capture-clarify`
- Scheduling the work: `time-blocking`
- Goals the project serves: `goal-setting-okrs`
- Weekly progress: `weekly-review`
- Getting started on avoided tasks: `procrastination-unblocking`

## Worked example
A small business owner wants to "launch online booking" before a busy season in eight weeks. Done when: booking page live, payments tested, confirmation emails working, staff trained and the old phone process retired. Milestones are tool chosen (week 1), setup complete (week 3), test bookings (week 5), staff trained (week 6) and launch (week 7). The breakdown produces 24 tasks; the estimate with 25% buffer is 38 hours against 40 available. The pre-mortem flags slow payment approval, so applying for the payment account becomes task one. Today's next action: compare three booking tools against a five-point checklist.

## Common mistakes
- Starting without a definition of done.
- Tasks that are still projects.
- Hidden dependencies on other people.
- Estimates with no buffer.
- No first next action.

## Self-check before you answer
- Is done defined with clear checks?
- Can every task be finished in one sitting?
- Are dependencies, owners and buffer included?
- Is there a next action for today?

---
Created by Afeez Adebayo, Marketing, SEO & Growth Expert
Website: https://afeezadebayo.com
LinkedIn: https://www.linkedin.com/in/afeez-adebayo/
X: https://x.com/za_icon
Source: https://afeezadebayo.com/skills-md/productivity/planning-tasks/project-breakdown/

Licence: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). You may copy, share and adapt this skill, including for commercial use, as long as you credit Afeez Adebayo and link to the source URL above. Keep this notice in any copy or adapted version.