Turn a client brief into a project plan

A brief describes an outcome. A project plan describes the work. Getting from one to the other is the most valuable hour in any engagement, and it's the hour most often skipped — because it is tedious, and because a to-do list feels like a plan until the first dependency bites.

This is a repeatable method for turning a brief into a plan you can run a team from.

Start by extracting, not organising

Resist the urge to structure while you read. Do one pass whose only job is to pull every piece of work out of the document, in whatever order it appears. Include the obvious deliverables and the quiet ones: kickoff calls, asset collection, stakeholder reviews, accessibility checks, handover documentation, the training session nobody budgeted for.

You will end up with a messy list of thirty to eighty items. That's correct. A messy complete list beats a tidy incomplete one.

This is the step Strumap automates: upload the brief and it reads the document, extracts the actionable tasks, and hands you that raw list already tagged with a suggested role and effort estimate — so the tedious extraction pass is done before you start thinking.

Group the list into phases

Now impose structure. Most professional-services projects fit five phases:

1. Discovery — questions answered, access granted, requirements confirmed
2. Definition — architecture, wireframes, content plan, technical approach
3. Production — the bulk of the making
4. Quality — review, QA, revisions, accessibility and performance checks
5. Launch and handover — deployment, documentation, training, retrospective

Phases give you natural milestones, natural invoice points, and a way to explain progress to a client who doesn't want a task list.

Assign an owner to every task

Every task gets exactly one owner — a role at minimum, a name where you know it. Include the client as an owner: "approve homepage design" and "supply product copy" are real tasks with real durations, and making them visible changes how clients behave. A plan where the client owns nothing is a plan that will slip and appear to be your fault.

Estimate in hours, then in elapsed time

Two numbers matter and they are not the same. Effort is how many hours the work takes; duration is how long it occupies the calendar. A two-hour review that waits four days for a stakeholder is two hours of effort and four days of duration.

Estimate effort per task, then convert to duration using honest availability — if you are on this project three days a week, twenty-four hours of effort is two calendar weeks, not three days.

Map dependencies and find the critical path

Go through the list and mark what must finish before each task can start. Then trace the longest connected chain from kickoff to launch: that chain is your critical path, and it is the only thing that determines your end date. Tasks off the critical path have slack; tasks on it don't.

Two habits pay for themselves here:

• Pull client-owned tasks earlier. Asset collection and approvals are the most common causes of delay, and the easiest to start early.
• Break long single-owner chains. If one person owns eight consecutive tasks, your plan has no resilience.

Turn the plan into a schedule

Place the tasks on a calendar working forwards from the start date, not backwards from the deadline. Backwards planning produces schedules that are arithmetically valid and practically impossible. Then compare the result with the client's date and, if there's a gap, present options rather than heroics: reduce scope, add a resource, move the date, or phase the delivery.

Keep the plan alive

A plan that isn't updated stops being a plan within a fortnight. Two lightweight rituals are enough for small teams:

• Weekly: update status, re-estimate anything in flight, flag blocked items with a named owner and a date.
• At each milestone: compare planned versus actual, and adjust the remaining estimates using what you just learned rather than what you originally hoped.

What good looks like

• Every deliverable in the brief maps to at least one task
• Every task has one owner, an effort estimate, and a phase
• Client responsibilities are in the plan with dates
• Dependencies are marked and the critical path is known
• The schedule reflects real availability, not full-time fiction
• There is a stated process for what happens when something changes

FAQ

How detailed should a project plan be?

Detailed enough that a competent person could pick up any task and know what "finished" means, and no more. One-day tasks are the sweet spot; half-day granularity is usually over-planning.

Do small projects need a plan?

Yes, but a proportionate one. A two-week project needs the same structure at a fraction of the depth: phases, owners, dependencies, and the client's tasks made visible.

What's the difference between a scope and a plan?

Scope defines what will be delivered and what won't. The plan defines how and when it gets delivered, by whom. Scope is commercial; the plan is operational. You need both, and the scope comes first.

How do I plan when the brief keeps changing?

Plan the near term in detail and the far term in phases. Re-plan at milestones instead of continuously, and route every change through an explicit change-request step so the impact on date and price is visible each time.

---

Have a brief sitting in your inbox? Get started with Strumap — upload it and get a scoped, role-assigned task plan you can edit in minutes.