Project Planning for Small Teams: Goal, Milestones, Owners

Why do projects in small companies almost always take longer than planned?

In a company with ten or thirty employees, there is rarely a project team that works only on the project. The new website, the workshop move, or the introduction of a CRM runs alongside quotes, complaints, and vacation cover. The deadline is set at the kickoff with a good feeling. Three months later it has been pushed back, and nobody can say exactly since when.

The usual response is a more detailed plan next time. That helps surprisingly little. Research shows that the cause runs deeper than a lack of care. This leads to the guiding question of this article: How does a small team plan a project so that goal, deadline, and responsibilities still hold after the kickoff?

To answer it, we first clarify the three building blocks of a plan and the thinking model of the planning fallacy. Then we look at the findings on remedies, followed by a one-page plan with a worked example. At the end there is an answer to the guiding question and a step for this week.

A project rarely fails for lack of a plan, but because of a plan that describes only the best case.

What belongs in a project plan for a small team?

A project is a one-time undertaking with a fixed result, a beginning, and an end. That distinguishes it from a process, which repeats. For a small team, three building blocks are enough to plan a project.

A milestone is a verifiable interim result, not an activity. “Write copy” is an activity. “All home page copy is approved” is a milestone. You know the distinction from weekly team planning: on the due date, it must be possible to say yes or no as to whether it has been reached.

Exactly one person is the owner, even if several people contribute. If you want to clarify in larger projects who co-decides and who is only informed, you will find the tool for that in the article on how to clarify responsibilities with the RACI matrix.

The planning fallacy: why we underestimate how long our own projects take

The thinking model behind the problem is called the planning fallacy. The term was coined by Kahneman and Tversky (1979). It describes an optimistic bias: people underestimate the time an upcoming undertaking will take, even though they know that similar undertakings took longer in the past.

Wiese, Buehler, and Griffin (2016) summarize in their review where the bias comes from. When people estimate a duration, they mentally run through a sequence from start to finish. This script is simplified and geared toward success. It contains the central steps but hardly any interruptions, waiting times, or competing tasks.

An important distinction the authors highlight is between working time on a task and the completion date. People often estimate pure working time reasonably well. They miss the completion date because it depends on everything that happens between the work steps. For a small company, this is the real point. The website may need 40 hours of work. Yet it is finished only after twelve weeks, because those 40 hours are spread across daily business, vacations, and questions to the client.

Plan in more detail or plan differently? What research shows

There are two readings of how to counter the planning fallacy. The first: plan in more detail. Whoever breaks a project down into many small tasks overlooks fewer steps. The second: plan differently. It is not the granularity of the plan that matters but the direction from which it is built.

For the first reading, the findings are mixed. Wiese, Buehler, and Griffin (2016) report that breaking a task into subtasks reduced the bias in some studies but not in others. It works less well when an undertaking has only a few parts or lies far in the future. In some studies, a particularly detailed plan even increased confidence, because it creates the illusion of a complete overview.

Three approaches support the second reading. In four experiments by Wiese, Buehler, and Griffin (2016), participants planned either from start to finish, from the goal back to the start, or without instructions. Those who planned backward consistently predicted longer times, and in the fourth study these predictions were measurably less biased. The backward planners paid more attention to obstacles, interruptions, and competing tasks. Buehler, Griffin, Lam, and Deslauriers (2012) found in four studies that people estimate more realistically when they imagine a task from an observer’s perspective rather than their own. And Koole and Van’t Spijker (2000) showed that concrete commitments about when and where to work did not make predictions more cautious, but sped up actual completion so much that the bias shrank. The reason was fewer interruptions.

What planning actually looks like in small companies is shown by a survey of 30 small and medium-sized enterprises in North Macedonia about their software projects (Tasevska, Damij, and Damij 2014). The companies usually clarified the business case, the scope, and a baseline plan. They planned for risks least often, and they hardly used tools such as bar charts. The study is small and limited to one country and one type of project. Still, the pattern fits the finding from psychology: people plan the path to success, but hardly what gets in the way.

I consider the second reading the more robust one. A finer plan answers the question of what needs to be done. The delay, however, arises from the question of what gets in the way. A backward plan asks that question by itself.

How do you plan a project backward on one page?

1. Define the goal in one sentence

   Phrase the result so that an outsider can verify it. “The new website is live, and all forms arrive in the CRM.”

2. Work back from the goal to the milestones

   Ask from the end date: what must be finished beforehand for this result to be possible? And before that? This produces three to seven milestones.

3. Give each milestone a name

   One person per milestone who makes sure it is reached. They do not have to do everything themselves.

4. Note obstacles for each milestone

   One line per milestone: what typically holds us up here? Vacations, client approvals, delivery times, peak season.

5. Add the outside view

   Compare the estimate with your last three similar projects. How far did they exceed the plan? Use that markup as a buffer.

6. Set a weekly check

   Five minutes in the weekly meeting: which milestone is due next, is it on track, and what is in the way?

The fifth step is the one most people skip. It corresponds to what the literature describes as forecasting with a reference class: instead of estimating from the plan, you look at the distribution of comparable past undertakings (Wiese, Buehler, and Griffin 2016, referring to Flyvbjerg 2008). The authors point out that this only works where comparable projects exist. A small company often has more of them than it thinks: the last trade show, the last move, the last software switch.

Worked example: how much buffer does your project need?

A company with 18 employees is planning to overhaul its quote templates. The team estimates eight weeks. Before committing to the date, the owner looks at four earlier internal projects and compares planned and actual duration. The figures are a worked example.

With this view, the owner commits to eleven weeks rather than eight. She does not spread the buffer evenly but places it before the milestones that involve others: the approval by the tax advisor and the coordination with the print service provider. That is where waiting times are longest and least under her own control.

The markup is not a weakness of the plan. It is an honest description of how projects have gone in this company so far. Leaving it out only postpones the disappointment.

How does the plan stay alive after the kickoff?

A plan nobody looks at anymore is a historical document after three weeks. In small teams, a few rules are enough to keep it part of daily work.

• The plan lives in the place the team uses every day, not in an email attachment.
• Only the next milestone due is discussed in the weekly meeting.
• If a milestone is postponed, the owner changes the date personally and states the reason in one sentence.
• After two postponements of the same milestone, the owner of the business decides whether goal, scope, or deadline will be adjusted.
• At the end, the actual duration is written next to the planned one, as a reference for the next project.

The last rule closes the loop to the outside view. Every completed project delivers another figure for the reference class. How to take away more than a number from a project close is described in the article on project close-out and lessons learned. And how to keep budget, time, and scope in view on an ongoing basis is shown in the article on project controlling for small businesses.

For the question of whether a project should be run in fixed phases or short cycles, the comparison in the article agile or traditional is worth reading. The one-page plan fits both, because it only defines the goal, the interim results, and the names.

Conclusion: what makes a project plan in small teams hold up

We began by asking
a small team plans so that goal, deadline, and responsibilities hold after the kickoff. The answer has two parts. The content of a good plan is simple: a verifiable goal, a few milestones as results, one name per milestone. The quality of the plan, however, depends on the way it is created.

As shown, people underestimate how long their own projects take because they run through the best sequence. An ever finer plan does not reliably fix that. Planning backward, naming obstacles for each milestone, and using your own past projects as a comparison, on the other hand, address exactly this cause. The studies on this come mostly from experiments rather than companies, but they point in the same direction. This leads to a sober observation: a realistic deadline is not a sign of pessimism but the result of a plan that also knows what lies in between.

First steps for this week

1. Take your next upcoming project and write down the goal in one verifiable sentence.
2. Plan back from the end date and set three to seven milestones with dates.
3. Write exactly one name and one line on typical obstacles next to each milestone.
4. Look up two to four earlier projects and calculate how far they exceeded the plan. Use that markup as a buffer.
5. Add the next milestone due as a fixed item to your weekly meeting.

For a medium-sized project, this takes about an hour. At the end you have one page that clarifies goal, deadline, and responsibilities, and a deadline you can commit to with a clear conscience.