The kind of project failure on my mind is not the dramatic kind. A system goes down on launch day, an executive sponsor pulls funding, a vendor goes out of business mid-implementation, those are individual catastrophes with individual stories. The kind I'm interested in is quieter and far more common.
It looks like this. A project starts. The kickoff happens, work begins, and two months in there's a meeting where someone raises a question about scope. The answer that comes back is slightly different from the answer two other people in the room remember. The meeting ends with everyone agreeing to clarify. The clarification doesn't happen. A few weeks later, the question comes up again with a third version of the answer attached, and the team continues working, more or less, around the disagreement.
At month four, a stakeholder who hasn't been deeply involved sees the work in progress and points out that the result isn't what they thought they were getting. The team explains what they were building. The stakeholder explains what they thought had been agreed to. Both are speaking honestly. Both versions of the project are partially true. Neither was ever written down in a form precise enough to settle which version was canonical.
More times than I'm willing to count, and increasingly, as my role has grown, I have been that stakeholder.
By month six the project is over its original timeline and over its original budget, the team is exhausted, and the deliverable when it arrives is a compromise between the versions of the project that accumulated over its lifetime. Everyone involved would describe it, privately, as a difficult experience. The project ships. The post-mortem identifies communication issues as a root cause. Nothing in particular changes for the next project, which begins in a similar shape and produces a similar result.
This pattern is the most common form of IT project failure I have seen. Across organizations, sectors, and project types, the surface presentation varies, but the underlying problem has been remarkably consistent.
The problem isn't a shortage of documentation. Projects in this pattern often have plenty: kickoff slides, status reports, vendor proposals, charters, statements of work, meeting notes. The documentation is bulky. The documentation is also incidental. It accumulates around the project without ever doing the specific thing the project actually needs from documentation, which is to establish a shared premise that participants can refer to when disagreements arise.
What fails in these projects is the premise itself. Not documentation in the bureaucratic sense, but the underlying agreement about what's being done, by whom, for what reason, and with what outcome counted as success. Some version of that agreement exists at the start of every project. It has to, or no one would have funded the work. But the agreement usually lives informally, in the heads of the people who launched the project, in slightly different versions person to person. The differences are invisible at the moment of kickoff because everyone is broadly aligned. They become visible later, when a concrete decision has to be made and the underlying versions of the project produce different answers to it.
A project, in this sense, is a small temporary organization built to do a specific piece of work. Like any organization it operates on shared assumptions about what it's for. When the assumptions are aligned, work moves fast. When they're misaligned, most of the project's energy gets spent on coordination instead: meetings to re-establish consensus, decisions that get relitigated because they were never really settled, work that gets redone because the original version turned out to be solving a slightly different problem. This coordination cost compounds invisibly until it consumes the schedule.
The function of project documentation, properly understood, is to externalize the premise. To take the agreement that lives in the founders' heads and put it on paper in a form precise enough to be referenced when needed. The version of the project that exists on paper is one version. The version that exists in seven people's heads is seven versions, and the seven-version project will struggle because there's no canonical reference for what the project actually is.
If that's right, then the minimum documentation set for a project isn't a checklist of artifacts to produce. It's whatever set of documents is sufficient to establish the project's premise in a form that survives the disagreements that will arise over its lifetime.
In practice that turns out to be a small number of specific documents, though the specifics matter less than the function they collectively serve. A project needs a document that says what it's doing and what it isn't, because the boundary of the work will be tested. It needs a document that says who decides what, because decisions will need to be made and the question of who decides is usually the first thing that gets contested under pressure. It needs a document that says how success will be measured, because the measurement will drift to match the work in progress if it isn't anchored at the start. It needs a document that names the dependencies the work has on parties outside the team, because those dependencies will be discovered the hard way if they aren't named the easy way. And it needs a document that takes inventory of what could plausibly go wrong, because the discipline of having thought about it tends to be more valuable than any specific prediction, most of which will turn out to be wrong.
These aren't separate disciplines. They're five views of a single discipline, which is the work of making the project legible to itself before the engineering begins. A project that has done this work has a premise that can be referenced when disagreements arise. A project that hasn't has a premise that has to be reconstructed, repeatedly, in the middle of every disagreement.
The reason this work feels optional is that it produces no visible deliverable at the moment it happens. The documents are short. They can be written quickly. Once they exist, they sit on a shared drive and are mostly not looked at. The discipline appears to have produced nothing, while the visible work of the project, the engineering, the configuration, the integration, the testing, feels like the actual project. The premise-establishing work is invisible by design, and its value shows up later, in the absence of problems that other projects encounter. That's the hardest kind of value to credit and the easiest to deprioritize when there's pressure to start the real work.
The leaders who consistently produce projects that don't fail in this pattern have, in my observation, internalized something the people running the failing projects haven't: that the documentation isn't separate from the work. The documents are the externalization of the agreement that makes the rest of the work coherent. Skipping them doesn't accelerate the project. It relocates the cost of incoherence to later in the timeline, where it shows up as missed dates, redone work, and exhausted teams.
There's a frame underneath this that I think is worth sitting with.
Most organizations treat project management as an activity. It's what project managers do to keep things on track: status reports, timeline updates, risk reviews, steering committee preparation. Activity-framed project management is what most PMOs produce, and it's largely what gives project documentation a bad name. Most of it is performance. Most of it doesn't move the project.
The alternative is to treat project management as a premise. The premise is the underlying agreement about what the project is, why it exists, who decides what, and how anyone will know whether it worked. Premise-framed project management requires very little ongoing activity once the premise has been established, because the premise carries the load on its own. When a decision needs to be made, the criteria are written down. When a disagreement arises, there's a reference to settle it. When a scope change is proposed, there's a baseline to compare it against. A PM working in the premise frame is mostly maintaining the premise, keeping it current as conditions change, rather than producing activity around it.
My read on most IT project failures is that they're failures of the premise frame. The team has plenty of activity. The activity doesn't help, because the underlying agreement was never made explicit. The project flails because there's nothing solid to push against, and the harder the team works the more dispersed the work becomes, because the work is being shaped by seven slightly different versions of what the project is supposed to be.
The fix isn't more activity. It's a premise, written down, referenced when contested. A small set of short documents accomplishes this for most projects, and the specific documents matter less than the function they perform, which is making the project legible to itself before the engineering begins.
Projects with that kind of legibility tend to succeed. Projects without it tend to fail in the quiet, demoralizing way that opened this post. The asymmetry is consistent enough across organizations, sectors, and project types that the legibility test functions as a diagnostic. Show me a project that's struggling, and the absence of a shared written premise is almost always the underlying cause. The visible symptoms vary considerably. The structural cause does not.
The work that produces the legibility is a few days at the start of a project. The work that goes into projects without it is months of repair in the middle, and most teams pay the second cost because they didn't pay the first one.
— Chris