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 projects as big as $1.3 million fail miserably and shutdown completely. It's painful. Entire organizations can be lost because of it. Maybe even two - the delivery organization 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% 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.
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% 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.
RSS Feed
