The post-mortem analysis of a failed technology project almost never identifies the real causes. The documented causes are technical: the integration was more complex than estimated, the data quality was worse than expected, the system performance did not scale. These are real problems. But they are not the causes — they are the symptoms. The causes are organizational, human, and political, and they are rarely documented because documenting them requires naming the decisions, the behaviors, and the dynamics that produced the failure. That naming is uncomfortable.
The Decision That Was Never Really Made
A large proportion of technology project failures trace back to a decision that was never actually made. The scope was agreed at a level of generality that left the important questions unanswered. The vendor was selected with reservations that were suppressed because the procurement decision was made under time pressure. The go-live date was committed to before the work was understood well enough to know whether it was achievable. These non-decisions create the conditions in which technical problems become fatal, because there is no clear authority to make the adjustments that would resolve them.
The Sponsor Who Was Not Really Sponsoring
Project sponsorship is one of the most frequently cited critical success factors and one of the most consistently underperformed. A project sponsor who attends the steering committee monthly, receives status updates, and approves budget requests is not sponsoring the project. A project sponsor who uses their organizational authority to clear the obstacles that the project team cannot clear on their own, who holds the business functions accountable for participating in design and testing activities, and who makes the hard decisions — about scope, about resources, about deadlines — when the project needs them to be made, is sponsoring the project. The difference between these two definitions of sponsorship is the most consistent predictor of project outcomes I have observed.
The Change That Nobody Was Prepared For
Most technology projects change how people work. Most organizations are surprised to discover that changing how people work is difficult, even when the people intellectually agree that the change is necessary. The resistance to change is not always explicit — it is often expressed as technical problems, data quality issues, or scope disputes that turn out to be displacement of the discomfort people feel about the underlying change. Addressing that discomfort directly — through communication, participation, leadership modeling, and honest acknowledgment of what will be difficult — is change management. Ignoring it and pressing forward technically is the approach that produces the most expensive lessons.