S02-E02 What if I cut my project...

In the previous article, we saw what a project plan was and the elements to start building it. We ended with the following question:

When did I reach the right granularity? How can I manage a project over several years?

It is to these questions that we will try to answer in this article.

The classic answers are:

• When a project task represents between 3 and 10% of the project duration, you are at the right level of granularity,
• A project with more than 150 tasks can be divided.

Generally speaking, both of these statements are good and relevant. However, let's try to specify concretely how to proceed.

1/ When a project task represents between 3 and 10% of the project duration, you are at the right level of granularity.

In our experience, we have seen that this first element allows us to identify anomalies in the project. However, there is no question of having a binary view on the treatment of this range.

We encourage you to identify the tasks around these "anomalies" to see if a grouping is possible. In fact, if you go into too much detail in your project plan, you often end up with a series of tasks lasting x days for the same resource. Thus, it could be judicious to group these tasks, carried out by the same functions, into a single task, while reclarifying the input data and deliverables.

Concerning the frequency of monitoring your schedule; what are the benefits of detailing two-day tasks (or even half-day tasks, yes, I swear) when the schedule is updated every week… and the project lasts 2 years?

By applying the 3-10% "rule", you will be able to simplify your project in a controlled manner while making it easily manageable (granularity).

2/ A project with more than 150 tasks can be split up.

Here is an example of what we try to avoid in terms of project plan visibility:

No need to specify that the management of this project will be somewhat complicated and may frustrate quite a few people… (especially the one who will update the links  ). Yet the project lasts several years and this complexity is real!

The classic way is to try to split the project into sub-projects, within a limit of 150 tasks. Here are some additional tips to help you with this breakdown:

• Try to identify in your project plan, where your tasks converge or diverge. Generally, this is a good place to make some project cuts

• Try to identify the real milestones of the project. Indeed, our customers often claim to have many milestones (i.e. a milestone that has not been passed will indicate that any task of this project will be stopped until this milestone is validated). In reality, with this definition, there are fewer milestones than one would imagine. Maybe some (not all) of the milestones can be broken down to make the project clearer.

For example;

VoYou have a CAPEX project that will go through a budgeting/requirements phase/search and validation of the supplier. Then a procurement phase with the selected supplier, and finally the installation on site. Wanting to detail the plan too far upstream limits your flexibility when you move to execution. You may want to have one project that goes all the way through to placing orders with suppliers. Then another project that includes both procurement and installation.

Keep in mind that no matter how detailed you get, you will never have a project plan that is 100% right. Therefore, applying these principles is a way to simplify your life while accepting a certain level of uncertainty.

So the next question is:

If I have a project plan that is not perfect and will experience uncertainty when my project is complete, how do I incorporate these new elements into my future project plan?

More in episode 3…