The Gantt Chart Is Fiction (And Everyone Knows It)
On the mental model that has been failing software projects for fifty years, and why it keeps being used anyway.
The meeting has been in the calendar for two weeks. The project manager has prepared a slide deck. There is a Gantt chart — there is always a Gantt chart — its coloured bars marching confidently across the screen from left to right, each one representing a phase of work that will begin on a precise date, proceed at a predictable pace, and conclude exactly when the bar runs out.
Everyone in the room has seen this chart before. The developers have seen it many times. They are looking at it now with the particular expression of people who have learned, through painful experience, that pointing out the obvious is rarely worth the political capital it costs.
The chart is fiction. Everyone in the room knows it is fiction. The meeting will proceed as though it is not.
This scene plays out, with only minor variations, in organisations everywhere, every day. I have been in that room more times than I care to count, on both sides of the table. After forty-five years in the industry, I have come to believe that the thinking buried inside that chart — a mental model so pervasive that most people have never stopped to question it — is responsible for more wasted money, more broken working relationships, and more sheer human misery than any other single factor in the history of software development.
That is a large claim. Let me make the case for it.
The mental model goes like this: software development is fundamentally similar to building construction. You gather your requirements — the architect’s drawings — produce a detailed design, and then hand it to a team of developers who build the thing according to the plan. The building part is where the time and money go. The rest is just planning.
This feels intuitive. It satisfies the finance department’s need for a budget. It gives management something to approve and something to hold people accountable to. It maps neatly onto every other capital project an organisation might undertake. And it is wrong. Not approximately wrong, not wrong in ways that better tools might correct. Fundamentally, structurally wrong — because software development is not construction. It is design, all the way down, and design does not work the way construction does.
In construction, an architect can specify a building in sufficient detail that a crew can build it without constantly referring back for decisions. The materials behave predictably. The edge cases have been resolved by generations of previous builders. None of this is true in software. The domain is almost always novel — if it weren’t, you’d buy existing software rather than building new software. The technologies change constantly. And the edge cases cannot be fully enumerated by anyone sitting in a room writing a requirements document. They can only be discovered by building the system and watching what happens.
Consider a developer implementing an online payment feature. The requirements describe the happy path clearly: the user enters their card details, the payment is processed, the order is confirmed. Straightforward. Then the developer types the word “else” — the part of the code that handles what happens when things don’t go as expected — and stops.
Is a payment gateway timeout the same as a declined card? Should the system retry, and how many times? Is an expired card the same message as a stolen card? If the payment succeeds but the confirmation email fails, has the order been placed? If the user tries again, will they be charged twice? None of these questions are in the requirements document. They couldn’t be — they only become visible from the point in the implementation where you are close enough to the actual behaviour of the system to see them. The requirements described what the feature should do when it works. They said almost nothing about what it should do when it doesn’t, because you can only enumerate those cases by building the thing. This is not a planning failure. It is the normal, expected, entirely routine operation of software development. Every significant feature has its else clause. The Gantt chart has no column for it.
The software industry tried to solve this, twice. The first attempt was the waterfall methodology — named for its diagram showing project phases flowing downward in sequence, each completing before the next begins — which crystallised through the 1970s as the discipline’s answer to the chaos of early software projects. It looked like engineering. It produced documents management could review and approve. It gave finance a basis for budgeting. And it failed, consistently and expensively, for exactly the reasons described above: it was built on the assumption that you could know everything that mattered before you started building, which you cannot.
By the late 1990s there was enough wreckage from waterfall projects to generate serious dissatisfaction. Out of that came the Agile Manifesto of 2001 — a short document signed by seventeen developers who had gathered to articulate what a better approach might look like. It is worth reading if you haven’t. It values individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. Not one of those values mentions two-week sprints, or daily standups, or story points, or velocity charts.
What most organisations adopted in the name of agile was a project management framework. Which is a different thing entirely. A sprint is just a short waterfall. A backlog is just a requirements document broken into smaller pieces. If the underlying assumption is still that software can be planned, estimated, and tracked like a construction project, changing the vocabulary and the cadence changes nothing fundamental. What you get instead is what practitioners have taken to calling “agile theatre”: the team holds its standups, the Scrum Master facilitates the retrospective, and meanwhile, somewhere above all of this, a senior manager has a spreadsheet with a delivery date committed to before the first sprint began, derived from an estimate produced before anyone wrote a line of code. The ceremonies continue. The date does not move.
I have written elsewhere about what happens when someone gives an honest estimate in this environment. It tends not to go well for them.
So why does the fiction persist? Because it is useful. Not useful for building good software — fifty years of evidence is unambiguous on that. Useful for conducting business in a way that feels manageable to everyone involved.
Consider the position of a large consulting firm bidding for a software contract. The client wants a fixed price and a guaranteed delivery date. The honest response — that both are unavailable at this stage, because the full scope of what will be required cannot be known until a substantial portion of the work is done — tends not to win contracts. The response that wins is a confident number and a confident date, underwritten by a methodology impressive enough to make both look credible. The firm that gives the honest answer loses the work. The firm that gives the confident answer wins it, and then has years of billing ahead regardless of whether the project succeeds, because extracting a large consulting organisation from an in-progress project is itself a significant undertaking. This is not a description of dishonest behaviour. It is a description of incentives that systematically reward the perpetuation of a false mental model.
The cost of those incentives is not abstract. I worked with a developer early in my career — talented, conscientious, someone who genuinely cared about the quality of what she built — who spent eighteen months on a government project contracted on a fixed-price, fixed-scope basis, with a scope that had been defined before anyone wrote a line of code. By month twelve she was working weekends routinely. By month eighteen the system had been delivered — late, incomplete in the ways that the contract did not technically require to be complete — and she left the industry shortly afterward. She had been in it for four years.
I have seen versions of that story more times than I care to count. The details change. The structure doesn’t. A commitment is made before the necessary information exists to make it responsibly. Everyone downstream absorbs the consequences.
The Gantt chart on the screen is not the problem. It is a symptom. The problem is a fifty-year-old mental model that the people funding software projects find too useful to give up, and that the people building software projects have learned it is not worth their careers to challenge.
That is not where you want to be. And it is exactly where most organisations are.
My book, Code Is Design, goes into this topic in a way that is accessible to both the technical people and those that are managing or underwriting software development projects.
It is available now on Amazon.