Planning work: top-down or bottom-up?

Let’s say you’re working on a project, and you want to get an idea of all the tasks you need to complete in order to deliver the project so you can tell how long the project is going to take or whether it can be done by the deadline. How should you approach doing that?

Generally speaking, there are two ways; top-down planning or bottom-up planning.

Top-down planning

Example

We want to build a castle out of Lego. In order to do that we’ll need a design for the castle, get the Lego blocks to build it, find a space to work in, and get people to do the building. So, now we’ve broken the goal out into four different groups of work that will allow us to achieve it.

Next we’re going to break each of those down. The task of ‘designing the castle’ could be broken down into ‘design the turrets’, ‘design the drawbridge’, ‘design the courtyard’, etc., until we have a complete list of all of the parts of the castle that need to be designed. For the task of ‘get the bricks’, we could break it down into ‘get red bricks’, ‘get blue bricks’, etc. And we’d do the same for the other two groups of tasks.

Each of those tasks can then be broken down further, so ‘get red bricks’ is broken out into ‘get list of red bricks from designer’, ‘send list of red bricks to supplier’, and ‘count delivery of red bricks to check they are all there’.

Approach

Start with the biggest single thing you know about the project, which is usually it’s goal. What does the project need to deliver and by when (assuming it has a deadline)?

Then divide the goal into groupings of tasks. These groupings can be tasks themselves, e.g., ‘Design the castle’, ‘Build the castle’, or they can align with project teams, e.g., Designer, Builders, Estates, and HR., or they can be aligned with phases of the project lifecycle. The important part at this stage is to try to make the groupings large enough to encompass everything that is part of the project.

Then divide the larger tasks into smaller tasks, and those into even smaller tasks. Judging the level of fidelity to go to will depend on the complexity of the project but it should be to enable other project management tasks to be completed such as estimating time, understanding which tasks can be completed in parallel or in sequence, where people are needed, etc.

Reasoning

Top-down planning uses deductive reasoning. Deduction starts with the general and reduces it to the specific. The logic of deductive reasoning is “If A equals B, and B equals C, then A must equal C”. But it starts with an ‘if’. C only equals A if A really does equal B. If the first statement isn’t true then although the reasoning can be accurate the result can be completely wrong. Knowing what reasoning you are applying in planning is important for ensuring that the planning process is valid and reliable. If, part way through the deductive reasoning process of breaking down the general to the specific

Benefits

Deductive reasoning and top-down planning can work well when the goal or end state is well-known and clearly defined. If you are sure you want to build a castle then top-down planning can work well.

Can help to identify whether a project can be delivered by a deadline and understanding whether all of the tasks can be completed within the time frame.

Can be down to any degree of fidelity, with as many breakdowns as are required to understand the work of the project.

Disbenefits

Top-down planning relies on the initial assumptions being correct. The more assumptions that turn out not to be true as the project progresses, the more the plan deviates from reality and harder it is to know whether the project will be delivered on time.

Replanning, when something changes in the project, for example you get more builders or you realise you forgot to design the moat, is likely to affect the tasks in other groupings.

This approach relies on dividing the tasks but doesn’t provide any guidance on how to create the divisions or whether any divisions were missed.

It’s harder to see dependencies in other groups of tasks, and so unknown blockers can be created.

The more levels of task breakdown that are included in the plan, the more time and effort is required to create the plan.

Bottom-up planning

Example

We have lots of Lego but we don’t know what to build with it. So we start with the task, ‘Decide what to build’, and that makes us think that we need to know who we’re building for, so we add the tasks ‘Define target audience’ and ‘Survey target audience’. And these, along with the other related tasks we can think of, are grouped together.

Then we move on and think of the task ‘Organise the bricks’, which might go into the same grouping as the task, ‘Decide where to build’, either because its the same team working on it or we want to do the work for those tasks at the same time.

And once we have all the tasks grouped we can form an idea of the outcome of the project from bringing those groups together to see that we’ll be building a Lego spaceship.

Approach

Start with small tasks and group the similar or connected ones together. When a pattern emerges, then group those groups together. As other tasks are thought of they can either be added to an existing grouping or start a new one.

The project plan is complete when all the known tasks have been added, grouped, and together those groups become the project goal or output.

Reasoning

Bottom-up planning uses inductive reasoning which starts with the specific and makes broad generalisations based on the patterns that emerge from those specific observations.

The usually example is taking coins out of a purse. If all of the coins you’ve taken out have been ten pence pieces, then even though you haven’t taken all of the coins out of the purse you can reach the conclusion that all of the remaining coins in the purse are ten pence pieces.

This type of reasoning in planning is useful because it gives you a degree of control over when you recognise a pattern (after three coins or after 75% of coins) and the validity of your conclusion (once you’ve taken all of the coins out of the purse).

Benefits

The bottom-up approach to planning works well when the goal or end-state isn’t know and needs to emerge from the planning process.

It allows new tasks to be added and grouped appropriately, either in existing or new groups.

Disbenefits

This approach can make the project look unstructured as new groupings of tasks can emerge late into the project when they are thought of.

It doesn’t reveal the goal or end-state of the project until the planning is complete.

Inductive reasoning assumes that it’s conclusions, or in our case the groupings of tasks that make up the project plan, are correct, even if your validity is low. So, a project plan reached through inductive reasoning that was done without the input of your Lego designers wouldn’t recognise that you had a gap in the plan because there were no design tasks added in order to be grouped.

Is there another way?

Yes, we can use abductive reasoning. Abductive reasoning takes observations and evidence and uses them to reach the most likely explanation, or in the case of our Lego example says, based on the Lego blocks that we have and the skills of our builders it looks like we might be able to build a Lego car. Project planners aren’t usually very happy with ‘might be able to’ so you can see why this type of reasoning and approach to planning isn’t used very much. However, for situations where certainty about the outcome isn’t required an abductive approach can result in a more realistic plan as it is based on evidence rather than inference as with deductive and inductive reasoning.

What can go wrong?

Using an approach, either top-down or bottom-up, requires the right use of reasoning to go with it. If use a top-down planning method, but switch between deductive and inductive reasoning (probably without realising it) then our project plans can become very confused.

• Category: Blog