Planning and breaking work down

Ask for a project plan and you will get one: neat phases, tidy durations, sensible-looking milestones. It will be genuinely useful in one respect and quietly misleading in another, and the two are easy to confuse because they arrive in the same table.

Good at steps

Decomposition is a real strength. A model has read an enormous number of descriptions of how work gets done, so it is good at listing the steps something involves — including the unglamorous ones people forget.

Ask for the plan you have not thought of:

I need to [goal] by [date]. Here is what I have already thought of: [list].

What steps am I missing? Include the boring ones — approvals, access, waiting on other people, things that must happen before step one can start. Do not give me timings.

Two parts do the work. Telling it what you already have stops it repeating your own list back. And do not give me timings keeps the output in the area where it is reliable.

The answer to “what has to be true before step one can start” is where most plans actually fail. Access not granted. A form nobody knew existed. A person on leave.

Bad at durations

Now the part to distrust.

A duration in a plan looks like a measurement. It is not — it is a plausible number, drawn from how long tasks like this are described as taking, in general, by people writing on the internet.

It knows nothing about your approval chain, your team’s other commitments, how long your organisation takes to answer an email, or the fortnight in December when nothing moves. It is also systematically optimistic, because written accounts of work are optimistic; people describe the intended path far more often than the one with three weeks of waiting in it.

So take the steps and put your own numbers against them. You know things the model structurally cannot.

Ask what would go wrong

The other genuinely strong move is inverting the plan:

Assume this plan failed. It is [date] and we missed it. Give the five most likely reasons, most likely first. Be specific — “poor communication” is not a reason.

This is a pre-mortem, and it works well because failure modes are heavily documented. Named specifically, several will be things you can cheaply prevent now: a dependency nobody owns, an approval with a two-week queue, one person holding three critical steps.

Keep the plan yours

A plan is a commitment you will be held to, which puts it firmly in L1’s expensive-to-check column. Use the assistant for the shape — steps, dependencies, failure modes — and own the judgement: what matters, what can slip, what you will actually do when it does.

Try it now (6 minutes)

Take something you are planning. List the steps you have thought of, then ask what is missing, explicitly excluding timings.

Then run the pre-mortem. Pick the one failure reason that made you wince and deal with it today.

Check your understanding

1. What are assistants genuinely reliable at in planning? Estimating how long each step will take Listing steps and dependencies you have forgotten Deciding which milestones matter most

2. Why are AI time estimates systematically optimistic? Models are designed to be encouraging Written accounts of work describe the intended path more often than the delayed one They assume you work full time on the task

3. A pre-mortem asks: What could go wrong, in general terms Assume it failed — what are the most likely specific reasons How long each phase should take

Recap

Use an assistant to find the steps and dependencies you missed, and to run a pre-mortem on a plan you already have. Do not take its durations — they are plausible numbers, not measurements of your situation, and they lean optimistic. The steps can be borrowed; the commitment stays yours.