Why Projects Fail
One morning after go-live, operations escalated: customers were placing orders on a delivery app, but some of those orders never appeared in the CMS. No red errors, no alerts, every dashboard green. Orders were simply vanishing between two systems, and every minute meant a hungry customer waiting for food nobody was cooking.
We found the technical cause within hours. The real question stayed with me much longer: why did nobody see this scenario coming, when it looked so obvious in hindsight? Sixteen years into delivery work, from writing the code to owning the outcome, I keep arriving at the same answer. Projects rarely die of technical causes. They die of things left unsaid.
Everyone nods at the objective, each in a different direction
Every kickoff has an objectives slide, and everyone nods. The problem is that "done" means something different in each head. Business hears "done" as customers placing orders. Engineering hears "done" as the API returning 200. Operations hears "done" as knowing who to call when something breaks. Those three versions of "done" can sit months apart.
PMBOK prescribes a project charter and success criteria. It sounds bureaucratic, but underneath it is one question everyone must answer in writing: what does finished mean, and which number proves it? My experience: if the kickoff doesn't produce at least one proper argument about the definition of done, that argument doesn't disappear. It just moves to the final week, where it costs the most.
Risks get written into a file, then left there
Every project has a risk register. Most get filled in once for compliance and never opened again. The real risks don't live in the file. They live in the half-joking remark a developer drops mid-meeting: "well, if the aggregator ever changes their payload format, that'll be fun." The room laughs, nobody writes it down, and three months later it becomes the first severity-one incident.
Risk management the PMI way is not form-filling. It is a rhythm: revisit the list weekly, ask which risk moved closer, which one needs a response now. Since the day I started treating meeting jokes as formal risk-register input, the number of incidents "nobody saw coming" dropped sharply. Because someone almost always saw it coming. They just said it as a joke, unsure anyone wanted to hear it straight.
Progress gets reported in hope
"Still on track" is the answer I fear most in a status meeting, because it carries no information. A project never slips all at once. It slips a little every day, and every day there is a perfectly reasonable excuse not to escalate yet. By the time it can no longer be hidden, the only options left are the bad ones.
My fix is to change the question. Not "are we on track?" but "what is the next milestone, how much work remains, and which task is waiting on whom?" Those three get answered with facts, not feelings. Earned value, a burndown, or a plain table counting tasks, the tool doesn't matter, as long as progress is measured rather than sensed.
Stakeholders get remembered when a signature is needed
There is a very quiet kind of failure: the project ships on time, on scope, exactly to spec, and users don't use it. Because in six months of building, the people who would live inside the system every day were never asked a single question. Stakeholder engagement in the books is a power and interest grid. In real life it is the discipline of going to talk to the people who never attend the meetings: the cashier who will tap this screen every day, the accountant who will reconcile these numbers every night. They don't sign off on the project, but they decide whether it lives or dies after handover.
Three questions I use to catch the disease early
Before every major milestone I answer three questions. Who makes the final call when two sides disagree? What actually happens if this milestone slips a week? Which number tells us whether we are winning or losing? If I, or anyone on the team, can't answer within thirty seconds, that gap is the project's number one risk right now, no register required.
And the vanishing orders? They became an item in our RCA process, a test case that runs every night, and a lesson I still carry: a system looking green is not the same as a system being green. The same goes for projects.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.