Project Planning Steps: A Checklist and Time to Plan First

Project planning steps turn a goal into work that a team can start, track and finish. Most guides list the same core steps, but people skip them because planning feels slower than doing. This guide explains what project planning is and why planning is important, then walks through eight steps with a checklist. It also covers the planning fallacy, which makes estimates too short, and how to protect time for planning before the work starts.

What is project planning?

Project planning is the work you do before a project starts to decide five things:

• what the project must deliver,
• which work that takes,
• who does each part,
• when each part happens,
• what could go wrong.

The result is a plan: a written outcome, a list of tasks with owners and dates, and a short list of risks. The plan is a reference point. When something changes, you update the plan and compare progress against the new version.

Planning is different from task breakdown. Breaking work into tasks is one step inside planning, and we cover it in detail in our guide to task breakdown. This article covers the whole planning process around that step.

Why planning is important

Planning finds problems while they are cheap to fix. Bent Flyvbjerg, a researcher who studies large projects, calls the pattern of successful projects “think slow, act fast.” In a 2023 CBRE podcast interview, he described what most projects do instead: “People think fast and then they’re forced to act slow because there are so many things they didn’t think through.” He also said that only about 8.5% of the projects in his data were delivered on time and on budget.

The causes of failed projects point to planning gaps. In PMI’s 2018 Pulse of the Profession survey, respondents cited these as primary causes of failed projects:

• inaccurate requirements gathering (35%),
• an inadequate vision or goal for the project (29%),
• opportunities and risks that were not defined (29%),
• inaccurate cost estimates (28%),
• inaccurate task time estimates (25%).

Steps 1, 2, 5 and 7 below address these causes.

The planning fallacy: why estimates run short

In 1979, psychologists Daniel Kahneman and Amos Tversky named the planning fallacy: people expect their own project to go as planned, even when they know that most similar projects ran late.

Roger Buehler, Dale Griffin and Michael Ross tested the idea in a 1994 study in the Journal of Personality and Social Psychology. In one part, they asked final-year psychology students when they would finish their honors thesis. The study found:

• The students’ best estimate was 33.9 days on average, and they took 55.5 days.
• Only 29.7% finished by the date they gave as their most accurate prediction.
• Even their worst-case estimate, 48.6 days on average, was shorter than the actual time.
• Fewer than half (48.7%) finished by their worst-case date.

The same paper found a fix. In another of its studies, the optimistic bias disappeared for participants who were told to connect relevant past experiences to their prediction. This approach is often called the outside view: start from how long similar work took before, then adjust for what is different this time.

Where to find past data

If you have never tracked how long work takes, you can still find a baseline:

• Your calendar and email. The dates of the kickoff and the final delivery on your last similar project give its real length.
• Old boards and task lists. Compare when the first and last tasks of a past project were created and completed.
• The people who did it. Ask how long the last one took, not how long the next one should take.
• Reports on your board. In KanbanWP, the Reports screen shows how many tasks sit in each stage, and a 30-day cumulative flow chart shows how those counts changed, so you can see where planned work piles up.

Start from these numbers rather than from your first guess, and adjust only for differences you can name.

The eight project planning steps

These steps give you step-by-step project planning for a small team project of a few weeks. For a larger project, each step becomes longer, but the order stays the same.

1. Define the outcome and success criteria

Write the outcome in one sentence. Then write two or three checks that will tell you the outcome is reached. “Launch the new pricing page” is an outcome. “The page is live, the checkout links work, and the old page redirects” are the checks.

2. Set the scope

List what is in the project and, just as important, what is out. An “out of scope” list is the simplest guard against scope creep. When someone asks for more, compare the request with the list and decide whether to add time or move the request to a later project.

3. Name the owner and the stakeholders

Name one person who owns the plan. List everyone who must approve the work, supply something, or be told about progress. For a client project, that list includes the client contact who signs off.

4. Break the work into tasks

Split the outcome into deliverables, then into tasks that one person can finish. Each task needs an owner and a clear result. Our task breakdown guide covers this step with a worked example.

5. Estimate from past data

Estimate each task, then check the total against similar past work. If the last three projects of this kind took six weeks, a four-week estimate needs a reason. Add a buffer for the risks you will list in step 7.

6. Order the tasks and set dates

Mark which tasks depend on others, and which can run in parallel. Set due dates that follow that order, and set a few milestones where you will check progress, such as “draft ready for review.”

7. List the risks

Ask what could block each deliverable: a late approval, a missing file, a person on leave, a tool that does not work as expected. For each serious risk, add a task, a check, or a fallback. A premortem, where the team imagines the project has failed and explains why, is a quick way to find them.

8. Agree how you will review progress

Decide when the team will look at the plan, who will attend, and what counts as a reason to change it. A weekly fifteen-minute review is enough for most small projects.

Project planning checklist

Copy this list into the first card of a new project and tick each item before work starts:

• The outcome is written in one sentence.
• Two or three success checks are written.
• The out-of-scope list is written.
• One owner is named, and the stakeholders are listed.
• Every task has an owner and a clear result.
• The total estimate is compared with similar past work.
• Dependencies and due dates are set.
• The main risks each have a task, a check or a fallback.
• The review schedule is agreed.

Protect time to plan first

Planning is easy to skip because it produces nothing you can show, and the first task often looks small enough to start right away. Three habits help you keep time for planning:

• Put planning on the calendar. Book the planning session as a meeting with a start and end time, before the first work session.
• Plan in proportion. A one-day task needs about ten minutes of planning, and a month-long project may need half a day. Planning can expand to fill the day, so set a time limit and stop when it ends.
• Make planning a condition of starting. Agree as a team that no task moves into the working stage until its description has an outcome and its checklist has the steps.

For tasks you can finish in a few minutes, skip the planning and do the work.

A worked example on a board

Suppose your team wants to add a “related posts” section to a WordPress blog. On a KanbanWP board, the plan fits in one card:

• Description. Outcome: each post shows three related posts at the end. Out of scope: redesigning the post footer.
• Checklist. The success checks: the section shows on desktop and mobile, posts with no related content show nothing, and page speed does not drop.
• Subtasks. Choose how posts are matched, design the layout, build it, test it on ten posts, publish. Each subtask has its own owner and due date.
• Blocked by. The tagging cleanup card, because related posts depend on tags and half the posts have none.

That last item came from the risk step. Without it, the team would find the untagged posts after building the feature.

In KanbanWP, the checklist shows its progress on the card, and the card also shows how many subtasks and blockers it has. You can set start and due dates on each task, and the calendar and timeline views show the dates across the board. The working-stage rule above is a team agreement, so KanbanWP does not enforce it. Our article on what isn’t on the board covers how to agree on rules like this one.