The Final Word in the Gantt Chart Polemic

Do you know what Abraham Lincoln used to say about planning? “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” Planning is and will always be vital to reach desired outcomes on time and on value. That’s why one hundred years ago, Henry Gantt was so passionate about helping people plan and better distribute their resources. He invented a bar chart to illustrate project schedules as clearly as possible. Only, Gantt’s was a chart to meet the project management needs of the twentieth century. It helped managers run one project at a time with fewer resource constraints. Although Gantt charts are 100 years old, they haven’t lost their popularity. But times have changed – today, we run projects in parallel more than ever and resources are scarce.

The Gantt Chart Controversy

Many project experts (you may be one of them) place great hope in their solutions based on Gantt models, while others consider them infeasible on their own. The question is whether this traditional project management tool can meet the expectations of project managers who have to pilot many projects at the same time. To see how the land lies, the Epicflow team has carried out a mini-investigation into the Gantt controversy. In this article, you’ll encounter the opinions of many project experts to help figure out whether Gantt tools are worth your attention.

In what cases can we use Gantt charts to achieve more or less effective results? Roman Baranovsky, a delivery manager at Microsoft and an expert with 18 plus years of experience leading projects and project-based organizations, remarks that the outcome of using a Gantt chart depends on what you expect of it. Baranovsky believes that the Gantt chart is a far cry from being universal and suitable for all cases. “This is just a tool, a type of diagram, so it might be very useful for some purposes and really bad for others,” Baranovsky specifies. To illustrate the point, he offers two scenarios:

1) If you want to show a senior stakeholder how a few projects in your portfolio are positioned on the timeline, then a Gantt chart might be a reasonable choice as they’re easy to understand.

2) If instead you want to discuss specific resource allocation or, say, dependencies, then a Gantt chart will be useless. You might be able to modify it for some simple cases (as MS Project did, adding resources, dependencies, percent completed, etc.), but otherwise you’ll have to come up with some other way to visualize or explain the problem.

Because of the scarcity of resources, our needs are often far more complicated. At times, we need to allocate a team member from one project to another, creating project interdependencies that project managers aren’t aware of. We need functionality, analytics, and intelligence to track our resources and see where they are in the plan so we can be confident in multi-project environments. Can Gantt charts cope with this?

Gantt Charts Can Be Elusive

Yuri Warczynski, a member of the Epicflow advisory board with nearly 20 years of experience in project management, expresses his concerns about working with Gantt charts in multi-project environments. Warczynski says that it’s normal to set up a network with dependencies in order to minimize the number of changes you have to make during execution when things shift due to slower-than-planned progress. But it’s not very convenient to do this in Gantt view. Network view is more suitable.

The resulting Gantt view will be a possible scenario of which work to do when. But it almost never goes according to this scenario. Here one may question the value of seeing a scenario which most certainly will not meet the baseline. Afterwards, during execution, some tasks will be to the left of the “today” line due to variability in execution. They should have started, but didn’t. You then have to move these tasks to the right one by one in order to create yet another improbable scenario. On large project plans you need 30 plus planners just to do this.

Warczynski highlights three reasonable points of departure from Gantt charts to modern solutions:

1) There’s limited value in seeing the execution dates on a Gantt chart since they’ll be different in reality. The feeling of certainty you get from a Gantt chart is an illusion.
2) It’s more convenient to see and make dependencies in a network view.
3) In software based on the Gantt chart, it requires too much effort to move tasks to the right that should have started but didn’t.

Andrew Utsogn, a project manager with Nokia and Microsoft for 18 years, admits that the main pain of Gantt charts is maintenance. According to Utsogn, multiple dependent projects will sooner or later be affected by schedule changes, having cascading effects across several of them.

Gantt charts are supposed to work effectively once you’ve established clear dependencies. When something changes, proper updates should follow. But nothing is ever that simple. Something will be missed, not all dependencies are even known when you set that first baseline. So what ends up happening is updates in each plan as you discover the hidden gaps in your plan. This isn’t bad planning necessarily, you’re always going to miss a detail or the project scope will change as business experts realize what they want vs. what they get vs. the business environment. A Gantt chart is merely a visual representation of the data behind it; i.e. the project plan details. And these are subject to change based on business conditions and project assumptions. So the Gantt chart isn’t inherently wrong, it just shouldn’t be taken so seriously until all of the risks and issues have been considered.

Does this mean that a Gantt chart is an unreliable option for solving complex multi-project situations? Let’s investigate what other experts have to add.

The Devil Is in the Details

The philosophy behind Gantt planning is to predict every possible detail that may stand in the way – which turns out to be a challenge. Albert Ponsteen, one of the scientists behind Epicflow, confirms that project management tools with Gantt charts at their core try to create a model of reality by incorporating all kinds of variables. They’re part of the deterministic approach to project management. In a deterministic world, you want to fight against uncertainty. But the desire to fight is not necessarily bad. The question is how realistic it is and how much effort it takes to adapt the Gantt chart to account for all these details. Ponsteen’s advice is to only incorporate items in a plan that are less vulnerable to uncertainty and that you’re willing to battle for as a manager, such as:

1) Time, by focusing on important milestones;
2) Scope and quality, by converting your process and the scope into a network diagram;
3) Budget, by focusing on hours spent, hours remaining, and buffer remaining.

Simon Kiteley, who works at BAE Systems, is also of the opinion that Gantt charts aren’t effective when it comes to presenting accurate project details. “When creating Gantt charts you are trying to graphically represent something very complicated by something quite simple,” Kiteley says. “So you are either representing the project at quite a high level and missing the details or putting in a huge amount of detail on things that will probably change or move.” According to Kiteley, the problem really comes when Gantt charts are treated as accurate rather than as a useful visualization of project development.

If done at a high level using things like “velocity” of development to learn from the first stages how later ones will need to be adjusted. Realize if you put too much detail in that, it can’t possibly be followed and as such you are probably wasting time, it’s a vanity activity.

It appears that multi-project dependencies are difficult to handle using Gantt tools. The experts cited below relate this to the problem of coordinating resources and connecting schedules.

Resource Coordination Troubles

Dennis Copeland, a project manager for many high-profile projects as a contractor in the public sector, states that it’s not really Gantt charts themselves that are problematic but the underlying data that feeds Gantt charts. According to Copeland, the most difficult thing is an environment where resources are shared:

If project A is either dependent on people that are working on project B, for example how you factor that in as you provide the data for the Gantt charts becomes a most vexing project planning and monitoring problem.

Jeff Franz-Lien, a project management veteran, is also convinced that coordination of resources between projects is the biggest pain of Gantt Charts in multi-project environments.

I’ve been in lots of situations where project managers were sharing resources but their Gantt charts were completely separate and standalone. So without a great deal of manual communication, it was common for project managers to accidentally over-allocate resources (e.g. conflict for particular tasks or overall), book resources for more time than required so other projects can’t get them (eliminates #1 but wasteful).

Franz-Lien suggests considering portfolio/multi-project software to greatly help with coordinating resources between projects. He insists that’s because the scheduling engine balances resource use among projects, which is reflected in reports.

Ian Jones, a resource and project management consultant with 25 years of experience, agrees that sharing and balancing resources across project plans is a challenge with Gantt charts.

Сonsidering MS Project as an example, each project plan has its own pool of resources. Unless you use something like Project Server (which complicates things massively) the resources (and utilization reporting) are managed independently in each plan. This means that it is very easy to plan the same resources for the same period in more than one plan. Which means over-allocation. What you need in a multi-project environment is a scheduling tool that has a central pool of resources that are shared across plans. You can then share a resource across the project with no fear of over-allocating people.

Lost Connections between Schedules

Geoff Reiss, a program management expert who has spent almost his whole life designing PM software, training project managers, and writing about PM challenges, focuses on the importance of connected schedules in multi-project environments. He believes that it’s important to have a schedule for each project – and that schedule must be owned by the individual project team and their manager or scheduler. Reiss says that to do a great job of managing schedules across multiple projects, you need some way of connecting individual project schedules. It’s likely that there will be interactions across projects – for example, milestones and resources that appear in more than one project. An overall cash restraint is common. Therefore, there needs to be someone or something with a multi-project view. This is one role of a program manager or intelligent project planning software that can track workloads, predict bottlenecks, and connect schedules without the burden of overload.

What’s the Future of Gantt Charts?

Our experts Albert Ponsteen and Jan Willem Tromp lit upon a new way of approaching the problem with Gantt charts. To alleviate the pains of using Gantt charts in multi-project environments, you can add value to your existing PM system and start to better coordinate resources based on capacity, connect schedules based on demand, and set priorities.

Have you noticed that your Gantt charts no longer have the power to help you handle complex situations? Sign up below for an Epicflow demonstration and start managing in harmony.