As an expert in the field of project management, you probably have experienced, seen or heard of fail projects story. Based on your experience, what are the 3 to 5 main project failure reasons? Saving Changes...
Ellen MahloyCEO| Ethereal Network LLCMidlothian, Va, United States
Either: poorly completed requirements gathering and/or poorly estimated time/cost/work load of a project. I'm very detail oriented so I either gathered the requirements myself or assigned people to do it that I knew would do so properly. Most of my projects have been IT and when I received task time/cost estimates from the technical staff, I multiplied their estimates times 3 to account for re-work (from QA and UAT testing) and unexpected interruptions. I rarely came in over budget and I almost always met deadlines. Saving Changes...
Engdaw AdmasuConstruction Project Manager| Water Works Corporation (WWC)Kombolcha Town, Ethiopia
1. Lack of the necessary resources
2. Inappropriate time estimations for project activities or not using time effectively.
3. The problem on quality consensus problem (lack of success criteria concerning quality, lack of appropriate quality metrics), and failure to meet quality requirements
4. Corruption is a major cause of project cost overrun and inappropriate performance on financial issues. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
I agree with @Sergio. Before measuring the failures we need to define what failure means. Should a project that was rectified via CR(s) be considered successful?
It is on time, on budget and delivered the scope. Should a project that delivered the scope but the outcome is now obsolete be considered successful?
Should a project that delivered the scope on time and on budget be considered successful if at the end of the project the morale in the team is low and people leave the organisation? Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
The CHAOS report had a section for the causes of project failure. It was a good reading and pretty constant since the first report. from the 1995 one:
1. User Involvement 15.9%
2. Executive Management Support 13.9%
3. Clear Statement of Requirements 13.0%
4. Proper Planning 9.6%
5. Realistic Expectations 8.2%
6. Smaller Project Milestones 7.7%
7. Competent Staff 7.2%
8. Ownership 5.3%
9. Clear Vision & Objectives 2.9%
10. Hard-Working, Focused Staff 2.4%
Other 13.9%
I don't see much difference today Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
@Kiron, I love the lack of Risk Management as a cause for failure, especially in the Agile world that mistakenly believe that Agile reduces the Risk, when in fact it increase the risk (although sometimes the positive aspect of risk). Saving Changes...
Adolfo JaramilloInternational Development Law OrganisationEysins, Switzerland
one here that I can add: when the PM has no authority over the project, when is controlled by his/her supervisor, this affects the project communications with stakeholders. Saving Changes...
Keith HoganSr Project Manager / Scrum Master| Sleek Solutions Inc.Saint Petersburg, Fl, United States
Failure = when the money runs out before the work is finished. Or at least, I'm not talking about absolute every last bit of work like reports and such that are not critical to the essential work of the product. These can follow. The value producing core must be completed on schedule. There can be scope and cost increased along the way if approved and budgeted.
Reasons for failure, scope increase without budget to support it. Failure to anticipate some discovery along the way. Retain sufficient budget to allow for some new work discoveries. I have seen PMs release version one with defects in order to claim success but deal with defects and omissions in the warranty phase. They may save their career, but add costs for the company to fix Release 1 software. The risk here is that defects have an unknown cost and could severely reek havoc with the company's operation. Release 1 can go in when it delivers sufficient value to the company with business approval. Saving Changes...
Where we typically "fail" is in schedule management. That is to say we are usually far behind schedule, which affects budget. We recently had a long discussion about the cause of this, but primarily because of our project governance structure, a project is not really a "project" during our identification phase. This means it does not get the resources (people, $$$) to really lay a good foundation for future phases. The issue is that the scope, budget, and schedule are "defined" during this phase, and usually the persons doing the estimates are not sufficiently experienced. The problem is that the project is then "sold" to senior management with these initial estimates in mind, and although they do change, wholesale changes are frowned upon. If changes are required that have a large impact on scope, budget, and schedule, it means going back to square one, which everybody avoids. This means the project is essentially "boxed" within those constraints, which usually leads to either quantities being reduced, or requirements being cut back. I'm working with one project now that has already had it budget increased once a good amount, and they are now realizing that it will likely not be enough. So instead of asking for more $$$, they are willing to reduce the scope. So, essentially the project has already failed the "end users", even though the project sponsor is willing to live with less quantity to remain within "budget": The same can be said for the schedule. Schedules are typically based on "guesstimates" using previous projects that had the same issues, and not on a robust WBS. We also tend to be optimistic, and rarely are timelines embedded into the schedule to account for any types of risks, which inevitably occur. That being said, you would then think that projects would identify "delays" as one of their biggest risks, but I have yet to see a risk register that has seriously looked at delays, as well as the accuracy of the initial schedule estimates to begin with. To sum things up then, I would say the biggest contributor to project "failure" is inexperience. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
I guess I'm not yet sure what we mean by "fail." I'm thinking along the lines of Edison's famous "I know several thousand things that won’t work" quote. Your project may not go according to plan, but that's a relatively poor criterion for success or failure. We need to take a more holistic view and determine the value of our projects: what problem they solve, what ideas they explore, how they fit into the company's vision, etc.
I've been fortunate to work for some organizations that weren't afraid to fail. Instead, they wanted to make sure we failed early, in order to preserve resources that could be applied to projects with a greater chance of success. It's easy for project managers to lose sight of this because we're so invested in our projects, but sometimes the best thing you can do for your company or your customer is to kill your project. If you recognize that your project no longer has the predicted value it had at initiation, then you could finish all work early and under budget but still fail. Saving Changes...
