Become a Project Management Pro
Get 7 days free access to all project management coursesStart free trial
If we had a magic potion that would make it so no projects could ever fail, there's no question we could sell it for a ton of money. Likewise, if we could ensure that we knew all the reasons projects fail and could map out how to avoid or mitigate those potential failure points, we'd also be pretty rich.
While we may not be able to cast a spell for successful projects, we can narrow down the key causes of project failure to a few major ones. Let's discuss the top 5 reasons for project failure, and come away with some positive and useful takeaways.
Why do projects fail?
In my opinion, there are five major reasons projects fail over and over again. Correct these from the outset, and you can avoid most project failures. The problem is, they aren't always that easy to identify before it's too late, nor are they really that easy to correct. The five reasons focus on communication, leadership, accountability, financials, and scope. Let's discuss each one further.
1. Communication breakdown
Communication is Job One for the project manager. Communication – in my opinion – is the top reason why projects either succeed or fail. I had one business analyst on one of my projects who told me he felt the most informed and up to date on my project (he was working on several projects with several different project managers). He said I sent out more email updates and kept the team better informed than the others he worked with. I liked that feedback - though maybe he was secretly telling me to cut back a bit on the emails... no way!
Have a communication plan in place – it doesn't even have to be a formal document, it can just be a list of regular meetings and communication points discussed in a project meeting or distributed via email. If you would like a template, you can download and customize this communication plan template that I use often. No matter the format you choose, your plan should outline the key communication contact points with email addresses and phone numbers as well as the ongoing project meeting schedules. There should be no excuse for anyone on the project team or the customer's team or any of the stakeholders to not know who to contact when – and how to get in contact with the project manager 24/7, if necessary.
2. Poor leadership
Leadership is critical – and a common success or failure point. The project manager can't go around complaining about the team being out of control. And the team shouldn't be left feeling that they don't know what to do or expect from one day to the next – it's a huge recipe for failure. Make sure everyone knows what is expected of them, and hold them accountable for reaching those goals or completing those tasks. Lead by example - if you're not late to meetings, there is no excuse for your team members to be either!
If you are doing everything you can to lead the team well, but have team members who are consistently underperforming, haven't responded to feedback, and things are just not working - then it is still your responsibility to raise the flag that you need to replace a team member or team members and the push to make that happen. The project manager who is in denial about his or her own leadership will not be able to garner respect and following from their team members, and chances are will have a tougher time steering the ship.
3. No team ownership
Our project managers and our team must own the projects we are working on. We can't control everything, but we can certainly own what we can control. And that is what is expected of the project managers who are managing the company's projects. They "own it." If something is needed for the project, then it is the project manager's responsibility to get it or at least ask for it, and it is the project team members' responsibility to raise flags when they need something.
Each and every project team member is expected to own the tasks they are responsible for and be accountable for the work performed on each of those tasks, as they contribute to the overall success or failure of the project. Clearly delegate responsibilities to team members, and establish what types of decisions they can make without you (e.g. emailing a supplier about a shipment), and what they need your approval for (a key decision about costs). Eliminating this grey area allows the team member to have more ownership over their work, and feel less like a cog in the machine.
4. Budget management
I feel strongly that the project manager who can't manage project financials should not be in the profession. Any project that is 10% or less over budget is doing well – and most projects that come in 10% over budget would be deemed a success. Certainly a 10% budget overrun is way more fixable than a 40-50% budget overrun. So how do you keep it at 10% or less? Luck? No! Diligent, weekly oversight, review, re-analyzing, re-planning and education.
By education, I mean educating the project team. Keep the team involved and up to date on the project's financial health. The team that knows you are managing the project financials closely is the team that won't charge their “grey hours” to your project. Everyone is working hard, putting in 40, 50, even 60 hour work weeks. But no one – or almost no one – is documenting those hours every day. So at the end of the week they have to get billed to one of the three or four projects they are working on... don't let those 5-10 hours that they can't remember what they were working on get billed to your project out of convenience. If they know you'll call them on it for accountability, they won't charge to it and your budget won't mysteriously disappear.
5. Scope oversight
Scope is one of those four letter words we usually struggle with and try to avoid bringing up unless we absolutely must. The worst thing that can happen is for the project manager to ignore the scope management part of his responsibilities, as the end result will usually be a project that experiences extra, non-paid and unplanned work driving the project over budget and over time.
Yelling “out of scope” at the customer when they request new work is not something that customer is going to enjoy hearing, and the change order that will follow will likely make them even less happy. But change orders are a reality on just about every project – I've never managed a project that didn't have at least some scope creep. Make sure you have a clearly defined scope of work at the beginning of the project. This offers the customer transparency about how much they are being charged for the work, and can be used to show how you calculated the amount for the change order.
Summary / call for input
That's my list from 20+ years of what I would like to call fairly regularly successful project management. If I never ran into issues or failures or major roadblocks, then I wouldn't be able to grow as a project manager. But thankfully the major issues have been few and far between and I've often had great teams to help me get through the “valley of the shadow of death” on each problematic project and come out on the other side doing ok.
If you are looking for more insight on how to successfully manage your projects, whether as a team member or agile manager, a project management course can help. If you are already an experienced project manager and want to take your career up a notch, consider getting certified and studying for the coveted PMP certification.
Readers, what does your list look like? Does this cover it? What would you change about it or add to it? Please share and discuss in the comments.