Get started
Blog · Steering

Planning a project: steps and best practices

A plan is a hypothesis, not a promise. Six steps to frame, break down and sequence, with what research knows about our estimation errors. · July 22, 2026 · 4 min read

Why our plans slip

There is a psychological reason before the technical ones. In 1979, Kahneman and Tversky already described our tendency to predict from the impression of the moment rather than from what happened in comparable cases. In 1994, Buehler, Griffin and Ross studied what they called the "planning fallacy": people underestimate how long their tasks will take, even when they know that similar tasks have overrun their forecasts before (Buehler et al., 1994).

The practical consequence: a plan is not a promise, it is a hypothesis you check against reality at regular intervals. The more detailed it is far into the future, the more likely it is to be wrong.

An open planner on a desk, ready for planning
An open planner on a desk, ready for planning

The six steps

1. Frame: an objective and non-objectives

A precise, measurable objective, along with what is explicitly excluded. Research on goal setting shows that specific, challenging goals lead to better performance than the vague "do your best" (Locke and Latham, 2002). Scope is also the first source of drift.

2. Break down: from deliverable to tasks

Start from the expected result and work down to the actions. One deliverable maps to one milestone, one milestone to tasks of less than a week. Why breaking down helps: see our article on task decomposition.

3. Sequence: dependencies and critical path

Some tasks only start after others. Spot the chain that determines the end date: that is what the Gantt chart should make visible.

4. Size: effort and capacity

Compare the volume of work with the team's real capacity, in available days rather than working days. What previous cycles produced is your best data, far more reliable than your intuition (that is the lesson of the planning fallacy).

5. Commit to few milestones

Three to five visible milestones, each with a written success criterion. Fewer, and you lack landmarks; more, and attention gets diluted.

6. Plan the review

Decide at the start when the plan will be reread, for example at the end of each iteration. A plan you reread changes gently; a frozen plan ends up changing all at once.

A project view in FluidOps: team members, sprint overview and task list.
A project view in FluidOps: team members, sprint overview and task list.

A short example (fictional)

A team has to publish a website by December 15. Objective: a live site with three pages and a contact form; non-objectives: blog and multilingual. Milestones: mockups approved, pages built, acceptance testing. To estimate, the team notes that the previous, comparable redesign took six weeks rather than the three that had been planned, and builds its plan on six. The gain is not precision; it is having a plan you will not have to disown at the first delay.

Sources

← Previous articleThe Gantt chart: how to read it and build it Next article →Tracking a project day to day: rituals and metrics