Seven causes of project failure

how to recognize them and how to initiate project recovery

Introduction

Each year, enterprise organizations around the world face astronomical project failure rates, often wasting millions of dollars per failed project. The same enterprises agonize over the causes of project failure, call in expensive consultants to assess and recover failing projects, and often abandon what originally seemed like well-planned, well-organized projects, destined for success.

There is no single method or organizational structure that can be used to manage projects to success. Different organizations handle the functional projects differently. Some have fragmented and decentralized groups with multiple titles indicating that they are projects, while others might have large aggregations of project management professionals in a centralized support organization.

Regardless of the physical arrangements of the functions, there is a common set of related organizational needs when properly delegated to the appropriate groups that can be used to save or manage projects. Besides a well defined charter, the list that follows summarizes some of the major project management functions that are necessary to achieve success in projects:

  • Recruit and maintain adequate technical and non-technical resource skills
  • Manage the allocation of scarce resources
  • Define and collect operational metrics to support project and stakeholders decision making
  • Promote efficient and effective communications
  • Select and utilize technology related tools

Many project management professionals who work well in this area would say that the list consolidates a significant and sometimes overwhelming task.

While managing projects is one of the oldest and most replicated accomplishments of mankind, one only has to look at the achievements of the builders of pyramids, the masons and the craftsmen of great cathedrals and mosques, the constructors of the Great Wall of China, and other manmade wonders of the world. On the other hand, managing projects in an enterprise is one of the newest disciplines with its roots in the latter 1950s for most organizations. As a result, projects in organizations have simply not had sufficient time to mature to the state of other business disciplines such as finance, operations, or accounting.

Many references are made in various articles that point out that project management as a profession has not been very successful from an outsiders view. Projects have high failure rates and there is even some debate about projects and their value in the organization. Is it a needed function? Should it be outsourced? Our view is that projects hold the key to an organization’s productive future and done poorly can lead to the failure of a business. Done well, projects can give a firm a significant competitive advantage.

If projects are so valuable, what keeps them from being universally recognized as an important function in business? What is necessary to manage projects well to achieve competitive advantage? Projects are a business lever, in that they allow the organization to pickup more weight than would be picked up without them. Business organizations abound with drive issues related to the scoping functions of cost, schedule and purpose. So how does one see that a project’s goals are met? Especially when the project itself is in the middle of being completed.

Why Projects Fail

Project failure can happen in any organization and to any project. There are an infinite number of reasons for failure. Sometimes it’s out of the control of a project manager and/or the team members. Sometimes failure is controllable. Failed projects and people involved with the failure have some things in common. In both cases they are given prescriptions for “quick fixes” which typically prove to be ineffective and can sometimes produce disastrous side effects.

Using a medical metaphor, flu’s are viral and are unresponsive to antibiotic drugs. For projects, technology is the antibiotic often prescribed. Suggestions like, upgrade your software for tracking the project, use the critical chain instead of the critical path, or use a Monte Carlo simulation to compute the project risks. In many cases, these powerful interventions fail because they are inappropriately applied.

The goal of project management is to produce a successful product or service. Often this goal is hindered by the errors of omission as well as commission by management, project managers, team members and others associated with the projects. The purpose of this paper is to enable the identification of the common causes of project failures through the use of surveys and questionnaires to provide information which can be used to mitigate their occurrence and in many cases repair the damage caused and hopefully, recover the projects.

Projects most commonly fail because there is a lack of attention and efforts being applied to seven project performance factors:

Focus on business value, not technical detail. This involves establishing a clear link between the project and the organizations key strategic practices. The project plan needs to cover t he planned delivery, the business change required and the means of benefits realization.

Establish clear accountability for measured results. There must be clear view of the interdependencies between the projects, the benefits, and the criteria against which success will be judged. It is necessary to establish a reasonably stable requirement baseline before any other work goes forward. Requirements may still continue to creep. In virtually all projects there will be some degree of “learning what the requirements really are” while building the project product.

Have consistent processes for managing unambiguous checkpoints. Successful large projects typically have software measurement programs for capturing productivity and quality historical data that can be sued to compare it against similar projects in order to judge the validity of schedules, costs, quality, and other project related factors. The lack of effective quality centered mechanisms can be a major contributor to both cost and schedule overruns.

Have a consistent methodology for planning and executing projects. There should be a detailed plan developed before any release date of a project is announced. Inadequate planning is one of the major reasons why projects spin out of control.

Include the customer at the beginning of the project and continually involve the customer as things change so that the required adjustments can be made together. It has been observed that successful projects occur when end users (customers) and the project members work as teams in the same cubicle, although this is not always possible. Projects are less likely to fail if there are informed customers giving meaningful input during every phase of requirements elicitation, product description and implementation. The customer needs to be asking, “how are the project result used over time and what do I get out of the results?

Manage and motivate people so that project efforts will experience a zone of optimal performance throughout its life. This involves managing and retaining the most highly skilled and productive people. Knowledge is money. A project team made up of higher paid people with the right specialized skills is worth more per dollar than a group of lower cost people who need weeks or months of training before they can start to be productive.

Provide the project team members the tools and techniques the need to produce consistently successful projects. The project team must be skilled and experienced with clear defined roles and responsibilities. If not, there must be access to expertise which can benefit those fulfilling the requisite roles.

Project Failures Classified and Categorized

Classifying or grouping the seven failure factors above into broader categories, helps to focus the assessment and recovery planning tasks around a few broad categories, for which there are numerous assessment tools, recovery planning techniques, and a reasonable amount of assistive literature. Grouping project problems into one or more of these categories becomes an essential part of assessing the project’s current situation, developing a recovery project plan and assembling a team to accomplish what is needed to get the project back on track.

An examination of the above seven project performance factors indicates that they can be classified into three broad categories:

  • People (#’s 6 & 7)
  • Process (#’s 2, 3, & 4)
  • Communications (#’s 1 & 5)

During June, 2007 the authors conducted an anonymous survey amongst a large group of professional project managers, working in a worldwide enterprise, using the survey questionnaire shown in Appendix to determine which project performance factors, are most closely related to project failures. Based on the survey, 43% of project managers surveyed responded that project Communications factors were a key factor in the failure of projects, while 42% responded that Process factors were key and only 32% responded that People were a key factor in the failure of projects they were involved with.

This survey data aligns well with another survey that was conducted recently by the Computing Technology Industry Association (CompTIA), in which nearly 28 percent of more than 1,000 respondents to the web poll cited poor communications as the number one cause of project failure. Eighteen percent of the respondents also cited poor resource planning (a People factor in the author’s survey) as the second most frequent cause of project failure. (CompTIA, 2007)

Assessment Process for Failing Projects

Every enterprise that employs projects to achieve its business goals needs to develop a formal assessment process for failing projects and needs to have trained resources, ready to respond to project “911” calls. The question usually arises as to whether “inside” or “outside” resources are best for project assessments. In most cases, it is more effective to employ resources from outside of the organization where the failing project is operating. In large companies (Fortune 1000) this goal can often be met by retaining assessment resources from another division. In smaller companies, it is almost always better to bring in outside consultants to conduct the assessment.

The project assessment process consists of five distinct phases (ESI, 2005):

  • Define the assessment charter
  • Develop the assessment plan
  • Conduct the assessment
  • Analyze data gathered; prepare findings
  • Report findings to stakeholders

Each assessment phase must complete before starting the next phase. There are several key assessment concepts that need to be understood at this point (ESI, 2005):

  • Assessment: formal examination of a project’s performance, metrics, issues, and forecasted performance
  • Recovery: save from loss; restore the project to usefulness; prevent total failure
  • Focus of assessment: determining the current “real” condition of the project
  • Result of assessment: determine changes needed in people, product, process or all of these (ESI, 2005)

In addition to focusing on determining the current, real status of the project, the assessment needs to thoroughly investigate project variables common to most projects:

  • Project work breakdown structure (WBS)
  • Project risks (those in the risk log and risks known but not recorded)
  • Project deliverable defects
  • Project resources (human and other)
  • Project schedule
  • Project processes (both enterprise related and project-specific)

Develop the Assessment Charter

The assessment is actually a project itself and it becomes a project-within-a-project. As a sanctioned project, the assessment requires a charter to be developed and signed off by the stakeholders of the failing project, before any assessment work begins.

The purpose of the assessment charter is to establish the authority of the assessment team to investigate all aspects of the failing project, to interview all project resources, and to gain access to all project intellectual property and project records. The assessment charter also needs to clearly describe the assessment deliverables and the schedule for the assessment project.

Develop the Assessment Plan

After the assessment charter is signed off, the next step for the assessment team is to develop an assessment plan. The purpose of the assessment plan is to describe what activities the assessment team will execute to achieve the objectives of the assessment charter. The assessment plan contains the details of the assessment process, and should include:

  • Assessment schedule, including daily “rhythm” activities and key milestones
  • Assessment team questionnaire(s)
  • Critical project documentation to be reviewed
  • Interview plan and schedule
  • Assessment deliverables

Like the assessment charter, the assessment plan needs to be delivered to the stakeholders of the failing project and it needs to be signed off by the stakeholders before any assessment activities begin.

The assessment team should schedule a kickoff meeting with the failing project team to explain the assessment process and to begin to build a relationship with the project team. This is not the time to express any feelings about the outcome of the assessment or to worry out loud about the project’s current situation.

Conduct the Assessment

The assessment kickoff meeting marks the starting point for the assessment project. The purpose of the kickoff meeting is to get the assessment kicked off in a positive direction. All assessment team members, project team members, and stakeholders who will be interviewed should attend. The purpose of the kickoff meeting is NOT to lay blame for project failures or find fault, but to ask for help from everyone to complete a thorough and objective assessment.

Project team members will want to share their views about the project’s troubles, how it got this point, and make suggestions for immediate fixes. Instead of engaging with the project team on these subjects, the assessment team needs to act confidently and positively and give the project team assurances that while time is of the essence, all of their concerns, suggestions, and solutions will be collected during the assessment. Now, during the kickoff meeting, is not the right time to begin gathering this information.

The assessment team needs to operate out of a “war room” established on-site where the project team is located. All of the project data that was identified for review in the assessment plan should be located in the war room, even if it means duplicating large amounts of project records. Administrative supplies and other support items for the assessment team need to be available in the war room also.

The daily rhythm of the assessment team needs to include two-a-day team debriefing meetings, in the war room, so that the assessment team can “synch up” and share information about their activities, interviews, preliminary findings, etc.

The assessment team leader should establish discipline around the use of the war room, access requirements, and hours of operation. When the assessment team is not working, the war room needs to be securely locked. The war room becomes the “home room” for project members from the failing project, who are assigned to work with the assessment team. These people should not be allowed to work in their normal work areas if they are assigned to the assessment team.

The walls of the war room should display assessment project metrics. Examples of effective use of the war room walls are:

  • Assessment master schedule, updated daily
  • “Burn down” charts tracking interviews left to be done, documentation remaining to be reviewed, and questionnaires left to be returned
  • “Thermometer chart” counting deliverables left to be completed

All stakeholder status meetings should be held in the war room so that the information on the war room walls can play an active part of the status meetings and serve to highlight the progress of the assessment project to the team members and stakeholders.

Key Focus Areas for the Assessment Team

The assessment team needs to focus on key areas of project performance and assessment metrics, as suggested in the checklists below:

Project data assessment checklist:

  • Project charter – does it clearly articulate authority and objectives for the project?
  • Project estimates – do the estimates that support the project cost/price appear realistic?
  • WBS – is the WBS complete and is it structured appropriately for this project; does it reflect all of the estimates and all of the work that must be done to complete the project?
  • Responsibility assignment matrix (RAM) – does the RAM account for and assign responsibility for all of the work scope?
  • Signed work orders and subcontracts – do these documents cover the entire scope of work outlined in the WBS?
  • Performance metrics – are metrics presenting a complete picture of project performance? (Forman & Discenza, 2006)
  • Key project indices – CPI, SPI, TCPI, IEAC, etc. (Fleming & Koppleman, 2005, Chap 10)
  • Control accounts – are CV and SV clearly explained in variance analysis narratives?
  • Time reporting – is time reporting accurate and is time being reported at the work package level?
  • Copies of deliverables and deliverables receipts – is the project data management of these critical items adequate?

Project planning assessment checklist:

  • Project plan – does one exist and is it current and does it establish a baseline on which to manage this project on a daily basis
  • Control accounts – do these track to the RAM and are they at the “right” level of responsibility?
  • Work packages – do these contain measurable work and are they of reasonable size and duration for measurability?
  • Do control accounts (and work packages) exist at a reasonable level of work decomposition in the WBS?
  • Project schedule – is the schedules for each work package in each control account traceable to the project master schedule?
  • Statement of Work (SOW) – is the SOW current (including any change orders) and does it describe measurable work with measurable completion criteria?
  • Risk management plan – is the plan complete and is it current, including mitigation plans, actionees, closeout info and dates?
  • Change management plan – does this exist, is it being used, and are all changes being reflected in other applicable documents?
  • Financial plans – if separate financial plan(s) exist, do reports track to the plan’s budget, goals, or allocations?
  • Issue logs, reports, and tracking information – are these being used, maintained, and are actions being assigned and closed?

Review and Analysis of Team Questionnaires

The team questionnaires need to be collected on schedule and the analysis of their results done promptly and tracked on charts in the war room. There will be stragglers and the assessment team needs to give them special attention so that they will complete their questionnaires and return them for analysis. Often, the most critical information is going to be contained in the late questionnaires – people with this key project information tend to horde it because they may fear some form or retribution.

If there were compelling reasons to make the team questionnaire anonymous, then the assessment team will need to enlist group peer pressure as the incentive to get all of the questionnaires returned for analysis. Depending on the composition of the questionnaire, there will be a variety of methods to evaluate and analyze the results.

The results obtained from completed questionnaires can change, add, or delete names from the assessment interview list. The list of questions for further discussion during project team interviews will be built from the questionnaire results and may be different for each interview. However, as a general rule, the set of interview questions should be standardized for all interviews. The interviews serve only as the basis to clarify results of the questionnaire analysis and are NOT intended to entrap project team members, fix blame, or identify team member performance issues.

Conduct Interviews

Next the assessment team divides up the number of planned interviews, often in a manner that matches the background of each assessment team members with that of the interviewee’s. All interviews should not be done solo – always have two interviewers so that one can be taking notes an making notes while the other is working through questions with the interviewee.

Schedule the interviews to occur as continuously as possible, without significant gaps in time. Completing all project team interviews in one or two days is important to maintain assessment momentum, continuity of purpose, and consistency of data collection.

All interviews should be conducted in the war room, to get interviewees away from their working environment, and hopefully, enable them to speak more freely about the questions being asked. Emphasize the confidential nature of the interviews. Do not use any recording devices to collect interview information. – this will establish a hostile, threatening environment. Use open-ended questions and listen, listen, listen.

Analyze Project Control and Management Review Processes

In addition to the focus areas for the assessment shown above, the assessment team needs to drill down into the project control and management review process (es) the failing project has in place currently, to determine the adequacy of these.

The drill-down will become apparent as the assessment team works through their assessment of project data and project planning artifacts, listed above. Also the results of the project team questionnaires will provide interesting avenues for the drill-down on project control and management review and processes.

Questions that need answers will be similar to the following:

  • What regularly scheduled project status meetings are held, who participates and with whom outside of the project team, are these meetings held?
  • How are project metrics reported to stakeholders and what are stakeholders expected to do with the information?
  • Are all variances being adequately reported and explained and is there a control/feedback process to assign corrective action?
  • Is the labor hour tracking system providing accurate information for project accounting and metrics?
  • What reports are being used by whom, to make what decisions?
  • Is all work reported as “complete” in fact totally “complete”?

Develop Findings

After all interviews are completed, the assessment team turns to the task of developing findings. This may follow a process where a set of preliminary findings are developed for initial review with the stakeholders and project management, to be followed by a finished (or final) set of findings, on which a project go/no-go decision will be based.

The task of developing findings is largely that of aggregating and analyzing large amounts of information that by now have been collected by the assessment team. The information needs to be filtered for relevance and aggregated into logically related categories that can be acted upon later. The authors like ESI’s approach to aggregating findings because it so clearly establishes the nature of the aggregated findings (ESI, 2005):

  • Threats – findings that contain future bad news for the project
  • Opportunities – findings that contain future good news for the project
  • Problems – findings that contain realized bad news for the project

There are a number of proven techniques that may be used to aggregate findings into the three “TOPs” categories, such as affinity diagrams, fishbone charts, comparative ranking, etc. (See Exhibit 2 for an example.)

Fishbone Diagram to Aggregate Findings

Exhibit 2 – Fishbone Diagram to Aggregate Findings

In addition there are some key points there are some key points for the assessment team to remember in developing their findings:

  • Each finding needs to be clearly supported by facts
  • Each finding needs to be specific, clear and understandable to stakeholders and project management
  • Findings should be stated in a positive sense, wherever possible
  • Every finding must be able to serve as the basis for a logical recommendation

Presentation of Assessment Findings

Before the assessment team presents their findings to the stakeholders, the team needs to prepare a summary slide deck to convey the findings and rehearse the presentation. The team needs to decide who will present the findings and how the remaining members of the assessment team will interact during the presentation. The answers to these questions will depend largely on what the assessment team has learned about the stakeholders and how they prefer to communicate.

The assessment findings should also be contained in a formal assessment report, as the key deliverable to stakeholders from the assessment project. The report may have appendices containing data that support the findings or references to where the data may be found online, etc. The assessment report is just that, and should not contain recommendations as to the continuation of the project or its cancellation or other disposition.

Attendance at the presentation of findings should be limited to only stakeholders who participated in granting the assessment charter. This meeting closes the loop with the assessment charter objectives and effectively brings to a close, the assessment effort. The assessment team attending the meeting may need to remain after the meeting to be available to address questions from the stakeholders, if they request. Otherwise, the assessment team’s work if finished and it should make preparations to disband, close down the war room, and closeout activities.

Conclusion

Assessing and recovering a failing project can be among the most challenging work for a project manager to perform for an organization. However, the payoff can be huge, since a project t brought out of failure can provide significant value to a firm. The seven factors outlined in this paper are critical for assessing a failing project’s performance and planning corrective action to make the project successful. All seven factors are needed for success. When one factor turns negative and is not corrected disaster is unavoidable.

The authors’ survey results on the common causes of project failure indicate that the failure factors can be grouped into three main categories. They are: (1) people factors, (2) project process factors; and (3) project communications factors.

Managing a failing project begins by assessing its real condition by the use of questionnaires, surveys, and interviews. When the assessment is complete and the project go/no decision has been made by the stakeholders, the assessment team can build a plan to implement project recovery.

References

Computing Technology Industry Association, (2007, March 6) web news release. Retrieved June 27, 2007from http://www.comptia.org/pressroom/get_pr.aspx?prid=1227

ESI International (2005, February) Rapid Assessment and Recovery of Troubled Projects,, a 3-day course taught as part of the ESI Project Management curriculum.

Fleming, Q. W. & Koppelman, J. M. (2005) Earned Value Project Management, 3rd edition, Newtown Square, PA: PMI Press.

Forman, J. & Discenza, R. (2006, October) Tools for Managing Projects: Adding Earned Value Metrics to Digital Dashboards to Report Performance of Active Projects Proceedings of the PMI Global Congress Proceedings – Seattle, Washington

Forman, J. & Discenza, R., (2007, June) survey instrument applied in a Fortune 100 company:

Appendix 1 - Opinion Survey on Project Success and Failure Factors

Exhibit1

Exhibit 1 –

© 2007, Richard Discenza, James B. Forman 10
Originally published as a part of 2007 PMI Global Congress Proceedings – Atlanta, Georgia

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.