I should preface by saying I have nothing against Gantt charts. In fact, I think they’re a useful tool, and I’d love to see them more. But I also think Kanban boards, DevOps backlogs, Microsoft Project, Jira, Azure DevOps, Trello, Asana, Monday.com, and just about every other project management tool have their place. They’ve all helped organizations organize work more effectively. I might have some things to say about Microsoft Project’s progression, or lack thereof, but that’s for another day.
The problem with these tools is that none of them are project plans. They are representations of a plan. It’s a subtle distinction, but an important one. I’ve been asked many times to help “build a project plan.” Quite often, what stakeholders are really asking for is someone to show a PowerPoint (shudder) and put some bars and a position marker on a timeline, with some detail about what will be delivered and when. It doesn’t take long before the conversation expands to timelines (and how to make them 25% shorter), milestones (and how to add more in less time), dependencies (and how to reduce their risk), and due dates (because Fred in Sales needs it yesterday), as though the project has suddenly become real because it now has a high-level timeline.
At that point, I usually stop and ask a simple question.
“What exactly are we trying to do?”
That question often earns a puzzled look. Everyone knows what the project is calling for, supposedly. There may even be a budget that someone made up, an executive sponsor, and a target completion date (thank Fred). Those things are useful, but they don’t necessarily explain what the project is trying to accomplish or why it matters.
Without those answers, creating a schedule is a bit like estimating the cost of rope without identifying whether you need to use it to tie down a tent cover, or to hold up a bridge. You can give an average cost of rope, assuming they mean an inch-thick towing rope, and not a 500-ft long steel stay cable for a bridge, but that estimate won’t get to the point. Similarly, a Gantt chart can tell you when something should happen, but it cannot tell you whether it should happen in the first place. I can get you a rope by end of day, I can’t pull a truck with it until you explain your purpose.
A project plan should begin long before anyone starts arranging tasks on a timeline. It begins by understanding the problem, defining the desired outcome, identifying constraints, documenting assumptions, recognizing dependencies, and determining what success actually looks like. Once those questions have been answered, the schedule becomes much easier to build because it is describing work that has already been understood.
This is one of the reasons I developed a project planning framework over the past twenty years. It isn’t centered around a scheduling tool because scheduling is only one small part of planning. The framework is designed to help teams discover the work before they organize the work. The emphasis is on understanding the project, not simply tracking it. And most importantly, something Microsoft Project or Asana will never tell you: when should you engage with people, instead of just clicking checkboxes on a to-do list.
Throughout my career, I’ve seen organizations spend weeks or months refining schedules that were based on assumptions that nobody had challenged. The project looked impressive. It had color-coded phases, critical paths, dependencies, and enough milestones to keep everyone busy until SpaceX gets to Mars. Unfortunately, nobody had stopped to confirm whether the project was solving the right problem. As much as I appreciate a beautifully color-coded Gantt chart, it still can’t rescue a project that was never properly understood.
That doesn’t mean project management tools have no value. Quite the opposite! Once a project is properly understood, those tools become incredibly effective. They help teams coordinate work, communicate progress, manage dependencies, and adapt as the project evolves. They simply shouldn’t be expected to answer questions they were never designed to answer, especially when you need to report upwards to higher levels of management or a CEO.
A roadmap communicates direction. A backlog communicates work. A Gantt chart communicates schedule. None of those define the project itself. They describe decisions that should already have been made.
That’s the gap I believe many organizations experience. They invest considerable effort into managing work before investing enough effort into understanding the work. The result is often a project that becomes more detailed without becoming more defined.
Good planning isn’t about producing more documentation, although I can’t say it’s about producing less either. It’s more about balance, and reducing uncertainty so that the right decisions can be made before significant effort has been invested. If that means more documentation, so be it. But it might mean more diagrams, a short video explaining it, or just a sketch of what it needs to look like when it’s done. Once uncertainty begins to disappear, estimates become more reliable, conversations become more productive, and the schedule becomes an indication of a well-understood plan rather than an educated and volatile guess.
The bars on the Gantt chart usually matter.
The thinking that created them matters more.