Skip to content

I can tell you why many projects fail  

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

If we had a magic ball that could tell us why projects fail we could make millions. Big projects fail every day. I've personally had £1 million projects fail miserably and shutdown completely. It's painful. Entire organisations can be lost because of it. Maybe even two - the delivery organisation and the outside customer. And if it's a huge project for an internal business unit or group there's an even greater chance that a catastrophic failure can cause the demise of an entire company.

If we knew why projects fail all the time we could mitigate or avoid the damage. Run the project differently and thus avoid the failure point, right? Sort of like going into the future and seeing what bad thing is going to happen and then going back in time and doing things different so you change the course of history. While that never works out well in the movies maybe it would for projects.

I, however, have the Magic 8 Ball that will tell me why projects fail. And I'm going to shake it now and share this information to you. Ready? Let's go... (imagine the shaking)...

Bad communication. Project communication is Job One for the project manager. Nothing the PM does on the project can affect the success or failure of that project like the way he handles communication. That's customer meetings, team meetings, quarterly project reviews, emails, phone calls, 3rd party vendor calls, or lack of any of these. And it's not only outgoing communication, but also listening and processing skills.  It begins and ends with the project manager and he's not good at it, then the project will definitely suffer.

Messed up requirements. Good, complete requirements are the lifeblood of the project. Nearly everything is built off of those requirements. For a technical project, the design and development of the final solution comes from those requirements. Test cases and test scenarios are built from those requirements and testing is measured against those requirements to ensure the proper, expected outcomes are happening during system testing and user acceptance testing (UAT). Missed requirements or poorly documented requirements leave the delivery team building a solution that likely won't meet end user needs and demands and won't satisfy the customer at implementation time. Requirements are complex and need to be detailed and well-documented in order for the project to be successful.

Impossible expectations that were never curtailed. Sometimes we are handed a project with delivery dates for key deliverables and milestones already laid out. That's fine when it's possible to meet those dates. Of course, a more desirable route would be for the the project manager and team to draft the project schedule using real knowledge of the statement of work (SOW) and then refined based on business processes, requirements and initial design meetings. From that draft and refined schedule comes real, doable delivery dates and milestone dates. If the project manager and team are forced into accepting dates that won't work, then the project is doomed to experience timeline failures throughout the engagement. If the project manager is handed dates that aren't going to work, it is critical that this be made known as early in the project as possible – in the hopes that new dates that will be acceptable to both sides – can be negotiated.

Lack of appropriate funding. Oh yes. Ask if there is money in the hopper for this project effort. When you're running internal projects this is easier. When dealing with external customers this is often much easier said than done. The reality of projects and consulting engagements is this... sometimes you think because of the wording of the call or email that there is a real project there when in reality the customer is still exploring it. No budget really exists yet. And sometimes the project may even start while the customer really only has funding for upfront planning efforts hoping to get the remaining funding approved while the project is moving along. Bad idea, but you'll be the last to know that this is the case. For consulting engagements I ask if they have budget for the effort or not. You can ask customers on larger projects if it's fully funded - but they may not tell you. It's always a risk. Especially if change orders come into play.

Misappropriated project resources. How about resources? Have you ever managed a project thinking you had your business analyst and technical lead 100 per cent for the entire project only to hit a point where you lose them both to another high-end project at a moments notice? Sure, you are given replacement resources but it's not the same. The team chemistry may be lost, the communication flow is interrupted, depending on skill sets and experience at least some tasks will probably need to be reassigned, and your customer will likely be caught off guard. Customer confidence will take a hit and so might team morale and collaboration. This is not a recipe for success.

Summary / call for input
Of course, there really is no Magic 8 Ball that can tell you why projects fail and I certainly can't tell you “prepare for this list and you'll never fail.” But it's a good starter list and it is a fairly straightforward list of key failure points on many projects I've witnessed along my project management path.

How about the readers here? Do you agree with this list? What would you add to it or remove from it? Please share some of your own thoughts and experiences and let's discuss and mitigate and avoid together.




Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Tom Collings
    Tom Collings 18 September 2017, 05:01 PM

    Hi Brad. I agree that communication is essential to any successful project but right at the top of my list is the team. A correctly structured team should bring an appropriate amount of experience along with the technical skills to be able to overcome the inevitable obstacles along the route often without intervention from the PM at all. The skill on the PM side is then to build that team, starting well in advance of the official start of the project, and then maintain it as the needs of the project evolve - balancing this, of course, with the resources demanded by other projects (this topic could fill a blog post on its own!) Tom Collings Programme Manager, Cambridge Consultants

  2. Matthew Henry
    Matthew Henry 22 September 2017, 09:39 AM

    Brad, excellent article. I don't know whether this is a stand-alone item or part of 'communication' but if there is no coherent 'vision' which has been effectively shared with the project and all stakeholders then the project will fail. If everyone is bought into the vision, they are able to overcome the inevitable hiccups along the way. Matthew

  3. Renee Teng
    Renee Teng 08 November 2017, 03:27 AM

    Thanks for sharing your insight. There is a tree swing cartoon which depicts the pitfalls in communication of project management. It first came in the 1970s and many variants came later on different subject, such as software and management.Then it became popular among the management to address issues when projects did not go the right way. Someone blames the pitall in communication, such as not listening to the client, but it also reveals the problems in product development and reminds anyone involved what to do and what not to do. If you are interested, here is the Project Management - A Tree Swing Story