If you want to eat an elephant you have to slice it up!

How to define the tasks of a project in a simple way

Reading Time: 4 minutes

Don’t worry … no animals were killed in the writing of this article. Also because I love animals.

It’s just a way of saying to explain that when you have to deal with a complex problem you need to break it down into sub problems.

After my previous article I received many requests for advice on how to determine the tasks of a project.

There are many techniques. In this short article I will explain a very simple yet functional way to accomplish this task.

PROBLEM

I need to organize and manage a project. I know what I need and I know the goal to be achieved. I also know the exact timeframe for completion. I want to use the Gantt diagram to manage it. Which and how many tasks should I define for the diagram and therefore for the project?

SOLUTION

A project of any size, complexity, or scope can be considered as a set of sub-projects. In turn, these sub projects, can be considered as a set of other sub projects. This reasoning can be repeated until you get to small projects. Sometimes it may be useful to arrive at atomic elements, i.e., elements so small that they cannot be broken down into subproblems.

FUNCTIONAL DECOMPOSITION

This that I have described takes the name of “Functional Decomposition” that is the decomposition of projects (or parts of it) in the activities and processes that compose it.

If we want to use a more precise terminology we can say that, what we have explained above, takes the name of Work Breakdown Structure abbreviated as WBS.

Every time we decompose a project into sub-elements we create a new level.

But then the question arises: How many layers should I define?

There is no defined number of layers. It’s up to those who organize and manage to understand what level of detail is needed.

Personally, based on my experience, I can say that it depends a lot on the type of project and its complexity, but generally it is not advisable to go too low. A good starting point could be 3, 4 or 5 levels, but this does not exclude the possibility of reaching 20 or 30 levels.

It is also necessary to evaluate, in case you reach too many levels, if it is the case to merge the sub elements and understand if you are exaggerating with the decomposition.

All this is determined by experience. It is quite natural that the first times we tend to detail too much and then to break down too many levels.

What we are going to create is a hierarchical structure where we start from the main element and as we go down in level we subdivide the trunk into main branches which in turn will be divided into other branches and so on.

To make the idea better we can imagine a kind of tree but imagining it upside down where the branches are at the bottom and the trunk at the top. We could also imagine the trunk and its roots. The concept is the same.

In figure 1 you can find an example of a multi-level hierarchical structure

The direction of analysis and decomposition is from top to bottom, that is, from the highest level of abstraction of the project to the lowest level of detail.

What we have just seen is called Top-Down Analysis and indicates the direction of the project decomposition in sub-levels which is from the top down to the bottom.

It is appropriate to mention the existence of the diametrically opposed approach called Bottom-Up. As it is easy to guess from the name, the management is carried out in the opposite way of what we have just seen, that is, it starts from the bottom and goes upwards. This methodology is surely much less used than the Top-Down. I myself have used it very rarely but I can assure you that there are situations in which it is preferable. We’ll stop here for the moment.

Now you have a simple method to create the list of your project tasks and to be able to go and create your Gantt chart.

CONCLUSION

During the preliminary analysis phase of the project, it is never convenient to go down in level too much and then get to a very other level of detail with a complex WBS structure. It is instead important to get to a very detailed level of WBS structure during the planning phase of the project so as to be able to control every single detail.

Again, we have approached this in a very simple way. My goal is always the same. To bring the use of a project management methodology to a wide audience and, above all, to those who are not project managers by trade but still have to manage both work and personal projects.

Enjoy Project Management 🙂