Project planning with Gantt charts 2.0

Do you know that feeling? As a project manager, you have just adjusted the Gantt chart of the project again and the next milestone seems to be realistically achievable through clever balancing. However, your subconscious says that you are probably already lagging behind. Something will once again not be done and the project plan that has been carefully drawn up has to be adapted once again. Wouldn't it be much more pleasant to work if we were a little ahead of the project? This cannot be achieved directly in our highly dense, complex world. This article shows an indirect but valid approach.

To get to the heart of the matter, let's go back in time. To the time of Henry Gantt, who lends his name to the chart mentioned above. Gantt developed his modeling at a time when industrialization was advancing, and steam engines were the "latest hype". To get a more concrete idea, let's take the example of an engineer from this period who was given the task of designing part of a steam locomotive. The engineer had two draftsmen at his side. The work is meant to start on Monday and the handover was on Friday. The planning documents for the component should then be handed over to the in-house foundry for production. The bar in the Gantt chart is therefore 5 days long and 3 resources are assigned full-time for this duration.

Let us assume that the engineer notices a serious problem on Monday lunchtime. Without the solution, planning cannot be completed, and production cannot begin. The engineer thinks about the solution for 4 hours on Monday afternoon and exchanges ideas with colleagues and his draftsmen. He finds the solution late on Monday afternoon. This creates additional work, which the two draftsmen make up for by working half an hour longer each of the following days. The task is finished on time, everything is fine.

What does this story look like when carried over to our present day? Presumably, the two technical draftsmen will be omitted, because the engineer will draw the draft himself with the appropriate construction software. The component is made of plastic and the planning documents go to China, where the component is manufactured in thousands. The engineer doesn't even start work until Friday. He has a window of half a day. He may have another meeting on Friday morning and there are still a lot of unanswered emails in the inbox. After an hour of work, the engineer then discovers a problem, and finding the solution takes 4 hours (...) At this point the story can be wrapped up because it is clear how it will continue.

This story is certainly exaggerated. But would you disagree with the principle? To get to the core of the problem, let's look at the numbers. A problem arises from the time of the steam engines, the solution of which costs the engineer 4 hours, which corresponds to 10% unexpected additional work in the project in relation to the total project time. For today's engineer, 4 hours more work means a doubling of the planned time, i.e. 100% unexpected additional work. This can no longer be easily cushioned.

In the new reality, the implementation time has decreased significantly due to the high degree of automation (construction software) compared to the steam engine age. Conversely, this means that today's expectation of the implementation time is correspondingly high. The solution to the problem, the intellectual, the creative solution remains unchanged. Back then, it took 4 hours of intensive thought and today the same amount of time is still needed. In our technically and organizationally highly networked world, it may take longer to find a solution. But solving the problem itself has a much greater impact on the overall duration than it did a hundred years ago.

Water in its gaseous state can certainly not be described as out of date and the methods from the time of the steam engines have partly retained their importance, but only partly.

Interestingly, we believe that we can still work with the methods from the steam engine era to a certain extent. It's so simple and straightforward.

Throwing the computer out the window is not the solution. In the past, everything was by no means better. The frequent longing for the past certainly has other (perhaps related) reasons. No company is alone in our globalized world, there is always competition. Automation and digitization will continue to advance and the methods in project management will experience further changes.

One approach is to transfer more responsibility to the team members so that they can organize themselves to a certain degree.

For this purpose, the bars in the Gantt chart are seen as a framework in which the team members organize their work independently or in small teams. The design is the crucial point, because whoever is given responsibility must also take it on. Team members plan their work themselves within the given framework, organize themselves and keep track of work progress.

To do this, each team member divides their work packages into tasks. At the same time, the employee assigns their tasks estimated or planned effort hours. For example, task 1 takes 1 hour, task 2 takes 15 minutes and task 3 takes half a day. So, step by step, as the individual tasks are completed, the degree of completion of the work package can be tracked by the employee himself and the project manager - without additional effort. With an integrated project management software, the overall progress of the project can be monitored and controlled centrally and in a consolidated manner.

This way, a hybrid approach can be mapped that combines the established way of thinking in bar charts with agile methods.

Octaved Flow offers exactly these possibilities. Both project management and the (more autonomously working) team members have access to the same information and tasks in real time. The prerequisite for the decentralization of responsibilities is that in the end the threads come together again.