Most projects don’t fail at the end. They fail at the beginning. The people involved just don’t know it yet.
How bad is it? From a database of 16,000 projects, only 0.5% were completed on budget, on time, and on benefit.
These numbers come from a book called How Big Things Get Done by Bent Flyvbjerg and Dan Gardner. I just read it, and it should be required reading for anyone starting any project. The authors focus on big infrastructure projects, yet the lessons apply to projects of any size.
The book reminded me of all the failed projects I’ve witnessed in my career and how they were doomed from the beginning.
It starts with a question most teams never ask: why are we doing this project? Is it mission critical, or are we just following a trend? AI strategy projects come to mind. Everyone wants one. No one is asking the hard question of why.
Then comes planning. How much will the project cost and how long will it take? Usually the answer is a number pulled out of thin air without so much as a benchmark. People tend to assume that their project is unique, that it will somehow take less time, cost less money, and produce better results than similar projects undertaken in the past.
Who has not heard that story before?
And once the project starts moving, there is rarely a system in place to alert anyone that it’s running off course from the beginning.
I took a job with a company that was implementing a new ERP (Enterprise Resource Planning) system due to go live a few months after my first day. This project was one of the reasons I took the job. It pointed to a company that was serious about process improvement and growth.
Two months after I joined, the project was cancelled.
It was not a total surprise. After onboarding, I hit the ground running participating in the testing phase and quickly noticed that the project was not where it should be. I was not the only one with that thought, so leadership hired a consulting firm to audit the progress.
The project was already a year behind schedule and a million dollars over budget. The consulting firm confirmed that there was no way it could go live in a few months. Their estimate: one additional year and one more million to complete. That would have put the project at three years and three million dollars, as long as everything went right from that point on.
The project was dead.
I was full of questions, so I reached out to the most senior person in the department.
Question: Who from the accounting department was part of the implementation team?
Answer: Why would the accounting team be part of that?
The problems started to become clear. No one from the accounting team had participated in any aspect of the project. The very expensive consultants were supposed to deliver a turnkey solution.
Question: Was there anyone from the company who functioned as the bridge between the company and the consulting firm?
Answer: The IT Director.
Question: And was the IT Director removed from his day-to-day duties and allowed to focus on the project?
Answer: Of course not.
This project was never going to happen.
No one had asked whether the original budget and timeline were even realistic. In my experience, any transformation project that doesn’t plan for at least three years is setting itself up for failure. No internal team had been assigned to the project. The very expensive consultants were trusted to deliver a solution for a business they didn’t understand. And the one person designated as the bridge between the company and the consultants was doing it as a side project on top of their actual job.
The real cost wasn’t just the money or the time. For people like me, who took the job because the project signaled ambition and seriousness, the company went from forward-looking to stuck in the past overnight. The project didn’t just fail. It told everyone paying attention what kind of company this actually was.
A million things can go wrong during a project. But it is usually just a few things early on, the questions nobody ask, the resources nobody commits, the warnings nobody builds a system to catch, that decide whether it fails or succeeds.