![[PM4K] - The Book @ AMAZON](http://3.bp.blogspot.com/-uWOvpXmAZEA/VZs0HpFXCyI/AAAAAAAABFE/EC07hE7dUTw/s1600/PM4K%2BBook%2BCover%2Bv3%2BJPG.jpg)
Posts
From experience, the following are the TOP10 causes of Project failure that Mathew can think of (they are not in any kind of order):
#1. Lacking Sponsor's Involvement/Ownership
#2. Halo Effect (Wrong Man for the Job)
#3. Poor HR Management
#4. Poor/Inadequate Project Communications
#5. Ignoring Project Stakeholders
#6. Absence of Risk Management
#7. Scope Creep/Unrealistic Expectations
#8. Lack of Monitoring of Plan
#9. Absence of a Project Management Methodology
#10. Simply BAD LUCK :)
You may feel free to chose any of the above and/or add a cause from your own experience that you think is the most recurring reason for project failure.
Looking forward to sharing & learning.
[Mathew@PM4K]
![[PM4K] - The Book @ AMAZON](http://1.bp.blogspot.com/-SxDz74KQ5_o/VZszWEf3hnI/AAAAAAAABE4/628Pl2hZxbs/s1600/PM4K%2BBook%2BCover%2Bv3%2BJPG.jpg)
1665 Comments:
#4 Poor / Inadequate Project Communications.
#4. Poor/Inadequate Project Communications
For me, no 1 is the biggie. Without commitment from the project sponsor, the project will drift and drag. The client team members, and client employees who are not too keen take that as the green light to drag their feet and generally be obstructive.
After that number 4.
After that, inadequate change control leads to number 7.
Number 10 rarely happens, but is often the excuse.
Under my experience depends also from the expectation/typology of the stakeholder that are not met anyway:
#1. Lacking Sponsor's Involvement/Ownership if the sponsor is not completely involved.
#4. Poor/Inadequate Project Communications lack of communication and inadequate real picture of the business threathed (action status and so on)
#5. Ignoring Project Stakeholders just threathed above
#6. Absence of Risk Management (due to the fact that sometimes the project manager and the team underevaluate some risk)
I would like also to add a Project management plan not fit for the purpose of the project. I think that must be evaluted the right boundaries of the project in order to avoid an over/under estimation of the business required.
For me, top 1 reason should be improper Risk management. The risk can be on scoping, estimation, quality etc etc ....
for me, reason 1, 3 & 4 are largely accountable for project failures. without actually understanding or involving project sponcers and client ,planning will not be good. and without proper people management no project will be successfull.
for me: project requirement and specifications are not clear to either party.
Mohit Goel
mohit@wildnettechnologies.com
#4. Poor/Inadequate Project Communications
#7 Scope creep/unrealistic expectations
For me, the three most important reasons, in their order of importance are:
#1. Lacking Sponsor's Involvement/Ownership
#4. Poor/Inadequate Project Communications
#8. Lack of Monitoring of Plan
Regards
Bala
No doubt - Communication Failure- Either with client or within team
1. poor planning
2. poor planning
3. poor planning!
1. project team.
since planning or communications failure or monitoring it is all performed by project team so the essential part is the project team
According to me, the top#1 cause for Project failure is,
#7. Scope Creep/Unrealistic Expectations
Regards
krishnan S
IMHO
1 Lack of Monitoring of Plan (=> project controlling!)
2 Bad planning (incl. Scope Creep/Unrealistic Expectations)
3 Poor/Inadequate Project Communications
4 Lacking Sponsor's Involvement/Ownership
best regards
Thomas
In My views
Lacking Sponsor's Involvement/Ownership
Poor HR Management
Absence of Risk Management
Scope Creep/Unrealistic Expectations
Poor/Inadequate Project Communications
Are the main reasons of Project Failures. Apart from these major factors,
Client's Interest & involvement plays the greatest part in Project Progress and success.
Last but not the least is Strategic management is needed at both sides;
client & Consultants.
In my experience it is:
Halo effect
Absence of Risk Management
Absence of trainings
IMHO - the order should be
#4. Poor/Inadequate Project Communications
#6. Absence of Risk Management
#7. Scope Creep/Unrealistic Expectations
#8. Lack of Monitoring of Plan
#9. Absence of a Project Management Methodology
#5. Ignoring Project Stakeholders
#1. Lacking Sponsor's Involvement/Ownership
#2. Halo Effect (Wrong Man for the Job)
#3. Poor HR Management
And yes Luck also plays a little role in everything you do :-)
#10. Simple BAD LUCK :)
In My Experience
#2. Halo Effect (Wrong Man for the Job)
#4. Poor/Inadequate Project Communications
@Jasmeet: Mathew agrees with you. LUCK (no matter how small), does play a role ;)
....
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
IMHO here is list of most frequent causes in descending order of occurrence:
1. Poor/Inadequate Project Communications
2. Scope Creep/Unrealistic Expectations
3. Halo Effect (Wrong Man for the Job)
4. Ignoring Project Stakeholders
5. Absence of Risk Management
6. Lack of Monitoring of Plan
7. Absence of a Project Management Methodology
8. Poor HR Management
9. Lacking Sponsor's Involvement/Ownership
10. Simple BAD LUCK :)
Dear Anish,
I will pick something outside your list of 10. I feel that the most serious cause of project failure is when the project is not aligned to the business needs and situation. Most of the cases that I have come across, the project offered say A while the business needed X, Y and Z or in some cases could afford only X and Y. Since the start of any activity is the best time to get your act together and prevent serious adversities, in my view, it is imperative that all stakeholders and managers take the time needed and make the effort necessary to ensure that what they are about to set out to do truly aligns with the organizational strategy, competency and the on ground situation.
Regards,
Devmitra.
Just my guess, based on personal experience:
- Over-optimistic projects with unrealistic schedules and budgets.
- Poor communications.
- Fundamentally ill-conceived projects (solution in search of a problem, "pet project" unsupported by a valid business case).
- Over-ambitious projects that should have been done incrementally.
My personal experience is:
- In recent years the Cost of winning project reduced due to firm competition among pure players (Bidders). The delivery group with in the executing organization used to in tremendous cost pressure and many of the time the Final Delivery cost exceeds the Winning cost, which resulted in Cost Overrun, Over Schedule; hence resulting in low morale/quality; ultimately resulting in costumer dissatisfaction and failure of the project.
@Devmitra: Thanks for thinking out of the list & emphasizing the importance of Scope Defination. Mathew agrees, "the project should promise only what it can deliver & should deliver only what it promised." Nothing more or less.
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
I found a rather peculiar reason for failure in one of the projects I recently worked . - Internal Politics within the Customer Organization lead to failure. I think its increasing in projects with an onsite-offshore delivery model.
Mathew feels LUCK (no matter how small), does play a role ;)
....
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
I think the main reasons are:
- Poor/Inadequate Project Communications
- Ignoring Project Stakeholders
- Absence of Risk Management
- The project is not aligned with the business needs (what about the Project Charter?)
Regards
Lucca
The top reason per me is "Lack of Frozen Requirements", if the requirements are not frozen it will end up changing and will remain a moving target which will never be acheived causing the project to fail.
In my experience the number one reason for failure is poor requirements gathering and documentation of the requirements. I have found that it is critical to make sure that the project team and the sponsors agree on what the project is and just as importantly, what the project is not. Success criteria needs to be defined and agreed upon. This then allows chamge management to flow naturally into the project as we all know that change will happen which is fine so long as both sides know that its a change and the project has procedures in place to accomodate and document. Hmmm, seems like I'm adding documentation as a pretty strong #2 reason for failure.
That's rather evident. When the start of a project is bad; then it will be hard to deliver your project. The start of a project is the definition of the scope (incompletness) and the gathering of the requirements (incompletness and not detailed enough to be used as a document for monitoring your project as a PM)
In my experience, a main root cause of project failure to be delivered on time and on budget is failure of adequate procurement management. Simply, contracts are written with absence or inadequate clauses to enforce financial consequences for vendors who deliver late or defected products. Another major factor is unrealistic optimistic timelines based on political pressures or underestimates of the actual effort (time and tasks) required to complete a project.
Best regards, Mike
The number one reason lies in the WBS -- lack thereof, incomplete, useless WBS dictionary, no concurrence with OBS and responsibility matrix. SOOOO many projects don't even have one, let alone a GOOD one.... it is shocking!
Next, I would proffer another perspective: perhaps our thinking in terms of "#1 problems" leads us into false security. We PMs think -- I've addressed the big issue(s) that are the biggest causes of failure, so I am covered as best as possible -- but we need to think in terms of project planning and control mechanisms that allow a continuous review and perusal of the entire project's purview of efforts. So that connects to your #8 above, yet it is founded on the interrelationship of #1, #4, #5, #7.
Then I guess that actually makes it #9..... hmmmm
In my opinion, I believe no. 1 lack of stakeholder involvement/support and an unclear statement of work. Both the stakeholder and the developers need to truly understand what the project is supposed to deliver. Oftentimes, I find that people do not have the same understandings of that the project is actually going to accomplish.
Great debate!
Ussually when we talk about success or failure we are comparing our current situation with our initial estimations and we assume that estimations are the right references. From my point of view success, in a simplistic way, is measured with the difference between the contribution to the business of the project and the total cost of it.
When we use agile methologies or a rolling wave planning (progressive elaboration) we have less pressure from the initial and idealistic estimations and we have more pressure from the business goals.
All great comments. I agree with Angel. Biggest cause in my experience is failure due to doing the wrong project. Lack of business value results in the wrong projects getting the resources, & subconsciously, people recognize when they are wasting the company's time & resources. Even when you bring it in under budget & ahead of schedule, it's a failure, because it's not used.
To me, successful project = happy client. Project failure is a matter of perspective based on the project plan and expectatations. Perhaps creating/setting and managing both are the causes of a (perceived) failure. An organization's culture and past project experience will drive this perspective. Bottom line...it's how, what, when information is communicated to the stakeholders. Choosing one, I will go with '#4. Poor/Inadequate Project Communications'.
Not involving experienced resources (technical and functional) during early stages of project life cycle is one of the main reasons for project failure. It leads to poor requirement gathering, incorrect estimation (cost and schedule) and sets the stage for project failure
#1 reason for project failure = lack of understanding by ALL parties as to the definition of project sucess.
Many of these projects are large scale complex projects. People set a goal, budget, resources, schedule, requirements and than make a promise to Senior Management. The team often spends a lot of time and money trying to manage change from happening. On projects of this size, change is not necessarily bad, the business goals and environment are moving and should move. I think the failure occurs when a project does not recognize this and delivers something that is what was asked for/promised long ago and is no longer what is needed. This connects a bit with Angel/Ray's comments above on Agile and "doing the wrong project".
The top cause for project failure is bad or inadequate communication between significant parties. Good communication ropes every aspect of the project collectively creating a balance.
For most projects, 6+7+9 = Failure
In my industry (Aerospace/Defense), the #1 cause is ineffective management of suppliers/subcontractors.
#1. Lacking Sponsor's Involvement/Ownership
This includes inadequate funds
You are probably not in your 60’s or you would know this looks just like “The Peter Principle”. All ten are signs of incompetent management, even luck. The more incompetent the manger, the more un-lucky they become.
Complexity is the number one reason that projects fail to deliver. Particularly if that complexity is born of scope creep.
In my experience too many projects organically grow into programs and baselines become meaningless.
Poor Communication and Lack of Leadership
Poor Communication and Lack of Leadership
While I do not want to hi-jack the discussion, my curiosity is too much to hold back.
In your organizations, are these not the responsibilities of the Project Manager? Communication? Leadership? The Management of Risk or Scope?
While I do not want to hi-jack the discussion, my curiosity is too much to hold back.
In your organizations, are these not the responsibilities of the Project Manager? Communication? Leadership? The Management of Risk or Scope?
It is scope management coupled with poor stake holder engagement and communications start the seeding for project failures. Other issues like Pm methodlodlgy, incompetent team, and inadequately skilled PM senior leaders buy in etc will hasten the failure steps
Actually in our book, The Project Management Communications Bible, we quote a direct survey taken from a PMI Network Mag that states the #1 reason for project failure is project communications.
I still believe that is the case!
Hey Bill. I agree the single biggest is communication. Is the survey specific to the cause? Is it poor selection of PM, poor training of PM, the PM is gagged by upper management?
hi Bill
Can I have access to the Book and the survey . It helps . thanks in advance
Hey Michael, lots of good reasons. None on there though... :) Basically, the survey was done by PMI and published in the PMI net asking 1007 PM's what are the Top Reasons project's fail. The results came back with 9 answers, with the highest score being project communications.
Thanks to all for making this discussion a great learning and sharing experience. Mathew's noticed a lot of comments emphasizing the importance of Scope Defination and how Scope Creep should be kept away from the project. Mathew agrees, "the project should promise only what it can deliver & should deliver only what it promised." Nothing more or less.
You may find it worth your time to read a post about Scope Creep tilted "ARREST THAT SCOPE CREEP" @ PM4K @ http://anishmathaimathew.blogspot.com/2009/07/associated-content-arrest-that-scope.html
Cheers..looking forward for more..
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
@Michael: There are organizations that expect its PMs to be SUPER HEROS. Agreed a PM is responsible for everything in the project, but the question is, Should he be expected to specialize in everything? Bottom line: No matter how important the role of a PM, he/she alone cannot lead the project to success. Would you agree?
...
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
Mathew,
Super hero? No!
However, "management" is two hundred year old, professional science. Project Management, like Operations Management, is a sub-specialty of general management. Thirty years ago, when I started to work my way up the food chain, you had to master the basics of general management before you could try to master the Project Management.
Every thing on your list is "basic" management responsibility. Just read the works of Henri Fayol.
#1 + #4 +#7 I think are the top reasons of project failures, at least in the ones I know.
#5 and #7 are critical for a project success and generally are factors due to which projects fail. Though every other factor do play a role in project success and a project manager is suppose to do all of these.
Not performing any of these in totality is certainly planning for failure.
What is important to understand even despite performing all of the above you if miss out on stakeholder management or proper scope definition then the project develops issues which pushes it the project towards failure.
#5 and #7 are critical for a project success and generally are factors due to which projects fail. Though every other factor do play a role in project success and a project manager is suppose to do all of these.
Not performing any of these in totality is certainly planning for failure.
What is important to understand even despite performing all of the above you if miss out on stakeholder management or proper scope definition then the project develops issues which pushes it the project towards failure.
Business understanding (or appreciation) of the of the "Iron Triangle". They want it all now, on the cheap with every bell and whistle. And quality better be dead on.
No matter what the industry or the type of project, Sponsorship is the number 1 issue. At the same time, Sponsorship is largely assumed to be limited to the Executive who is signing the check-- but successful project implementation requires a network of "Reinforcing Sponsors" who are Expressing, Modeling, and Reinforcing desired behaviors. Most Sponsors don't understand that Sponsorship is an active condition and behaviorally based. And they don't understand the amount of time required to be a good Sponsor. There is absolutely no doubt that Sponsorship is the single most important factor in project implementation success. Here's an article:
http://www.imakenews.com/imaworldwide/e_article000935247.cfm
This is an interesting discussion. It's not clear to me that the "triple constraint" theory is still valid, or that the PMBOK is sufficient to guide a project/program manager in today's business environment. With respect to Mr. Ervick's comments, I would go so far as to assert that the business environment in which projects are managed -- particularly in the A&D industry -- has transformed to such an extent that the PM techniques that put a man on the moon are no longer sufficent to drive project success. To drive the point home, I would argue that the PM techniques that managed the design/build of the 737 are pretty much not applicable to managing the design/build of the 787 ... a "fact" that Boeing learned too late, to its detriment.
For those interested, I'd like to recommend "Reinventing Project Management" by Aaron Shenhar and Dav Dvir, Harvard Business School Press, 2007. It establishes the position that all projects are not the same, and that PM techniques need to be tailored for the project at hand, based on evaluating the following four attributes: novelty, technology, complexity, and pace. Shenhar's statements rang true for me.
Anish,
Wow a great question and one that should generate plenty of feedback!
I have worked on many projects in my time in the following sectors: Nuclear, Public Sector, Rail & Telecommunications.
They all have one thing in common: they have in place Project Management systems and processes and plan to succeed! However with all best intentions they usually ''fail'' to varying degrees.
You highlight perfectly the typical examples that are all to common and oft repeated.
I can cite an extreme example of a project failure:
There were seven state funded Research Bodies all running their own individual payroll, procurement, pensions & HR functions. A decision was made to combine these functions into a shared service (SSC). A company was created that would eventually take delivery of and manage this combined service.
The Research bodies were very reluctant to comply with a ''one size fits all'' arrangement. (There were research functions as diverse as Arts to Engineering and Environment to Social Sciences).So we had from the beginning poor Stakeholder ownership. Involvement was varied from truculant to compliant.
Then there was the Vendor Issue! Two high profile companies were involved in the database platform and desktop/back room hardware. There were twelve functional workstream leads in the Programme team. There was a Programme PMO. One vendor had its own PMO, the shared service company had a PMO.There were two lots of consultant firms embedded in the PMO and Programme workstreams. There was a layer of executive Programme Managers.
The programme as you can imagine suffered from scope creep or actually scope cuts to meet continuing slipping go-live dates.
The Programme PMO has had in 18 months had seven different PMO Managers.
There was poor co-operation between the different Programme entities. Nobody seemed to have overall authority and lack of accountability allowed the Programme to severely slip and go over over budget. The Programme Director eventually resigned closely followed within a month by the Programme Assistant Director.
This Programme is still ongoing and has survived since it is being paid for out of the public purse. It would have been culled last year if this had been a private sector Programme!
@Karl: Thanks for your comment and the great example. Guess in that case you'd agree that LUCK (no matter how small), does play a role ;)
....
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
Another discussion I recently saw on LinkedIn asked a question like: how did we manage to put a man on the moon 30 years ago, while today we can not produce proper software. For me this question shows the real reason for faillure. Most projects focus on producing a rocket (only focus on delivery). Successful projects however look further: why do we create a rocket? Because we want to go to the moon. If NASA would have only focussed on delivering rockets, they would never have reached the moon and probably had produced a great number of disasters while delivering or using those rockets.
A Business Case focus, rather than only a delivery focus!
(By the way & off topic: this delivery approach for me also caused the current financial crisis. Only focussing on the deal, not on the long term effects.)
All reasons summed up in the question above are in my view symptoms and results of the delivery-only approach rather than reasons.
Another discussion I recently saw on LinkedIn asked a question like: how did we manage to put a man on the moon 30 years ago, while today we can not produce proper software. For me this question shows the real reason for faillure. Most projects focus on producing a rocket (only focus on delivery). Successful projects however look further: why do we create a rocket? Because we want to go to the moon. If NASA would have only focussed on delivering rockets, they would never have reached the moon and probably had produced a great number of disasters while delivering or using those rockets.
A Business Case focus, rather than only a delivery focus!
(By the way & off topic: this delivery approach for me also caused the current financial crisis. Only focussing on the deal, not on the long term effects.)
All reasons summed up in the question above are in my view symptoms and results of the delivery-only approach rather than reasons.
I would say #7. Scope Creep/Unrealistic Expectations. All the others reasons are certainly strong source for failure but somehow most of them point to have a bad road map document.
This is why a Project Manager is so useful in any organization to make sure that we get the right project management plan, which include a concise and accurate project scope statement and "realistic" project expectations.
Based on over 20 years of project management experience, I would say item #1 to have the greatest impact. The lack of appropriate management buy in and sponsor support has in my experience, led to the largest failures on the projects I have been part of. If this structure is not solid and available for the project manager to resource when problems arise, it often leads to many of the other problems listed above (wrong people in the wrong roles, scope creep, etc.). A stong steering comittee and project sponsorship is key for success and can serve as a mechanism to assist the project manager with mitigating other issues that come up during the project planning and implementation process.
Poorly defined requirements, which can cause scope creep as you realize what was really wanted or required to make the thing work.
Scope creep, inadequate budgets with inadequate contingencies, ignoring potential risks, fickle stakeholders
Scope creep, inadequate budgets with inadequate contingencies, ignoring potential risks, fickle stakeholders
I work for a small company of less than 100 and I find lack of good time management programs and accurate projection. Another issue in small companies is the desire to meet an aggressive timeline on our part, but the slow signing of documents on the part of the customer. Creep begins to be a huge issue from the beginning in these situations.
With over 8 years of project experience in the private and public sectors, I would say that the biggest #1 cause of project failure is incorrect business requirements specification (BRS).
You may have the stakeholder buy-in, scope defined etc, but if the project has not performed a proper analysis phase right at the beginning of the execution stage with the milestone of a business requirements specification defined; no matter what you do, the end result of the project will not be done as to what the business wanted.
I have had the rare opportunity of always been given the kind of projects that have not been defined correctly, failing, running late etc, and the primary cause has been the above. No approved BRS.
I agree that all of these issues contribute to a projects failure. Number 1 is the tops, followed by lack of or bad project communications and risk management. If the top executives or stakeholders don't truly buy into, not only the project, but project management as a discipline, covering all of the other bases will get you nowhere.
#1. Every project has to be driven. The more compelling the purpose and the more committed the sponsor is to the project, the more weight can be bought to bear on the inevitable competing priorities and the clash of the operational and project worlds in the business.
Others have mentioned President Kennedy's historic project to land a man on the moon and safely return him to earth. Project Sponsors and Project Managers would do well to study his speeches in this regard.
The purpose and vision was made crystal clear
The priority was established and ranked alongside all other priorities
The cost (including the $ impact on all other Government budgets) was made explicit up front
Everyone knew where ‘the boss’ stood on priority conflicts!
The fly in the ointment is #4. I have found that Poor Communications consistently comes up in the root cause analysis as the underlying problem and inadequacy of Project Management.
I can easily provide examples for every one of the choices, but given the list you've provided, I would have to say it's been a combination of #1 and #7, which are typically the result of an aversion to the pains of reality. That viewpoint may be a result of my usual role of being hired as a troubleshooter for a failing/failed project.
In almost every case, it's been the result of a poorly planned project from the start, which inevitably leads to scope creep. And the reason the project(s) start off on the wrong foot is because the primary stakeholder handcuffed the original project manager with an inadequate budget, then tried to "force" the project plan to conform to that limitation. The root cause in almost every case? The stakeholder didn't have the guts to tell their superiors that the project was doomed from the start due to lack of funding, and unrealistic expectations. It's impossible to "gain" efficiencies when a project is kicked off with one foot in the grave...
I can easily provide examples for every one of the choices, but given the list you've provided, I would have to say it's been a combination of #1 and #7, which are typically the result of an aversion to the pains of reality. That viewpoint may be a result of my usual role of being hired as a troubleshooter for a failing/failed project.
In almost every case, it's been the result of a poorly planned project from the start, which inevitably leads to scope creep. And the reason the project(s) start off on the wrong foot is because the primary stakeholder handcuffed the original project manager with an inadequate budget, then tried to "force" the project plan to conform to that limitation. The root cause in almost every case? The stakeholder didn't have the guts to tell their superiors that the project was doomed from the start due to lack of funding, and unrealistic expectations. It's impossible to "gain" efficiencies when a project is kicked off with one foot in the grave...
It's a great list, and your #1 is, in my opinion, the correct #1.
One critical item is missing from the list, though: The lack of a shared "culture of project management" among all direct and indirect project stakeholders.
Without it, the project manager is constantly put in the position of (to borrow a phrase from George Burns) playing pool with a rope - of pushing important PM techniques into an organization than doesn't want them, sees no need for them, and considers them to be unnecessary bureaucracy.
You will get "practical" amount of support from the sponsor, rather in the real world you will never get 100% (perhaps from 50% to 70% support). However nothing excuse you from creating a deficient project scope statement or accepting unrealistic stakeholder expectations; if it is the case then you should say NO to the project.
I have to agree 100% with Robert Lewis' post about having a "shared culture of project management" within a given organization. I didn't want to sound cynical in my original post, but that TRULY is the root of the failure in the projects that I have "hired into" in my career. And in essence, is the reason that I may not elect to renew my PMP certification after 7 years.
I have been suckered into joining companies that proclaimed to the top of the highest mountains that they were looking for "change agents" - when in reality they only wanted more of the same-old-same-old. Many high level managers LOVE to hear themselves talk, but rarely listen when the harsh truth about a failed/failing project is professionally explained. These are the organizations that hire PM's and view them as a necessary evil, which, in turn, fosters a cultural aversion to project management practices. In the end, for the PM, attempting to deliver a project on schedule and under budget is the equivalent of... herding cats.
I agree with your #1 - without someone to champion the project, it doesn't get any priority. It also causes delays trying to get sign.offs. I think that #2 should be poorly defined requirements. If you do no deliver what was expected, the project is a failure.
Poorly defined requirements, and a total lack of anything that even vaguely looks like basic systems engineering.
Unclear Requirement is by far the most major cause of project failure.
Lack of buyin from various areas of the company, to include sponsors and project teams can kill any project.
First it is a breakdown in communications. Typically it's not technology or consultants. Poor communications leads to all of the above and a blame game.
Secondly, It has been a poor statement of work with vague deliverables.
I agree with your number #1. I have written an article on Engagement or Program Management that will be released soon. I'll share it with you once it is published.
From the various classes and talks on the subject, as well as an online poll I did - the feedback I keep receiving is Requirements Definition as the number 1 reason. Poor, unclear, questionable requirements. Set yourself up for poor objectives and requirements and you are bound to fail. Now with that being said - communications issues are a very close second.
What a great topic! I love this topic. For more troubled project fun - feel free to join in on the group Troubled Projects - Rescue My Project.
Lets just see what kind of trouble we can identify with!
Brian
The number one issue for project failure is the lack of effective management by the project manager. This can be due to the project manager not being provided the appropriate authority within the organization to execute effectively or a lack of experience or competency in areas of leadership, project methodologies or technical knowledge. Deficient specifications, ineffective communication and many of the other items on the list are symptoms of the underlying cause for the projects failure. Ask yourself this question, if a project manager has the appropriate authority, technical competency and leadership skills should any of the items on the list become issues? One of the key competencies that need to be developed in any project manager is the assessment of the required level of authority to execute the project and the skills and credibility to negotiate that authority with the Senior Management of the sponsoring entity. If the project manager has the skills and the appropriate authority to obtain manage and direct the required resources the accountablity clearly lies with us as the project managers for the failure or success of the project. The list above simply states the things we were unable to accomplish. Luck may have some impact on certain types of projects as in weather related issues or catastrophes in most projects it is a hard sell as a reason for failure.
As Terrie pointed, ineffective or lack of communication is # 1 cause for project failure
@Brian: Mathew's noticed a lot of comments emphasizing the importance of Scope Defination and how Scope Creep should be kept away from the project. Mathew agrees, "the project should promise only what it can deliver & should deliver only what it promised." Nothing more or less.
You may find it worth your time to read a post about Scope Creep tilted "ARREST THAT SCOPE CREEP" @ PM4K @ http://anishmathaimathew.blogspot.com/2009/07/associated-content-arrest-that-scope.html
Cheers..looking forward for more..
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
I think it is definitely lack of requirements usually due to lack of sponsor involvement or lack of sponsor understanding. While it is true that the project manager can and should be able to address these issues, some seem to be beyond fixing.
What Dennis (Rick:) described regarding authority is one of the very basic reasons why projects fail and because of lack of all those mentioned "if"s.
To me the top common failure is senior management´s lack of understanding of differences between business as usual and project management! Senior management lack of fundamental idea of what they want from a project and where they usually think short term benefits. Senior management create and force an apparently agreed objective and scope with
a) too much business way of thinking and not project oriented thinking
b) rushing too fast with a charter lacking very much basic points
c) involving the project manager too late,
d) not givingin the right match between mandate & authority
e) usually not focusing neither respecting identified risks nor assumptions
f) involving their personal or position interests/politics too much in the project!
But of course at the end of the road the skilled project manager with right project management practice is an assumption to not fail:)
I think it depends on the type of project. However, lack of true and meaningful Client team involvement is in my experience often the #1 reason for project failure. Not only in the project implementation, but in the crucial period when the project is complete and its benefits need to be realised (whether they are rental yields from a building, a new plane being successfully sold to airlines or a new hospital managing to improve treatment of patients in the region).
I think it depends on the type of project you're working on as well. My primary experience (12 years worth) is in IT and software development projects. Coming at it from that perspective, I'd say a combination of poor requirements definition and/or unrealistic expectations and scope creep are the #1 cause of project failure. Somewhere within progressive elaboration of existing requirements the scope seems to inevitably start to creep beyond what was agreed to. A tight integrated change control process can really help to mitigate the problem so lack of a project management methodology exacerbates the problem.
A health dose of good luck doesn't hurt either.
I think "scope creep" is a cop-out. In other words, if you have a sound scope management process, and something get pulled in, then you're not following your own process. Or if you don't have a process, well, then enough said.
In my experience, projects fail because the requirements are not sound from the beginning - marketing, clients, etc. think they know what they want, but until something is prototyped, they don't *really* know and so it's a lot of discovery. However, no business mgr I know wants to allow for an unquantifiable "discovery" factor (risk) so the schedule and budget get set without that factor and then the "unknown unknowns" pop up and nobody wants to allow for it (they claim scope creep!).
So the second part of project failure is all around risk. I think conceptually it's an easy process to understand, but I've not seen any business unit actually embrace risk management and use it proactively to assess project health.
I really appreciated all the expert's comments so far and based in my experience I would add as the most relevant factor for projects failures is the lack of proper and consistent communications in all levels. If the PM and project team creates, defines and adhere to a consistent project communication's plan, most of the hidden issues will be minimized and chances for success increases.
Scope control/integrated change control are the keys to controlling 'scope creep.' Discovery is supposed to take place during requirements elicitation/definition, however; progressive elaboration of the requirements also take place during the project life cycle. The project manager must have the authority to enforce integrated change control and bring all the stakeholders together to a) assess the risk and impact to the project budget and schedule b) make a conscious decision to live with that impact. I won't say it never happens but I will say I've seen project managers overridden more times that I've seen them supported when they want to move timelines or expand budgets.
Senior management's answer at this point (having already set the timeline and budget and not properly assessed the risk) is to 'throw more bodies at it.' In many of the cases I've been involved with that solution actually hinders completion. And these were organizations with mature project management processes and established PMOs.
Definitely number #4. I don't know how many times in my career I've seen, and you pick it, bad, poor, wrong, innappropriate, inadequate, and/or minimal communication in any form. And this isn't just limited to verbal and written. It also goes to the developed, or lack thereof, PMP for said project. No Comm Plan, no Risk Mgt Plan? Not a good situation. A book I have used in training and provide copies of is Verbal Judo as primer. It is an excellent book, and easy read, to establish a solid baseline of what good communication is and how to get outside the box when dealing with challenging individuals.
Poor project manager!
The rest can be managed and documented.
#5 , Missing /ignoring stakeholders. At least my experience as PM has been so.
1. Poor requirements management
2. Poor program management baseline management (includes EVMS, Risk Mgt, weekly schedule compliance management)
3. Inadequate flexibility to customer needs
4. Not understanding the customer
Definitely requirements management...the more frequent issues were either (1) we as IT folks didn't understand what the customer was looking for (2) or the customer kept requesting changes or additions to scope.
top #1 cause of a project failure is
#4. Poor/Inadequate Project Communications
cheers
neeraj
#4: It all boils down to one thing - communication. The mis-firing of communications is the crux of all problems in and around our projects.
In-Experienced Project Manager (worse if he/she has no formal Project Management methodology self study or training).
Completely agree with Mark Parrish...All other factors are easily manged/corrected if there is strong push from Project Manager. I've seen project where requirements gathering and project communications are poor but still project is successful.
The whole project thing revolves around Project Manager.
In my experience I would rate top 10 reasons for inefficiencies in the project and ultimately leading to a project failure as follows...
1) Lack of communication ( people working in silos, left hand doesn't know what is the right hand doing)
2) Explicit Project Scope statement and WBS structure.
3) Lack of the involvement of project team from very beginning.
4) Non availability of a proper responsibility matrix and a RACI chart.
5) Lack of Management support
6) Lack of a comprehensive Project Management Plan.
7) Team members being drifted from original scope of work and wasting time in activities which are not in scope.
8) In efficient Project change control system
9) Lack of project controls...cost and schedule reporting ( try EVM, its really effective).
10) Customer involvement and keeping abreast of changes and progress all along the project path.
This list can be elaborated further but the above are the important 10 reasons which a project manager should take care off from the early stages of project planning.
Cheers
Neeraj
I agree with the buddies who say ‘Lack of communication’ and ‘Project Manager’. Even when you have everything in line, if things are not communicated effectively nothing is achieved and one person who can maintain productive communication among all project stake holders is PM.
I cast my vote for #4, communication.
I cast my vote on the communication issue -- particularly, a lack of communication re what is the goal of the project and a clear definition of scope. Everything else flows downhill from there.
I've managed hundreds of millions of dollars of construction projects and find that the more detailed my planning and the more I encourage team engagement in following the plan, the more successful it is. Planning, very detailed planning, is evrything.
Now having a plan is wonderful, it holds the promise of removing most of the wasted time, improves quality and safety and builds client confidence BUT unless you are on top of implementing that plan it is only wallpaper.
I follow much of what the Lean Construction Institude teaches, with my own slant.
In the end, plan, plan, plan, plan, act AND work hard on improving employee engagement in taking ownership of the plan.
Today I can honestly say that I do not deliver late, over budget or with safety or environmental issues. It just doesn't happen. And the cotnractors and their employees love working with me because they enjoy a well-ran ship too - and it reflects in their bids to me.
I like all lthe responses. I think that depending on the project, I've seen several of these take a project down almost singlehandedly. BUT, a lot of these can be prevented with great project communications and stakeholder management.
IMHO,
Effectiveness in two areas which can make a difference b/w success and failure
a. Communication
b. Conflict resolution
Hi,
In my opinion, following are the reasons for project failures :
# 1 : Project Deadlines fixed before Scope Finalisation
# 2 : Poor or Insufficient Requirements Gathering/Definition
# 3 : Expectation mismatch between Stakeholders
# 4 : Weak sponsorship at High Level
# 5 : Lack of Key People involvement in the Project
Murali.
#1 Communication
#2 Understanding of Group Dynamics
1. Failure to Follow the Plan - beginning with "Initate" and by the time we have a project plan we have made serious generalities. But when we maintain the plan in place and retain the accountability elements, it should address the other common problems.
A great deal of emphasis is placed on having a plan but too often we do not use it in critical areas.
Jim is right. Most plans are wallpaper. They look like the team has a plan, but they're mostly eye candy. Primavera charts are the most common wallpaper in trailers.
If on any given day you do not know exactly where you are with the plan (schedule, budget, long lead items, etc.) then you are off plan.
I hold daily work plan sessions that last about fifteen minutes - tops. It is obvious to everyone present whether we are meeting plan or not and what to do about it to correct it.
As for the complaints about owners unrealistic expectations or deadlines being set before scope completion, I don't get it. First, the client is never to blame for the contractor taking a job and not meeting expectations. Second, we do projects all the time where the first thing that is known is when the thing must be done - even before design. Opening day is opening day. You have to generate a plan that meets that date.
I built a baseball stadium in 2001 that sold tickets in advance of plan completion. We committed to the date before seeing the plans. We built the thing is 10 months, were $300M (M is thousand) and enjoyed a great season opener with the entire team in attendance. No issues.
Last April I was given a $20MM project by a steel mill under the one condition - that it had to be done in three months. No one else would make that commitment. The plans were actually completed a month after we were done. The dang engineers were a bunch of primadonnas and just didn't get the clients urgency, nor were they equipped for design-build. It was on time, all worked great and was $2MM under budget.
You have to drive. What Lean teaches is to pull, not push. It's a departure from the normal task-driven thinking, but you have to compress the schedule within the constraints. The good news is that with all that efficiency you gain much larger margins, do things once, and have far fewer safety issues.
We're at 3MM man-hours without a recordable.
@Jim-@Brice: Mathew agrees with you. Many times plans are created just for namesake. A lot of times Planning is considered more important that Execution itself. Its true that "If we fail to plan, we plan to fail", having said that, "Effective Execution of a Good Plan" is equally (if not more) important for project success. In short, a plan is only as good as its execution.
Cheers..looking forward for more..
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
I would vote for
1. making wrong assumptions by the management team including PM
2. lack of good project team (extra milers)
In my experience, the number 1 reason for a project failure is a lack of well defined/precise project business objectives.
Everything else follows
#4. Poor/Inadequate Project Communications
Poor or inadequate project communication is the most common reason for project failure. Mind you that could be not communicating or doing so poorly with a steering committee, with a project team, etc. I also believe that the poor communicator doesn't necessarily have to be the PM; it could be communication between two other stakeholders - but it's up to the PM to recognize the situation, and taking action to solve the problem.
I second Michael Corcoran's post - poorly defined specifications allow for incorrect expectations from the beginning - and projects drag on trying to reconcile "expectations" with what was paid for.
Communication is critical to define ramifications of changes in scope. Clients often change their minds during the project, demand the changes, but do not fully understand the results of those changes to the rest of the project. This is PM's most important role - the explanations all the way through.
Dissension in the ranks or Team.........due to lack of communication on the Core side and interaction/building on the Team side
Lack of communication between project manager, Stake holders and end users.
I am going to disagree and agree with all of you as I think that overall it is none of the above but all of the above are sometimes relevant.
The most common reason for project failure is that the project management methodology and the governance that manages it, is in the business environment or corporate culture that is failing.
It is possible to follow governance and for the project to fail. Yes there are poor project managers and yes communication with stakeholders is vital and yes to the whole of the list but the real problem is that the modern project management methodology fails to take account of the corrupt culture in business and the fact that business science is still 20 years out of date.
It is all about the structure of power over governance in most major corporations. As a senior executive in a major corporate you can ignore governance.
Most major companies do not operate risk management processes properly and I would also say the management of project finance is a core issue as well. Businesses do not understand the cost impacts of customer experience staff attrition brand devaluation and a host of other costs that should be part of the risk assessment.
The Customer Experience Foundation is doing a detailed study on this at the moment. Please follow the link and take part as you will get a copy of the results.
Is it just the extra project cost or the late arrival of business
benefits?
Is it the cost of unhappy customers or stressed out staff?
How often does it happen and how much does it cost?
How many new technology projects fail completely?
This is the largest survey of its kind ever undertaken and it takes 5 - 8 minutes to complete. By taking part you will get a free copy of a report worth £150.00, and the chance to win an IPod or a choice of a bottle of champagne or chocolates.
Follow this link to take part:
http://www.surveymonkey.com/s.aspx?sm=jnS82pjZik6rJesYrSkUoQ_3d_3d
Something I have noticed, that I would like to add to this list (which is also part of a couple of responses), is motivation: that failure (or success) is strongly influenced or impacted by the motivation of the organization or sponsor to actually get it done. The project can be defined well, planned, communicated, and so forth, but if the participants are not motivated, or have a sense of urgency, then there is a tendency for the project to stall and/or eventually fail. This applies to the business sponsor down to the folks actually doing the work. Many things come into play here revolving around culture, politics and capability gaps that could take this thread in many new directions.
So, in the success stories listed in the thread, I expect they were motivation and had a sense of urgency. I would also expect the failure notes lacked them.
I got to facilitate about 30 Lesson Learned sessions for a fortune 100 company. If you do the root cause analysis down to the very base problem you run across the same root issue about 85% of the time. That is most issues start with not having the right skilled person at the right time working on the right task. The other 15% of the root issues are normally some sort of vendor issue. I have worked on the vendor side of the implementation equation also. When you do their lessons learned for the vendor their matrix sorts out the same way…about 85 % of the time it is not having the right person with the right skill working on the right task at the right time and the other 15% are their vendor issues.
So the answer is #3. Poor HR Management. All other issues are just symptoms of that basic issue.
My advice is pay close attention to your resource mix and don’t hesitate to ask for support in areas that are weak or missing skills. Good luck to ya
1) reason for a project failure is acceptance of a project with a lack of well defined/precise project requirements, scoping etc.
In my experience its all about the scope! If the scope is not complete and there is a lot of loop holes it definitely causes the project to fail. I am learning and have learned as a project manager to understand the scope in and out and even rewrite it to be more precise and it really keeps the project team accountable and it meets the client expectations. We are starting to implement SDLC in our company, what are some of your thoughts on that?
My experience:
#4. Poor/Inadequate Project Communications coupled with inadequate stakeholder identification/management
Okay, SDLC as I understand it is used in software development. Are you applying it to construction? How?
I'm kind of amazed that there are many responses blaming the owner. Most of the time all the owner knows is that they need the project, that's why they hire us, the problem solvers. High functioning PM's solve problems. For sure we don't blame the client.
Having said this, the trend-du-jour is bargain-hunting for design professionals. The AIA for sure has attempted to get ahead of this with marketing the value of good architects, but in the end, owners are not convinced that designers are worth the bucks they command, so they simply go cheap and heave the balance of incomplete work into the contractor. This decision has a ten-fold negative effect on cost, but they do it anyway. Again, we solve the problems.
Regarding the root cause comments and others it's planning and employee engagement. We've covered planning, so put this under your hat; Gallop did a wide-spread poll and found that 50% of employees were not engaged in their work, 25% were actively disengaged and 25% engaged. The actively disengaged can be culled from the heard. They're working at not working. The 50% not engaged are waiting for us to tell them what to do and maybe even how.
Be omnipresent. Hold your team accountable for their commitments to the plan and pull everyone through, not push them through.
As for vendors, again the PM should have been on them counting the cards. Of course they will tell you what you want to hear. That's their job. They lie. Go look. Say show me.
Okay, have a great day.
By far the reason most projects fail is due to the fact that requirements are not well understood, documented or planned for. There is always time to do it over but never enough time to do it right the first time.
Okay. I'll go with you. There are too many PM's that are not qualified to do the work, too many companies bargain-hunting for managers, the false reliance on having a BS degree vs. actual experience as the driver for hiring, inadequate documentation of everything (he who takes the best notes wins) or (I can't tell you how many meetings I've been to where nobody was taking notes and no one reviewed my minutes) and finally nobody is planning for anything except how to blame someone else or redo work.
Well, almost nobody.
One thing is for sure, this depression is going to shake a lot of people out of the business that probably shouldn't have been in the first place.
I would say "Lack of Diligence." Several examples include poor requirements, not staying on top of issues/risks, not assessing impacts of changes, not testing properly, not phase gating work.
PMs need to stay rigorous in all aspects of the project for it to be successful.
My 2 cents from the IT/telcom world - Missing or incomplete requirements, as well as, lack of user input are at the top of the list.
Next, strong executive support - DO NOT take a project without strong and explicit executive support. If it important enough for the VP, they will gladly spend 20 minutes reiterating their support to you personally as the PM. Job number on a project is understanding WHY are we doing and the VP will gladly explain the reason and the financial goal that is associated. I have seen more careers damaged by taking on their managers pet projects that did not have strong executive support. And get the requirements down correctly => build the WBS/dictionary completely => get buy-in they will meet the business objectives => do just the requirements.
Standish Group is the gold standard; the most widely followed.
How to nicely take exception to scope shift/frozen requirements... ALL projects have some requirement shift. All change requests get documented, some get analyzed for project impacts (all AOK will be impacted) and ALL changes are approved by the project sponsor or don't do them. Keep them on the documentation. Invite the requester to meet with the sponsor and join them. Answer questions, involve SME as needed. It is not your battle to approve/request changes, you are the PM not the sponsor. Last, if needed kill the project and start over if the scope has changed too much for the approved design.
The businesses we work in are changing faster ever day, to freeze requirements is a great disservice to our enterprises. Build good flexible designs, anticipate change, or you will be doomed to hit the target, yesterdays target and not tomorrow's. See best buggy whips. A strong PM methodology will have rigorous change management processes for changing requirements and approvals... and delighted customers.
-stepping off soap box-
My experience list three reasons and in this order:
1. lack of senior management sponsorship
2. unclear scope
3. unclear roles and responsibility
I would go so far as to say that if any one of these are present in your project the probability of failure becomes exponential. I think these are problems that you do not recovery from very easily. Many other problems can be fixed it you have these areas covered.
My opinion is that up front understanding of what is important and needed for this particular type of project in this particular environment is critical to preventing failure. Jordan Kuperschmid correctly points out that change is to be expected in large IT projects, but how about building a tall office building. After construction is underway on a 10 story building, adding extra stories would not be possible because the foundation and lower parts of the building would not support the extra weight.
How about understanding the customer expectations - not only the one who pays for the project, but the politically powerful individuals or the ones who might sabotage the project. After mergers, acquisitions and major reorganizations I have seen dysfunctional organizations who still hated each other several years after the project was completed. Cost, schedule and requirements of migrating one organization into another were all very successful, but the project was a failure because it did not deliver the desired results. In these instances excellent (organizational) change management practices should have been the critical factor.
Whatever is a common cause of failure of the project(s) your are currently managing may not be a factor in the next project you manage. Unless you take time on that next project to determine what are the critical success factors, you may screw that project up by continuing to manage your previous project rather than your changing to meet the new conditions.
The successful project manager brings both leadership and management to their project. A combination of doing the right things, and of doing things right. Might failure commonly be due to the PM not recognizing what was critical to their new project?
Ok, I know we are all great, but how about inexperience, lack of skill, or the poor execution of a good plan? does that ever happen? Hard to say.
If let me to choose, I will choose No. 7 Scope Creep/Unrealistic Expectations
This is the major cause of project failure, ( delay, over budget, customer esclation etc) in China according to my experience. In Telecommunication domain, China's customer usually has unrelistic expectations and it's really hard to "freeze" the requirments. Sometimes customer don't really understand what he/she needs.
No. 9
I would suggest the #1 reason is a lack of alignment with company priorities and vision. Once aligned the resources and committment for success follows.
@Rebecca: Mathew agrees with you. A lot of times Planning is considered more important that Execution itself. Its true that "If we fail to plan, we plan to fail", having said that, (as highlighted by you) "Effective Execution of a Good Plan" is equally (if not more) important for project success.
Cheers..looking forward for more..
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
oversealous project schedules stretch projects into failure. the question is what causes a PM to be overzealous? Lack of experience ,shortfall in full risk assessment and resource management
Consider the answer to Oliver F. Lehman’s question 29 available at http://www.oliverlehmann.com/contents/free-downloads/175_PMP_Sample_Questions.pdf :
“Projects frequently do not meet customer expectations from which of the following reasons?”
The answer with reference to H. Kerzner, Project Management, A Systems Approach to Planning, Scheduling and Controlling, 8th Edition, Page 66 surprised me – It’s:
“Technical inability and poor risk management by the contractor”
The answer is interesting in the context of the following link: http://en.wikipedia.org/wiki/Critical_Chain_Project_Management
“for traditional project management methods, only 44% of projects typically finish on time, projects usually complete at 222% of the duration originally planned, 189% of the original budgeted cost, 70% of projects fall short of their planned scope (technical content delivered), and 30% are cancelled before completion”
… my first post.
I've been working for IT solution provider companies from some years, managing small-middle sized IT projects. The most familiar causes of failure are in my opinion:
#1 Scope creep and lack of change control
#2 Lack of sponsorship and stakeholder involvement
#3 Unrealistic schedules and costs
I may say that IT projects, at least in Spain, are difficult to fit inside the PMP methodology. Restrictions on time and cost are often hurdles that forces estimations to be wrong evaluated. The project team is often contracted or assigned to tasks not according to their professional profile.
I've experienced also lacks on comunication and expectative management that leads to a poorly defined scope, scope creep and general disagreement about the results of the project...
In my opinion scope / expectative management is the key stone, I agree with Zhiguo Yang.
In my opinion major cause of project failure is 'loosing sight' on why are we doing this project and what need to be done on this project. Of course, planning is the key to start with.
I agree with most comments. To add simply projects that are not part of the core objective will fail regardless of whether they are delivered on time or within budget. Lack of WBS and assignment of responsabilities is a major issue as well. However; from my experience a lack of ownership from either sponsor, PM or major stakeholder will always deliver failure.
1- Poor specifications (including acceptance criteria)
2- Poor communication (inside the project and with stakeholders)
3- Poor project/program control (on budget, scope and planning)
All great comments, should I summarize ?
#1 Doing the wrong project, or a project that does not fit with the strategy
#2 Lacking in Stakeholders Involvement & Communications (sponsor, decision makers, final users, team members, functional managers...)
#3 Poor requirements gathering
#4 Poor change control management
I want just to add one thing about changes to comment Tarun's idea about frozen requirements. Changes are not necessarily bad things!
Of course, changes MUST be documented, evaluated, authorized and integrated to project baselines (if approved), but a change can be very beneficial for the project (example : corrective actions, new requirements to address a real important business need that we were not able to define in first project phases…).
In brief, changes themselves are not the problem, the real problem is in the manner in which we address changes.
I think this issue deserves a topic, I’ll think about it.
Regards.
1-Scope Creep/Unrealistic Expectations
2-Poor Communication (Not getting the right people involoved at the right time)
All great comments...however, it seems as though I'm still looking for a perfect project, and all the things mentioned thus far have played a role in projects I've led, including the one I'm currently leading. Stakeholder involvement, good requirements, supporting business objectives and strategy are all contributors to a successful project. In the end game, however, it's up to project professionals, such as ourselves, to position every project for the best possible opportunity for success. Therefore, we take sound bites, such as those offered in this thread, and slide them into our personal PMBOKs for use on our projects.
I venture to the wild side, a digression, to add that I believe another reason for project failure is the project manager's inability to assess the project situation and take the right corrective action.
David
To David's "venture to the wild side", I say AMEN - so be it.
With failed projects too much is said about what went wrong (who or what can I blame)!!!
Would what I failed to do to prevent (or correct) failure be better communication?
Don
Lack of planning. Going from idea to implementation without mapping anything out.
Sue
All 10 are excellent reasosns for project failure.
In my experience, the inability to coral the funding (based on a sound business case) and well-articulated ROI (including TCO) is at or near the top for why projects fail.
I should point out that Frederick Brooks, Jr., writes in "The Mythical Man-Month" (20th Anniversary Edition): "More software projects have gone awry for lack of calendar time than for all other causes combined." Brooks also is renown for his statement: "Adding manpower to a late software project makes it later."
Ed-
in my experience it is #1. Lacking Sponsor's Involvement/Ownership = without motivation nothing can be accomplished ... a team small or large, in a project complex or simple, will simply stop working (or even quit!) if no one is available to give feedback...
#7. Scope Creep/Unrealistic Expectations is more a reason for exceeding the budget but with a team sufficiently capable it shouldn't cause overall failure. which opens the question: what do you consider failure?
I would say the biggest reason why website development projects fail, large or small, is 'content' (database format - copy - imagery) not being thought through, understood, structured and/or provided by the customer at the right time.
In many cases you are simply not able to mitigate the risk as clients do not have the budget or the time to undertake what is a huge task. A task which is fundimental to the success of any web project in almost every area.
Can you really bite the hand that feeds you?
My top three reasons for project failure are:
1. Lack of project champion. No support from the top = no one cares
2. Oversold expectations. Sales guys over promised, but technical delivery cannot meet client expectations (this also goes along with poor requirements)
3. Poor/weak project managers/teams who do not communicate well and do not take ownership of the issues.
The projects I have seen fail all had these three issues in some shape or another. As PMs, I think our main goal is to:
1. Get stakeholder buy in
2. Set realistic expectations (built in planning, risk, outputs areas)
3. Communicate, communicate, communicate
Without these, your project may end up being shelved I think. I have seen it happen a lot.
Regards,
Brent
I am compelled to agree with James Solits' comments regards being suckered into joining organizations ostensibly looking for "Change Agents," which could not be farther from the truth. Herding cats or pushing on a rope is practiced not only within the realm of project management where it has reached a high degree of "perfection;" it is also rampant in not-for-profit organizations. Can you imagine my surprise at being hired by a not-for-profit quasi-state organization and thinking all was well, when I was terminated only to discover that I was the fourth CIO the organization had in less than three years? The executives did not want a Change Agent but a rubber stamp person.
Great topic! From my experience, I would agree with Alexandro on #7 with Scope Creep and with Beth on #1 with the Lacking of Upper Management Ownership, which causes #4 Poor Communication that Gary points out. Many times, we Engineers are instructed by upper management to just get started, and we will define requirements later, leading to assumptions, not communication, to just "get r done". Is that not a recipe for disaster or what?
I love the feedback this question has generated.
All the items on the list contribute to failed projects. I would add one more. As the saying goes..."Failing to plan is planning to fail". I've been involved in project management for 18 years, and many of the items on the list occur because of an inadequate plan and/or breakdowns in communication.
Keeping all stakeholders, sponsors and team members engaged and on the same page is one of the key roles of the PM. Communicating a clear, concise plan that addresses and overcomes poor expectations, requirements and results can many times be the difference between a failed and successful project.
If necessary, the PM has to have the confidence to step up and explain why the expectations as currently defined will fail, and clearly present a project plan that will lead to a successful project.
I do agree with all the feedbacks, but I would like to add one more issue:
1. PM´s that don't know how much important is the involvement of his team (experts) during the project management activities.
One of the lessons I´ve learnt is that when you involve your team during the planning activies, your plan become more real. Additionally, at the same time you get more commitment of your team.
Regards,
Ben-Hur Chavarria de Souza
Absolutely with Alexandro and Aiden on scope creep (Note: I'm sure it is not an 'A' thing...just happened that all our names started with 'A' :>)
The PMs role is definitely a gate keeper to ensure that requirements get locked down early on. Some flexibility is required to evaluate change requests and a proper change management process goes a long way to ensure that change requests get the proper attention and approvals to be considered of inclusion. The PM needs to be a skilled negotiator to be able to guide the process and to help to push out non essential changes to the next phase.
I must be lucky enough to have overcome most of the others because I often see around me that project fail due to poorly thought through (not getting enough detail, understanding the implications or not "walked through") and documented requirements (vague, assuming details...).
Thanks to all for making this discussion a great learning and sharing experience. Mathew's noticed a lot of comments emphasizing the importance of Scope Defination and how Scope Creep should be kept away from the project. Mathew agrees, "the project should promise only what it can deliver & should deliver only what it promised." Nothing more or less.
You may find it worth your time to read a post about Scope Creep tilted "ARREST THAT SCOPE CREEP" @ PM4K @ http://anishmathaimathew.blogspot.com/2009/07/associated-content-arrest-that-scope.html
Cheers..looking forward for more..
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
I think all this reasons can kill any project but the most important two are
#7. Scope Creep/Unrealistic Expectations
#8. Lack of Monitoring of Plan
I agree with James and Robert. Culture is key.
If you take out the human element of all projects and let a computer run the the show - chances are it would run smoothly. Because, in principle PM structures, techniques and methodology all make perfect sense - it's all logical thinking.
The fly in the ointment is us and our 'culture, personalities and characteristics'
I have used PM's from all over the globe and they all have different traits and nuances that can make or break a project.
Encouragement is a big thing in our company. If a project is over budget, over schedule or the scope is creeping then we talk about it and work out how to A) fix it and B) stop it in the future.
The holy grail of a perfect 100% project completion is unattainable because we are all just human beings with flaws and imperfections. Not computers.
I would rate "#7. Scope Creep/Unrealistic Expectations " highest in this context. Having said so I do agree that other reasons are significant cotributer for induvidual projects. However I feel Scope creep is side effect of most of the reasons enlisted here.
Most of my project experience which involved people from various geographical & cultural background suggest that we easily makeup for the distance in culture and time zone as we conciously strive to do so. In case of project failure I see Scope Creep as most important contributor no matter whether it is for Halo effect, Poor Planning, Cultural differences, too many vendors(stake holders) or for some other reasons.
I am yet to come across a project with clear:
- User Expectation
- Business Value &
- Uniform Requirement Understanding amongs stakeholders
and has still failed.
Thanks Mathew for bring up this interesting topic.
-Suresh
These are all good comments, and I am certain very well intended. However, there is another thought also. In early June, I wrote an article and published it via newsletter and LinkedIn on the same subject, but a different viewpoint. It generated quite a bit of comments and discussion. Here is an excerpt from that article, that summarizes what myself and others think the answer really is.
"First, most are authored by Project and Program Managers, and not by Business Sponsors, Management personnel in general or the C Level Executives that are primarily responsible for the health and well being of their company. Now many would likely say that to get a good list of reasons why projects fail, go to the same people that are managing those Projects and Programs. Seems like a pretty good idea. However, there is one thing primarily wrong with that scenario. It is very much akin to asking a Doctor to ‘Heal Thyself’. Usually doesn’t work out to well on the diagnosis side, and certainly leaves a lot to be desired for the cure or solution.
Secondly, the other trait – which is the main theme here today – is virtually non-existent on any of these lists, and it is this simple truth.
Most projects fail, because the Project Manager either cannot or does not Execute effectively."
Now, this does not mean that we have a large number of people performing the PM function that are not capable or poorly trained, it means something different. In general, it usually means that our PM Practices are no longer practical, and cause quite a bit of problems for those of us left trying to execute them.
The entire article is available at:
http://www.johnastrello.com/?p=9
The 'main' discussion area on LinkedIn (which contains many, many comments) is at:
things go wrong...lol.
Ok that was a joke, John you bring up an outstanding point, to sum it up "accountability" at what point did we as project managers not take the accountability to ensure all of the listed items above happened when they should have? At the end of the day the buck stops with us. Success or failure depends mostly on how well we did/do our jobs.
I would like to chime in here and defend scope creep as a problem. I believe it is an opportunity! Scope creep can be managed into contract amendments, iterative and process-driven deliverables, and project extended phases. When a stakeholder is in the candy store choosing, and the money is finite, you offer some candy now, and high incentive to come back next week with next week's allowance money.
Ultimately, I can only blame myself for failed projects (though there have been only one or two in my 25+ year career! However, as a PM working across enterprise lines, I do find that I have to beg for team members' time. If a network manager has 50% business as usual work, he or she will often view the other 50% allocated to project work as risk -- and reduce the FTE's assigned to less than 20% based on anticipated operational emergency situations. My takeaway on this is that project schedules require far more built-in slack, to accommodate a thinner workforce. Adding appropriate slack to a project schedule, based on real-world FTE availability, drives the project costs up considerably, and lands the PM as prey in a duck-shoot contest. It's tough all over and no, the answer is not outsourcing.
To those of you who consider poorly defined requirements to be the problem:
If by "poorly defined requirements" you mean the lack of a shared understanding of what success will look and feel like, I couldn't agree more. And in fact, we encourage clients to define both project completion and project success as different subjects with different criteria.
If, on the other hand, you mean loose specifications that don't precisely define the work products to be created, I'd have to challenge this, at least in the software domain.
From a formalistic perspective (simplistically put): Project management is about making sure everyone knows what the tasks are, who should work on them, when they should start, and when they are due.
The development methodology is what determines what those steps should be, and not all development methodologies call for complete specifications prior to construction.
The methodologies that do call for this are called "waterfall methodologies," and most of us in the trade have concluded they don't work very well. By now it's well-understood that what works better are iterative, incremental approaches in which the specs emerge, a bit at a time, as business users and IT developers figure out together what's needed and how to build it.
I've found that the team's not thoroughly and clearly understanding the sponsor's and stakeholder's primary goal and true needs at the start leads to most project mishaps. This of course leads to poorly defined requirements and mismanaged expectations.
Since there is no such thing as bad luck or fate, #10 is right out.
It would seem prudent to define failure here. We hear, ad nauseam, quotes and mis-quotes on the percentage of projects that fail, 40, 50, 60, 70, 80 percent etc. What exactly does failure mean in this context? If we are talking total cancelation of the project, then more than likely the root cause is not a singular issue but is a combination of issues and interdependencies working to a cascade.
If a project is based on a legitimate business need, then it can not in fact fail since the solution has to be somehow implemented. It may run over, take much longer or even be supplanted by a different solution, but the goal must eventually be met in some form as part of the business plan.
Everything listed seems to be "contributory causes" and I do not believe any individual item, even the project manager or SME can be an overall single point of failure.
If replacing the PM, project team or suspending work meets the definition of failure then these things may be indeed be a cause.
What I do not see and believe are direct single possible causes for project collapse, are a failure of concept, requirements and specifications.
Some projects are doomed before they start, long before they reach the PM and should never have been initiated to begin with.
A failure of concept happens when the solution is based on a perceived problem and the problem is not qualified. Many times a solution is initiated as the result of a desire, not a real business need. The ultimate responsibility for this rests on the shoulders of Sr. Management, who have the responsibility to approve the preliminary research and conclusions or in other words the initiative that precedes the project and subsequently approve the unique set of requirements that become the project charter.
Culpability also lays with the project initiator or sponsor who is responsible for defining the business problem and establishing the rationale for the proposed solution. When this is a quick conversation with a member of management or under best circumstances a steering committee is where the cause of the failure begins. This is obviously not true in every case, but more often than not the envisioning and submission is a laizzes faire process that results in a poorly conceived idea that gets passed through to approval. Consider some recent Congressional legislation as an example of what I mean.
In many cases, by the time a PM gets involved, the damage is imbedded in the idea. This is also the last point at which to catch the structural failings and correct them. The PM has an obligation to review the projects requirements and establish the risk. If the PM is involved earlier in the process it may also help mitigate risks.
The project charter needs clearly defined requirements in order to create the schedule and establish functional specs.. If they are vague or not present then the charter needs to be rejected. This can be a difficult stand for a PM to take. No one wants to be pointing out the emperor is naked. However, if potential project deficiencies are identified early and before kick-off then the odds for project success rise. There may also be cases where the project concept may need to be rejected in total based on risk or the realization the work is redundant or superfluous.
So in my opinion, most projects fail because they were a bad idea from the start…
I think poor performance in:
1- Planning. Create & RESPECT the plan
2- Communications (internal, external). Relationship
3- Documentation ( Control boards)
In Military parlons it is said "Time spent in recce is never wasted & eventaully is the major cause of the result of a military operation"
In PM terms it refers to the scope definition. Which certainly may lead to scope creep if not well thought of.
Some of the major infrastructure projects around the globe are also suffering on account of poor handling of stake holders.
@Jim: Love your optimism :)
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
1. Lack of risk management
2. Not identifying all the stakeholders
3. Lack of clear documentation of requirements and measurement criteria to ascertain if the requirement is met.
@Suresh: Thanks for your appreciation. Like all fellow professionals discussing this topic, Mathew also aims to Share & Learn. Some of the comments received on this topic have indeed been an eye opener for Mathew in a lot of ways. Mathew hopes its added value to all those discussing here also :)
Looking forward to more sharing & learning.
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
All are very important but today I will go with:
#9. Absence of a Project Management Methodology
If you do not have a methodology numbers 4, 6, 7, 8 are included!!
@Gabriela: Very Good Observation. The presence of a robust PMM would help avoid a lot of the causes mentioned above.
....
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
@John: Mathew's gone through your article on your website. Your take on the fact that, "Most projects fail, because the Project Manager either cannot or does not Execute effectively." is refreshing & enlightening. Thanks for sharing.
@All Participants: Mathew recommends visiting John's site and reading the article @
http://www.johnastrello.com/?p=9
...
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
Mathew feels that thanks to the 'Halo Effect' a lot of people who are not qualified & experienced to be PMs (and thus do not deserve to be PMs), end up becoming PMs and this surely effects the Project Success negatively. After all, its time organizations understand that PROJECT MANAGEMENT is an area of specialization in itself and a professional with Project Management qualifications/experience is what organizations should be looking to hire to manage their projects (not necessarily Subect Matter Experts).
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
I concur with you. Thats very true.
@Jonathan: Thanks for agreeing with Mathew. You may find it worth your while to read the following article titled A PROJECT MANAGER IS A SUPER HERO!!! @ http://anishmathaimathew.blogspot.com/2009/05/project-manager-is-super-hero.html
[Mathew@PM4K] @ http://www.anishmathaimathew.blogspot.com
Posted 2 hours ago | Delete comment
Besides the obvious, namely, an incompetent PM, the number one cause for difficulties is scope creep.
I would vote with the Below sequence for Top# Causes for Project Failures.
#4. Poor/Inadequate Project Communications
#2. Halo Effect (Wrong Man for the Job)
#7. Scope Creep/Unrealistic Expectations
One other comment I may add follows a discussion I was having with the construction management department head of a major university.
The current requirements for construction management degrees includes a significant amount of design, advanced math, structural calculations, etc. that are engineering stuff - not construction managment.
It's a waste to bloat the currriculum with engineering to prepare people for CM. If you are the CM, design and design decisions are not and never should be your decision. On the other hand, classes in finance, human resources, supervision and personnel management, advanced scheduling (and not just how to make the software work) and lean philosphy, etc. are not.
CAD knowledge and knowing what size beam to install or the properties of soils should never be part of CM training and it's rediculous to follow the herd in this trend.
We simply are not preparing our students for the real world and the world we are in (unfortunatley) does put more weight into degrees than experience unfortunately.
As per my experience and the projects executed, I personally feel that the most common cause of project failure is:
1] Business Users not clearly aware of the functional requirement
2] Initial homework inadequate leading to scope creeps or inconsistency in requirements narrated by business users, which are prone to changes in the later stage of project life cycle.
Though every Project has a new learning but I think the problem of scope management is the biggest cause of project failure, having its impact till the last phase and schedule and which gets compounded when the champion business user from client is not able to get all the business users to understand his views.
I have some experience in troubled project turn arounds where the client and teams have failed to meet schedule, scope and budget goals and objectives (in other words, they were failing). The turn-arounds I have been engaged have been typically exceeding schedule and budget by more than 100% (and the burn rate is 7 figures per month).
While there can be a number of reasons for these failures, they typically have the common elements:
1. Lack of Client Executive Engagement and Leadership.
2. Lack of a clearly defined and delineated rationalization criteria for what qualifies as a "Requirement".
3. Lack of program and/or project priorities (scope, schedule, budget) which are ranked by what is non-negotiable, flexible and fluid.
4. Lack of clearly defined "toll / quality" gates with facilitating and measureable criteria on respective deliverables and work products.
5. Project organization is not aligned with the business organization in regards to business ownership.
I have often found that these failures are contributed equally by both the client as well as the implementers of the planned solution. Of course when you have one or more of the above you will see subsequent 'symptoms' in the lack of any baseline management, metrics for progress and performance analysis, risk management criteria etc.
"Lack of Client Executive Engagement and Leadership" is by far the reason N1.
Stakeholders are not able to identify right PROJECT MANAGER for the project.
I would say while scope creep can definitely be a killer (which ties in to having a great PM to avoid this), the number one cause for project failure is insufficient support from sponsors/upper management. A project can have an excellent PM, but if management is not behind it, then it leads to all manner of issues: lack of resources, no commitment, changes in funding/budget midstream, schedule slippage... you name it. Even if you get your project out on time/budget, if there's no business suppport for your end product then you've just created something that will get little use (if it's something like an IT application) or won't be integrated well into existing business processes resulting in the project being a sunk cost for the business. So maybe a parallel reason for failure would be that the project wasn't originally aligned well with business needs and strategy or was a good solution for the business need to begin with.
I think lack of strategic alignment between the project and company goals will destine you for failure. You can have the best PM and the best plan but if the project is not in line with the company's goals and objectives you will fail. This should fall back on the shoulders of your sponsor but sometimes even they miss this alignment.
The second big issue for projects is the lack of planning. So many want to get busy "doing" and do not take time to plan. The best phrase I have ever heard was from one of my team members during a tough planning session he said "Sweat now or bleed later." This was so true at the time, the team we had was inexperienced in planning and was questioning "Why am I spending time in this conference room planning? I should be out doing that right now and I can get it done."
The two key things for a project to be successful are to be strategically aligned with the company and have a plan. The rest of the issues on the list are important but will fall in line naturally if you have these two key elements.
You have started an excellent discussion, generating lots of good responses. A moving target is what I have experienced to be the main culprit (#7).
Being said, one may argue that the individual (project manager?) with ultimate responsibility for the project is the reason for its success or failure. One may argue that this individual should be able to control all reasons you have listed, thus, the cause would become the halo effect (#2). This is an easy assumption to make and it is too easy to blame one individual for a project failure.
I do think also that a lot of people (top management and team members included) do not understand or realize what a project is about and that it requires knowledge, skills and a methodology. Without this understanding, the project is of a bad start.
I agree with an earlier comment that "simple bad luck" (#10) should be rules out. Should not it be when risk assessment come into play? Being said, how often that risk assessment, which includes opportunity for improvement, is being conducted?
Project Managers are made not born.
I would have to argue that an equal case could be made for the "reverse halo effect" in making the assumption that pure project management may be a panacea for project ills. Concepts and methodologies are useless without applied knowledge.
Regardless how you wield the whip of Project Management Methodology it will have little effect if those you are trying to motivate have no confidence you understand what they do. They are the square peg to your round hole. It also makes it more difficult to understand business requirements and assess risk.
In my experience the best project managers are those with an in-depth knowledge of and direct level of experience in whatever industry, sector, technology etc. being serviced. Better scoping comes from a common understanding between the PM, project resources and stakeholders.
Regardless the formal education it impossible to transfer experience. Those with an aptitude for project management should be recruited from the work bench and an investment in their training and certification should be made.
"Project management skills" shows up in many job description as a desired qualification, in many cases Project Manager is a position held within career progression and not a lifetime role. Many CIO's and CEO's and I am sure other executive leadership roles have help PM positions in their careers.
So perhaps another contributor to project failure is a poor understanding (by the PM) of the business you are in.
According to me Customer Expectation Management is one of the Key differentiators.
On the subject of "customers": Something we teach in our project management seminar is that the entire world is divided into Stephen Spielberg and Roger Ebert ... people who make movies and people who criticize movies.
Allowing the beneficiaries of a project to consider themselves customers encourages them to be critics, instead of being members of the cast and crew.
Even when they really are customers ... when the project is managed and staffed by a separate, contracted company ... project managers should do everything possible to bring client stakeholders at all levels into the project team (into the extended team if there's no logical core team role) so the finished product is "our movie" instead of "Spielberg's movie with which we need to find flaws."
Robert, the only problem I see with your movie analogy is that Ebert generally only gets an opinion AFTER the (Spielberg) project is complete and in the can. He is not a stakeholder at any level. Since I doubt he even pays to see the film he actually may not be a true customer either.
The beneficiaries of a project are indeed the customer regardless their involvement. I might buy an "as built" Ford off the lot and my only involvement is signing on the dotted line or I might require customization I will pay extra for and so will have a greater involvement in the decision making process of what modifications are done in both cases I am a stakeholder but in the latter I am an active stakeholder.
The end user is ALWAYS a customer regardless their level of involvement.
Jim ... At the risk of sounding argumentative, I'll state two points with certainty:
1. End-users aren't customers. As a matter of definition (admittedly, our definition), customers are the people who make or influence buying decisions. They might or might not be the people who use the product (end-users/consumers), and might or might not be the people who provide the money (wallets).
Differentiating the customer, consumer and wallet roles is critical to business success at all levels. Conflating them leads to nothing but confusion and conflict (and alliteration).
2. Treating the beneficiaries of a project as customers is a matter of choice, not an inevitability. This is true even when they are customers by definition. The project manager may ask "What are your requirements for this product?" (contractual relationship), "How can we make our product better for you?" (customer relationship), or "Please help us make our product great" (collaborator relationship).
We generally recommend the third alternative - hence the Spielberg/Ebert metaphor.
I trust the reasons are obvious.
Regarding Robert's comments about the Customer being a critic; I have an 'example' that I'll reference.
While running a large Corporate Risk Project several years ago, the Corporate Security department had to both participate, and also were the prime 'customer' - as the toolset we were implementing would go to verifying security settings on databases.
In short, they were a critic, sitting on the sidelines. This was the number one root cause of problems - identified by the Project Team and Managment Staff when I was brought in to help 'right the ship'. Instead of being an adversary, I made sure that I got them 'in the boat with the rest of the crew' in solving the Security problems. We 'engaged' them as part of the team, and made sure that they knew and understood we were dependent upon them to bring their expertise and knowledge to the table.
In short, they went from being a critic, to being a part of the team that was deliverying the project.
Post a Comment