Most people think projects fail because they run out of money, miss deadlines or suffer endless scope changes. Those are certainly the things that make the headlines at project review meetings, but after more than forty years of managing projects, teaching project management and helping organisations recover troubled projects, I’ve come to a different conclusion.
Those aren’t usually the reasons projects fail
They’re simply the point at which everyone finally notices something has been going wrong for quite some time.
When a project is cancelled, it’s very easy to point at the overrun or the missed deadline and declare that to be the cause.
In reality, those are usually the final symptoms of decisions that were made weeks or even months earlier. Somewhere along the line, somebody accepted an unrealistic deadline, failed to involve the right stakeholder, ignored an emerging risk or assumed everyone understood the project’s objectives without ever checking that they actually did.
At the time, none of those decisions seemed particularly dangerous. They were often made with the best of intentions. After all, everyone wanted to get started quickly, keep the customer happy or avoid another lengthy meeting. Unfortunately, projects have an unfortunate habit of allowing small decisions to accumulate until they eventually become very expensive problems.
One of the biggest lessons I’ve learned over the years is that projects rarely collapse because of one dramatic mistake. They drift off course through dozens of perfectly ordinary decisions that seemed reasonable when they were made.
A planning workshop is shortened because people are busy. A risk is dismissed because it probably won’t happen. A supplier promises they can deliver on time, so nobody asks what assumptions that promise is based upon. None of these events causes immediate concern, but together they slowly move the project further away from where it was supposed to be.
That is why successful project managers often appear remarkably calm when everyone else is beginning to panic. It isn’t because they possess some mysterious talent or have access to better software. More often, it’s because they’ve learned to recognise the small warning signs long before they grow into major problems. They understand that preventing failure is usually much easier than recovering from it.
In this article I’d like to share some of the patterns I’ve seen repeated throughout my career. Whether the project involved a handful of people or hundreds, whether it lasted six weeks or several years, the same themes kept appearing. Better still, they’re all avoidable. Once you understand why projects really fail, you can begin making different decisions that dramatically improve your chances of success.
Why Most Projects Don’t Fail Overnight
Whenever I’m asked to review a struggling project, one of the first questions I ask is, “When did you first realise things were starting to go wrong?”
Interestingly, very few people answer with a specific date. Instead, they usually smile rather sheepishly and say something like, “If I’m honest, we started getting worried a couple of months ago,” or “Looking back, there were probably a few warning signs we should have paid more attention to.”
That answer tells me almost everything I need to know.
Projects don’t usually wake up one Monday morning and decide to fail. They drift. Every small compromise nudges them a little further away from their original objectives until eventually someone can no longer ignore what’s happening. By then, the schedule has slipped, costs have started climbing and confidence across the team is beginning to disappear.
I’ve seen this happen countless times. A sponsor asks for “just one small change” that nobody bothers to assess properly.
A technical issue is pushed into next week’s meeting because everyone is busy. Progress reports become slightly more optimistic than the actual situation because nobody wants to be the bearer of bad news. Individually these events seem harmless. Collectively they create the perfect conditions for a project to lose its direction.
The experienced project managers I’ve worked with have one habit in common. They stay curious. They don’t simply accept that everything is green because the dashboard says so. They ask another question. They look for evidence rather than reassurance. They encourage team members to raise concerns early, knowing that small problems are usually inexpensive to solve, while large problems rarely are.
That mindset has saved more projects than any scheduling tool, reporting dashboard or methodology I’ve ever used. Good project management isn’t about waiting until things go wrong and then proving how good you are at firefighting. It’s about spotting the first signs of trouble while there is still plenty of time to do something about them.
That’s the real difference between managing a successful project and managing a successful recovery.
Unclear Objectives: If You Don’t Know Where You’re Going, Every Road Looks Right
One of the most common causes of project failure appears before the project has really begun. Everyone is enthusiastic. The customer wants results. Senior management wants to see progress. The project manager is keen to get moving. In all the excitement, one rather important question often receives far less attention than it deserves.
What are we actually trying to achieve?
That might sound like an obvious question, but you’d be surprised how many projects begin with only a vague answer. There may be a broad idea of what needs to be delivered, but that’s not the same as having a shared understanding of what success will actually look like.
I’ve sat in meetings where everyone nodded enthusiastically as the project objectives were presented. Half an hour later, I asked each person individually what they believed the project was trying to achieve. Almost every answer was slightly different. None of them was completely wrong, but none of them was exactly the same either. That should have been ringing alarm bells, because if the leadership team can’t describe the destination consistently, what chance does the project team have?
This is where a good Project Charter earns its keep. It isn’t another document to satisfy governance or tick a box for the PMO. It’s the opportunity for everyone involved to agree why the project exists, what business problem it is trying to solve, what success will look like and, just as importantly, what sits outside the project’s boundaries.
When those conversations don’t happen, people naturally fill in the gaps with their own assumptions. Marketing imagines one outcome. Operations imagines another. The technical team starts building something slightly different again. Nobody is deliberately creating confusion; they’re simply making the best decisions they can with incomplete information.
Unfortunately, assumptions have an awkward habit of becoming expensive.
I’ve often said that assumptions are like taking out a loan. At first everything feels fine because you’ve borrowed certainty instead of doing the hard work of finding the answer. Eventually, however, the debt has to be repaid, usually at exactly the moment when the project can least afford it.
That’s why I encourage project managers to become almost obsessive about asking simple questions at the beginning of a project. What problem are we solving? How will we know we’ve succeeded? Who decides whether the project has delivered value? What assumptions are we making today that we ought to validate before moving any further?
Those conversations might delay the start of the project by a day or two, but they can save weeks or even months of expensive rework later on.
Weak Sponsorship: Every Successful Project Has Someone Fighting for It
When people think about project success, they naturally focus on the project manager. That’s understandable because the project manager is usually the most visible person on the project. They produce the plans, chair the meetings, coordinate the team and report progress to senior management.
What is sometimes forgotten is that the project manager doesn’t own the business.
A project manager can recommend, influence and communicate, but there are times when decisions need organisational authority rather than project management skills. Priorities need changing. Additional funding may be required. Departments need persuading to release key people. Difficult decisions have to be made when business interests collide.
That’s where an effective project sponsor makes all the difference.
The best sponsors I’ve worked with didn’t interfere with the day-to-day running of the project. They trusted the project manager to do their job. At the same time, they never disappeared for weeks on end only to reappear at the steering committee asking why everything had gone wrong.
They stayed engaged.
They asked sensible questions. They removed organisational obstacles. They challenged unrealistic expectations before they became impossible commitments. Most importantly, they reminded everyone why the project mattered to the organisation in the first place.
Sadly, not every project enjoys that level of support.
Sometimes the sponsor accepts the title but has little time for the role. Meetings are delegated. Decisions are postponed. Problems sit unresolved because nobody with the authority to act is available. Before long, the project manager finds themselves trying to solve business problems they were never empowered to solve.
I’ve seen capable project managers unfairly blamed for projects that were quietly losing executive support months earlier. There comes a point where no amount of good planning or brilliant communication can compensate for the absence of effective leadership at the top.
One question I often ask organisations is remarkably simple.
“Who loses sleep if this project fails?”
If the answer isn’t immediately obvious, you may already have identified one of the greatest risks facing the project.
Strong sponsors don’t simply approve projects.
They champion them.
They give the project manager the authority, backing and confidence to make progress, knowing that when difficult decisions arise, someone with genuine organisational influence is standing behind them.
That partnership between sponsor and project manager is one of the strongest predictors of project success that I’ve encountered throughout my career.
Risk Management: Hoping for the Best Isn’t a Strategy
If there’s one area of project management that’s frequently misunderstood, it’s risk management.
Many people hear the word “risk” and immediately think about filling in a risk register because the methodology says they should. A workshop is held, a few obvious risks are identified, someone assigns red, amber or green ratings, and everyone feels they’ve done their duty. The document is saved somewhere on the project server and, if we’re being honest, it may not be looked at again until the next project review meeting.
That isn’t risk management. That’s administration.
Real risk management is a way of thinking. It’s the habit of continually asking, “What could stop us achieving our objectives, and what are we going to do about it before it happens?”
The best project managers I’ve worked with never viewed risk as a negative subject. They saw it as part of making sensible business decisions. They encouraged people to talk openly about uncertainty because they understood that discussing a risk doesn’t make it more likely to happen. If anything, it usually has the opposite effect because people start taking practical steps to reduce the likelihood or lessen the impact.
Over the years I’ve noticed something else. Successful projects don’t necessarily experience fewer risks than unsuccessful ones. They simply recognise them earlier.
Every project contains uncertainty. New technology may not perform as expected. A key supplier could experience delays. Regulations might change. A specialist resource could become unavailable. None of those possibilities should come as a surprise because uncertainty is simply part of delivering change.
The question isn’t whether risks exist.
The question is whether you’ve chosen to see them before they become problems.
That’s why I often encourage project managers to treat their risk register as a living management tool rather than a document produced for compliance. Every significant decision should prompt another simple question.
“What new risks have we just created?”
It’s surprising how often that single question changes the quality of the discussion.
The Best Project Managers Build Trust Before They Need It
Technical knowledge is important, but after many years of working with project managers around the world I’ve become convinced that trust is even more valuable.
Think about the people you’ve most enjoyed working with.
They were probably organised and knowledgeable, but I suspect that’s not what first comes to mind. More likely, you remember that they listened. They kept their promises. They admitted when they didn’t know something. They treated people with respect, even when conversations became difficult.
People trusted them.
That trust becomes incredibly important when a project encounters problems because projects always do.
When a project manager has built strong relationships, stakeholders are much more willing to work together to find solutions. Team members feel comfortable raising concerns before they become crises. Sponsors are more inclined to support difficult decisions because confidence has already been established.
The opposite is equally true.
Where trust is weak, every issue becomes harder to resolve. Information is held back. People become defensive. Meetings focus on protecting reputations instead of solving problems. The project slows down, not because the technical challenges are impossible, but because the human relationships have started to break down.
I’ve always believed that project management is, first and foremost, about people.
Plans don’t deliver projects. People do. Software doesn’t solve problems. People do.
Processes provide structure, but it’s the quality of the relationships between the people using those processes that often determines whether a project succeeds or fails.
That has been true throughout my career, and despite all the advances in artificial intelligence and project management software, I don’t see it changing any time soon.
What the Best Project Managers Do Differently
People often ask me whether successful project managers possess some special quality that everyone else lacks.
I don’t believe they do.
What I’ve observed is something much simpler.
They remain curious when others become complacent. They ask one more question before making an important decision. They listen carefully instead of assuming they already know the answer. They recognise that a green dashboard isn’t proof that everything is healthy, and they understand that the absence of bad news isn’t the same as evidence that everything is going well.
Perhaps most importantly, they never stop learning.
Every project leaves behind lessons. Some are encouraging, others are painful, but every one of them has something to teach us if we’re prepared to pay attention. The best project managers carry those lessons into their next project, gradually becoming a little wiser with every success and every setback.
That’s one of the reasons I still enjoy teaching project management after all these years. Every conversation, every course and every project reminds me that there is always something new to learn.
The methodologies evolve. Technology changes. Artificial intelligence is already reshaping the way we work.
But the fundamentals remain remarkably consistent.
Successful projects still depend on clear objectives, honest communication, supportive leadership, thoughtful planning, sensible risk management and people who are prepared to work together towards a common goal.
Those principles have stood the test of time. I suspect they always will.
Monday Morning Takeaway
If there’s one idea I’d like you to remember after reading this article, it’s this.
Projects rarely fail because of one catastrophic decision.
Far more often, they drift away from success through a series of small decisions that nobody challenged at the time.
That should encourage every project manager because it means failure is rarely inevitable. It can often be prevented by asking a few better questions a little earlier.
So, when you sit down on Monday morning and review your project, don’t begin by asking whether it’s on schedule or within budget. Start with a different question.
“What assumptions are we making today that we haven’t actually tested?”
That one question has the potential to uncover hidden risks, expose misunderstandings, improve communication and prevent expensive mistakes before they ever have the chance to grow.
In my experience, that’s where successful projects begin.
Not with better software. Not with thicker methodologies. But with better conversations.
