Why is it that that so many projects fail? An often cited statistic is that 70% of projects fail. Although there doesn't seem to be an original source for this statistic, it's worth asking why projects fail. If we can learn from past project failures, we can avoid making the same mistakes twice.
When I first became a project manager, I seemed to learn everything about project management failures the hard way: misjudging estimates, forgetting to ask key questions, and being hesitant to say no.
While I’ve been a practicing project manager for many years at this point, I’ve still had projects fail spectacularly for all sorts of reasons. In this article, I'll cover what makes projects failures, why project ultimately do fail, and tips for avoiding failure.
When Are Projects Considered Failures?
Projects are considered failures when they have budget overruns, are delivered late, or are not delivered to the planned scope. There is often some wiggle room, however. Projects are often delayed for reasons beyond the control of the project manager (ex. the client didn't send their website content on time).
Scope can often change throughout a project as well, due to changes in the client's or stakeholder's needs. Although scope creep can be a culprit of project failure, if this is handled properly (with change requests and sign off from key stakeholders), it doesn't need to end in a failed project.
6 Common Reasons Projects Fail & Examples
So why do projects fail? Here are five of my biggest project management failures that illustrate common causes of project failure, and the important lessons learned that I took from them to improve future project success.
1. Not Communicating When Things Get Difficult
It’s a basic human instinct to not want to call attention to yourself if something’s gone wrong and no one’s noticed. It’s counterintuitive to the very nature of project management, but poor communication is so often why projects fail.
I’ll admit, the combination of a very difficult client and a budget or timeline about to be blown has made me hesitate just a bit too long in notifying a client of the status of their project.
This is especially true when it’s been quiet and all-clear for the last few days or weeks on a project. That’s also the most vulnerable time in your project time frame—it’s so important to retain and foster the trust a client has in their project manager.
Lesson learned:
Every time I’m about to pause before delivering difficult news to a client I think to myself: is it better to set their expectations now, or do I want to deal with this after it’s too late? The answer is ALWAYS do it now, and be proactive.
You’ll also lay the ground work for managing future unrealistic expectations while working with a particular client.
2. Not Sticking To Agreed Upon Scope
On a particularly detailed project, a project team member working closely with me suggested we try a new slider plugin for a portfolio section we were working on for a client’s site.
It used a framework we typically didn’t work with, but the slider looked and functioned more elegantly than the one we normally used. I was hesitant at first because of the tight timeline and particularly detailed design direction of the project, but I was swayed by the promise of better function for the client AND our dev team.
It wasn’t something we had discussed upgrading in our typical toolset in the past, but the timing seemed right and it was a good opportunity to see the new plugin in action.
It ended up being one of the most costly decisions of the project, in man hours and budget. The slider didn’t end up supporting a key feature and did not easily support responsive sizing or particular browsers.
This didn’t go through the usual vetting and decision-making process with tech leads and other developers as a planned update. It was an incredibly simple mistake that ended up costing both of us a lot of stress, embarrassment, and wasted resources.
Unnecessarily ‘gold plating’ scope by adding new project deliverables or by overcomplicating project tasks is another typical reason why projects fail.
Lesson learned:
Stick with your processes and don’t update things on a whim. Should your team members really need or benefit from a change in process or tools (including project management software or other project management tools and tech) mid-project, go through all of the motions to vet it.
3. Becoming Too Friendly With Your Team And Clients
There’s a definite divide between professional relationships and casual friendships, and I’ve learned to keep those separated through careful practice.
That’s not to say you can’t be friends with your teammates or clients—just be aware of when you turn the professionalism on or off in your interactions.
Years ago, I worked at a company full of people just out of college, all with similar interests and living close by each other in our city. Naturally, we hung out after work and on weekends together, forming strong friendships.
One day I had to ask for a quick turnaround on a project that no one really liked—it wasn’t pretty, fun, or something that was seen or appreciated by most people.
The designer on the project blew through the due date and was instead working on a larger, more modern site design that wasn’t due for weeks. I confronted him about it and he asked me why I was being hard on him when we were friends.
A blurring of the lines between personal and professional is sometimes the reason for why projects fail as it can impact accountability.
Lesson learned:
Be friendly but stay professional in order to continue holding people accountable to their actions on a project. It’s much easier to feel we get a “pass” with our friends on things, and that can be a dangerous (and awkward) situation to get into when it’s being mixed with professional obligations.
4. Panicking Before You Have A Chance To Process
Maybe it’s just me, but I find it easy to react to certain red flags or keywords on projects.
Things like all caps emails, the words “new deadline” or “site down”, or more innocuous warning signs like lack of communication at a key point of a project, a new stakeholder being brought into a project just before launch, or weird glitches on a site just before client demos.
There is nothing that makes me feel more flustered than immediately turning to a manager, developer, or client to ask for clarification on something that would have been obvious (or doable myself) if I had taken a moment to breathe, process, and think about my next step.
There have been so many instances where I thought a major bug was present on a site (when it was just an issue with my own or the client’s cache), misinterpreted a request for a feature that seemed much larger than what’s really needed, or a client thought their site/server was down when they really weren’t connected to the internet (yes, that happens a lot).
While this point isn’t one large project failure on its own, it contributes to poor communication and can incite panic when panic is not needed.
Lesson learned:
Never be afraid to look away from a reactive email or message, pause, and take a moment to investigate before asking for more help.
5. Not Following Processes
Ah, yes: the “this item can skip our typical dev/design/review/QA process because it’s just a small change” fallacy. This is so often why projects fail.
So many times I’ve seen this happen on projects. I’ve made this mistake with seemingly “easy” maintenance updates, small feature requests on larger projects, and project scope changes across the board.
Something like updating a form field option might be simple on the surface, but might become spaghetti code and a full-system update once a developer dives into it.
Likewise, a client asking for a small visual change on a project might upend the design process and force you to rethink part of the whole site flow as a result.
Lesson learned:
Always trust in the process and go through the discovery, estimation, and QA processes accordingly: I’ve learned that there’s never a small enough change to NOT disrupt something else along the way.
Be protective of your process and become a champion for doing things the right way—even if it means just a little bit more effort. This also means picking the right project management methodology or workflow, whether that's agile, waterfall, Kanban, or a hybrid.
6. Not Setting Clear Goals
From the outset, projects should have clear, measurable project goals (also known as SMART goals). How can we know if we're working on a successful project if we don't have something to measure project progress against?
As part of the planning process, you'll determine project milestones, objectives, and success metrics. Think about your project schedule, project requirements, and project budget. Choose the KPIs that make the most sense for your project or initiative.
This is one of the most common causes of failure. Without this, project team members (and you!) won't know if you're on track when it comes to timeline, scope, and budget. You'll rack up missed deadlines and budget overages before you even notice that something is amiss.
Lesson learned:
Always set KPIs and metrics for your projects, even those smaller projects where this might feel unnecessary or like an extra step to determine something you already know. You might discover a mismatch between your project objectives and KPIs that will save you a headache down the road.
3 Steps For Avoiding Project Failure
Here are three steps for avoiding project failure all together.
- Identify risks: Normally, you'll do this as part of the process of creating the project plan. Capture risks in a risk register or RAID log.
- Assess risks: Assess the likelihood and impact of each risk. Risks that are very likely to happen and would have the most negative impact should be given the most attention.
- Create risk management plans and contingency plans: What will you do if a particular risk comes to pass? How can you reduce the chances of that risk occurring?
Read more about how to avoid project failure here.
What Do You Think?
These are some of the most common reasons for project failure, but they aren't the only ones. You might also encounter a lack of resources, a lack of teamwork, and a variety of other issues. The main thing is to stay vigilant, keep your communication channels open, and ensure you've covered off risks that might threaten your project.
Let us know about your own sticky situations that have taught you a thing or two in the past! Why have your projects failed? What did you learn from the project failure?