I have never found Gantt charts to be useful. When I say that to my clients, some of them tell me they do find use in Gantt charts. Specifically, the people who like Gantt charts say they can predict where the project is headed. In addition, they can see the various interdependencies across the work. They say they know—from the Gantt and without a doubt—when the project will finish.
All my experiences negate theirs. In fact, I find that Gantt charts tend to obfuscate the reality of the project. In innovative products, the interdependencies can change any day. As for the date? The Gantt chart shows us the first date we cannot prove we cannot finish. (I wrote about this problem as a schedule game, “The Schedule Tool is Always Right.” There's more in Manage It! Your Guide to Modern, Pragmatic Project Management.)
How is it possible these people have such different experiences than I do?
I suspect their teams hide their feedback loops.
- If your product does not need much innovation, you can plan for longer and know you will meet that plan. Those are the kinds of products that do not require much, if any, innovation.
- When people create a high-level WBS, no one sees the feedback loops or the dependencies. The feedback loops tend to be late and create chaos in the project.
- The more people estimate from the bottom up, the more they pad their estimates to account for unknowns. That's another great way to hide feedback loops.
If you can use a Gantt chart and you find it valuable, that's fine. However, I find late feedback loops deadly to forward progress. (That's why I wrote Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility.)
I also like to know where the project is headed, the interdependencies, and the possible completion date. Here's how I find that data to see the project's current progress and a little into the future.
See the Project's Progress and a Little About the Future
Yogi Berra said:
“It's tough to make predictions, especially about the future.”
I agree. So instead of trying make forward-based predictions, as people typically do with Gantt charts, I use cycle time as evidence-based prediction. (See Predicting the Unpredictable for more details.) In addition, I ask teams to show visual progress, such as in a demo.
What if you have no visual progress yet? Ask yourself this question:
What is the most valuable thing we can learn and how fast can we learn that?
So many project plans, such as Gantts, try to envision everything, all the details. But, unless you have a totally deterministic project, your project will need to learn something. Instead, the question about the most valuable thing often prompts the team to create deliverables, not tasks. Deliverable-based planning feels different than task-based planning, because everyone optimizes up for the deliverable.
Some teams might need a candidate architecture so the team has a way to think about the product. But in my experience, architectures change, regardless of the need for innovation. I want architecture feedback loops as early as possible in the project, which is why I want visual progress with demos.
Our ability to make progress also exposes various dependencies and interdependencies.
See Dependencies
Tools or Gantt Charts rarely (if ever) show you the real dependencies. Instead, consider value stream maps and measuring cycle time to see where you might start. See this series about how to see dependencies with value stream maps in various kinds of teams, starting with A Common Tool Trap: the Tool Will Help Your Delivery and Planning Problems. My February 2024 Pragmatic Manager newsletter discussed issues with component teams. See Three Tips to Focus to Deliver Better Products Faster.
But, the one thing the dependencies cannot show you is a completion date.
See Your Possible Completion Date
Gantt charts show you the first possible date you cannot prove you can't finish. Let me turn that around and say the Gantt chart shows you the most optimistic date. Yes, even with padding.
That's because the Gantt chart focuses on people-based tasks, not watching the work. Too often, that means people work in resource efficiency, not in flow efficiency. That creates dependencies and multitasking. That increases WIP. All of that means you are much less likely to be able to predict a completion date. Yes, Little's Law and the flow metrics rule our work. (See Predicting the Unpredictable to see all your prediction options, such as spiraling in on a date, offering a three-date range of possible, likely, and pessimistic.)
The best predictor of finishing anything is when the team has a regular cycle time. Review the cycle time series option in How to Predict When the Team Will Complete a Specific Backlog Item, Part 1. Build your cycle time series chart and use that.
I see too much wishful thinking when I review Gantt charts. However, when my clients tell me they have to use Gantt charts, I recommend they do what I do. Cheat. Use the Gantt to see monthly deliverables, not tasks.
Visualize Monthly Deliverables or Problems to Solve
When senior leaders tell me they really need to see a Gantt chart, I ask them if they would like to see the deliverables they want or the tasks. Most often, they say deliverables.
That's when I ask the project manager and the product leader to get together and decide on one problem to solve—as a deliverable—for the next month. (If they can deliver more often, terrific. But I often find that the organizations that love their Gantts also love component teams. That challenges faster cycle time. See Three Tips to Focus to Deliver Better Products Faster.)
Now, plan the next two monthly deliverables. Don't bother with all the tasks to support those deliverables. Just put the deliverables or problems in the Gantt, one per month. Not more than one. Just one. If your cycle time decreases, plan for fewer months, and keep the focus on deliverables. That will reduce WIP, increase throughput, and decrease cycle time all the good things about flow metrics.
As the team completes that first deliverable, add the next deliverable to the Gantt.
You eagle-eyed or long-term readers just noticed I described rolling wave deliverable-based planning with a lean roadmap. (See How to Plan for Change: Clear Strategy, Small Deliverables, Rolling Wave with Options.) Keep the plans small, focused on deliverables.
Large Detailed Plans Rarely Work
While I have a lot of experience with project and program management, I have not see all projects and programs. Maybe you love your detailed Gantts and get a lot out of them. But I never have seen a project work the same way the Gantt says it will. I always see unplanned feedback loops. Those kill forward progress, and because they're invisible, no one knows why.
If your experience matches mine, don't use long detailed plans. Instead, avoid task-based plans, which encourage micromanagement. Use deliverable-based plans with fewer details. Harness a short rolling wave of not longer than a month to deliver. That allows everyone to focus on solving this one problem. That does work.