Frank WintersPhotographer and ConservationistSandwich, Ma, United States
In your experience, what are the primary causes of project failure? I have my personal top ten list, what's yours? In particular, what can be done to improve the abysmal success rate of IT projects? If we solve this conundrum, let's move on to world peace! Saving Changes...
Let's set that project failure is the unability to meet stakeholders expectations. In my experience I use the why's technique to try to find the reason. When something goes wrong, I ask the question why ? and with the answer I find I ask why again. After a few of those whys questions the answer in the majority of the case is (and it is my top reason for project failure): bad communication. Saving Changes...
One of the top causes I see is unclear goals. Everyone involved has a different idea what the end result should be and therefore none of the work is coherent. Saving Changes...
I see poor communication skills one of the main reasons for project failure, however, "communication skills" in and of itself is too broad of a term to be meaningful in modifying behavior. From my perspective, I consider poor communication as a series of missteps (read that missed steps) from the beginning of the project onward.
Essential steps prior to the planning phase of the project are often abandoned, the most important of which is listening to all parties impacted by the success or failure of the project. These parties often go well beyond those who are directly paying for the project, who are also often dictating the completion timeframe to the project team. In addition, many corporate cultures reward only "hard deliverables", (a written plan, for example), and either do not recognize or reward the "softer skills", such as listening, then assessing and analyzing. It is simply too difficult for most project teams to articulate the true "added value" of a strong, methodical and comprehensive listening and assessment process, much less the necessity. Further, as another indication of the lack of value given to listening, consider than when individuals are sought with "strong communication skills", it often refers to the individual's ability to receive direction, acknowledge receipt of direction, and disseminate information to others, rather than highly developed skills of eliciting and receiving information from others, such as listening skills. So in the interest of indicating that work is being performed, effort is focused on a "deliverable", such as a planning document. The project team dives headlong into the planning phase to present their "solution" and recommendations to solving the client's "problems", without a full understanding of the client company's culture, challenges and capabilities.
In a project post-mortem, many of the indications of failure of projects are present early on, had they been elicited and responded to. Indications of failure at the end of projects, if revealed earlier on, can be treated as indications of challenges to the project, and addressed. Had the project team listened and adjusted accordingly, the likelihood of handling challenges successfully early on would have gone up, as well as, I suspect, the potential for project success. Saving Changes...
As you mentioned in the article, this is a complex issue and I personally don't see a single answer. I have worked in organizations where we focused on PM education and mentorship programs to support the active PM's. This made an improvement, but did not solve the problem. I now look back and think to myself that maybe the training did not arm the PM's with the appropriate information. I've wanted to look at this problem through a different lens to understand this better, but have not had the time to get it done. An approach to consider this would be Systems Dynamics and casual loops. I've used this approach for understanding complex organizational issues and it is quite powerful. It is an approach designed to evaluate complex issues and get to the fundamental principles that guide the dynamics of the system. Knowing these principles provides a key to the root issues and approaches for solving.
Bottom line, I would go back to your number one issue - inadequately trained and/or inexperienced project managers. A highly skilled PM can work with all stakeholders to avoid some of the other problems listed. Unfortunately, that still does not guarrantte success. Saving Changes...
E Travis PMPGlobal Program Manager| PonderworksMelrose, Ma, United States
I have been mitigating failed project for 10 years now. One thing I have found for certain, if you are skilled enough, you will almost always be able to find out why a project failed, but, never be certain why another project succeeded.
Regarding your point #1, I have such great respect for this profession that I feel as though a person put in that position is not a project manager at all. How can you call yourself one if you don't know how to act like one? Perhaps that is a bit harsh, but, when you see what some failed projects look like from the inside, it is pretty devastating. For example, by all accounts that I have heard, the Boston Big Dig is a failed project. It cost the taxpayers of this country something like 14 billion dollars. I don't know how many careers or jobs suffered as well but, needless to say, not a good place for an inadequate project manager to be assigned. Saving Changes...
Richard PeckConsultant| SolutionsWestSacramento, Ca, United States
For what it's worth, here's a list I put together recently for a presentation on the development lifecycle. There isn't a particular order, and the list certainly isn't comprehensive, but there might be a couple new ones to think about in here.
Unclear Vision ? for what problem the project/system will solve, what the system should accomplish; also conflicting visions, private agendas.
Uncontrolled Requirements ? not articulated well by customer, not understood by team, not documented well, not constrained, not traced, then revisited late in the project.
Inadequate Leadership ? no focus of responsibility and accountability; i.e., no project manager or no support of project manager authority from sponsor or upper management.
No Quality Assurance ? no verification and validation of plans, requirements, designs; no test plans, no testers, no defect tracking.
No Risk Management ? no documented approach, no commitment to risk resolution, no planning for risk mitigation.
No Milestones/Iterations ? project is not phased, which increases risk; no clear transition from one phase or iteration to the next.
Poor Visibility ? information on the project is held close; team is not engaged in planning, status reporting is haphazard and scheduling is not validated.
No Time Accountability ? no tracking of time spent on tasks means no possibility of learning how long things take.
Low Level of Commitment ? roles and responsibilities are unclear and may not be accepted by team members.
These are all problems I've encountered on development efforts that are officially recognized as 'projects', though the scope of these problems belies the notion that the work has actually been treated like a project. Saving Changes...
I think that before we can consider what are the major causes of project failure, we have to take a step back to consider how we know when a project has "failed." In other words, we have to define what project failure means.
I believe that every organization has a different measurement scale for failure. Does a project fail when it comes in late? or does it fail when it doesn't work. Or is it when the users didn't get want they asked for?
What happens if the project came in late and was over budget, has some minor bugs, but the users love it because it lets them do what they want to do. Has the project failed in this instance? In this case, a project manager that may not be so good in keeping to a schedule, but is great at giving the users what they want has "not" failed because the organization might place more importance on shipping a useful product, than shipping it on time.
In an ideal world, we might be able to solve every problem we find and become the perfect project manager. But in my experience, time is limited and we can't do anything. A more effective strategy might be to focus principally on the problems that affect the core business focus of the organization. In other words, find out what is most important to the organization, then align your practices to them.
There is no perfect answer to this beacause it depends on who is doing the asking and who is doing the answering.
A better way of dealing with the question "why projects fail" might be to first consider how the organization defines failure, then focus on examining the habits and practices that might lead to what your organization considers failures.
Saving Changes...
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
Geoff raises an excellent point - that different organizations have different measures and definitions of success and failure. I would go a step further, and state that different situations have different measures; within an organization there can be variation. In fact, there can be variation from project to project.
To me, this then illustrates the extreme importance of having someone leading the project who is capable of understanding the key measures of success and failure, and driving the project to meet success and avoid failure. Due to this need for understanding at the project level, and managing the project to the needs, I would subscribe to the view that having an effective project manager is paramount in importance. Without this, the chance of failure is significantly magnified.
I do also subscribe to John Howe's final statement, that "a highly skilled PM...still does not guarantee success." There are very few guarantees of success in IT projects! Saving Changes...
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
The definition of project success or failure is similar to the defition of pornography "I know it when I see it". However, for both projects and pornography this is inadequate. Project success can't be one dimensional and it always has the same basic elements no matter the organization and its culture. There needs to be a quantifable ROI, the product of the project must be consistent with the needs of the stakeholders funding the project (the business owners) and must be perceived by them as such, and these results should have been produced within the timeframe and budget set aside for the work (as amemded if the amendedment process is well executed). It is quite possible for a project to satisfy the business owners but be over budget and late. This might be called a qualified success. However, with success like that you might not need any failures in that project managers somethimes are hurt by results like this. Saving Changes...
Perhaps it is alluded to in item 7, but I find a significant contributing factor is a poor perception of cultural change. New applications are not just ?turn key? wonders. I?ve found that it can take up to three years for a new technology to take root?a significant part of adaptation is, like Thomas Kuhn said about scientific paradigm shifts, a result of turnover. It?s a lot easier to bring new employees into the new culture than it is to change the old. There are, of course, many training and development tools available but they are expensive both in time and dollars, both for the training and for the apparent interim loss of productivity. But knowing this makes you a part of the solution. Saving Changes...
"More than any time in history mankind faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly."
