Top Reasons Projects Fail

According to PMI, only 26% of all projects achieve success. That means an astounding 74% actually fail at some level. Project management is a complex profession and requires a variety of skills to be successful. Project managers are leaders, strategists, organizers, managers – you name it. A successful project manager must have a solid balance of both hard and soft skills.

We’ve compiled and categorized a list of top reasons from various sources on why projects fail. Each of the categories is directly addressed in the Execution Leadership for Project Managers program.

Goals and Vision

• Failing to understand the “why” behind the “what” (i.e., failure to ask and answer the question, “What are we really trying to achieve?”)
• Failing to document the “why” into a succinct and clear vision that can be used to communicate the project’s goal to the organization and as a focal point for planning
• Failing to align project objectives with overall business goals and strategy (e.g., sponsor has a private agenda that is not aligned with the organization’s stated goals)
• Failing to follow defined vision and goals as a guide for subsequent decision-making
• Neglecting to coordinate multiple projects throughout the organization which results in misalignment and potential conflicts

Leadership and Governance

• Failing to establish a governance structure appropriate to the needs of the project
• Appointing a sponsor who either fails to take ownership of the project or believes the project manager is solely responsible for project success
• Appointing a sponsor who lacks experience, seniority, time or training to perform the role effectively
• Failing to establish effective leadership in one or more of the three leadership domains (i.e., business, technical and organizational)
• Choosing a project manager with inadequate interpersonal or organizational skills that hinder collaboration or goal achievement
• Failing to establish the appropriate level of project oversight (e.g., the project manager either  micromanages and causes the team to lose motivation or fails to track things sufficiently and allows the project to run out of control)

Requirements

• Neglecting to use a formal approach in the scope definition process, resulting in vagueness and variability in understanding of scope limits
• Using vague or open-ended requirement statements (e.g., requirements that end with “etc.”)
• Failing to address excessive scope volatility or uncontrolled scope creep
• Failing to fully understand the operational context in which the product being produced needs to function once the project is over
• Allowing an intermediary to define requirements without directly consulting or involving those who will eventually use the product being produced (see the section on stakeholder engagement above)
• Failing to vet individual requirements against the project’s overall objectives to ensure each requirement supports the project’s objective and has a reasonable return on investment (ROI)
• Writing the project requirements on the assumption that everything will work as planned and not considering potential problems and challenging situations
• Failing to broker agreement among stakeholders with differing perspectives or requirements

Estimation

• Excluding those who will actually perform the work from the estimating process
• Adjusting estimates arbitrarily to secure a contract or make a project more attractive
• Allowing a manager, sales agent or customer to bully the team into making unrealistic commitments
• Providing estimates without a corresponding statement of scope
• Basing estimates on insufficient information or analysis, often resulting in rapid off-the-cuff estimates becoming firm commitments
• Making commitments to firm estimates rather than using a range of values that account for unknowns in the estimate
• Neglecting to document, discuss or validate the assumptions used for estimating
• Omitting small scale, less visible activities (the peanut list) from estimates
• Not referring to the repository of performance data culled from prior projects during the estimation process
• Failing to build in contingency to handle unknowns
• Assuming a new tool, process or system being used by the team will deliver instant productivity improvements.

Planning

• Failing to plan – diving into the performance and execution of work without first slowing down to think
• Underestimating complexity
• Working under constant and excessive schedule pressure
• Assuming effort estimates can be directly equated to elapsed task durations without any buffers or room for nonproductive time
• Failing to manage expectations of management or customers
• Viewing planning as the project manager’s responsibility rather than a team activity
• Failing to divide a large-scale master plan into more manageable pieces that can be delivered incrementally
• Assigning team schedule commitments without first getting corresponding commitments from other groups and stakeholders whose commitment to the schedule is crucial to success (aka schedule suicide)
• Neglecting to clarify roles and responsibilities, resulting in confusion and gaps
• Overloading some team members, resulting in degraded performance in critical areas of the project, while underutilizing other team members
• Not prioritizing requirements, leading to team energies often being focused on low-priority items instead of high-priority work
• Failing to include appropriate culture-change activities as part of the project plan
• Failing to provide sufficient user training when deploying the product produced by the project into its operational environment
• Failing to build training or ramp-up time into the plan
• Handling change requests informally without assessing their implications or gaining agreement to changes in schedule and budget

Risk Management

• Failing to think ahead in an effort to foresee and address potential problems
• Viewing risk management as an independent activity rather than an integral part of the planning process
• Considering the occurrence of risk, problems and issues as an indication that the risk management team is ineffective 

Architecture and Design

• Choosing a pet idea as a solution without considering more suitable solutions
• Developing individual team components before thinking through overall team architecture or component integration, resulting in duplication of effort, gaps, unexpected integration costs and other inefficiencies
• Failing to consider non-functional requirements (especially performance requirements) when designing a product, system or process, resulting in a deliverable that is operationally unusable
• Ignoring poor architecture, resulting in a system that is difficult to debug and maintain
• Being seduced into using leading edge technology when it is not needed or inappropriate
• Engaging in developer “gold plating” (I.e., developers implement the Rolls Royce version of a product when a Chevy is all that is needed)
• Relying on a specific tool to solve all problems simply because it is well understood rather than because it is well suited to the job
• Providing new tools for use by the project team without adequate training or appropriate vendor support. 

Configuration and Information Management

• Failing to maintain control over document or component versions, resulting in confusion over which is current, compatibility problems and other issues that disrupt progress
• Failing to use appropriate tools for organizing and managing information, resulting in a loss of key information and a loss of control

Quality

• Not discussing quality requirements, resulting in confusion on expectations and standards to be achieved
• Failing to plan for and include appropriate reviews, tests or checkpoints to verify quality
• Reviewing documents and design papers with a focus only on spelling and grammar rather than on substantive issues
• Viewing quality simply in terms of testing rather than as a culture of working
• Viewing quality solely as the responsibility of the quality assurance group rather than as a shared responsibility, sometimes referred to as the “throw it over the wall” mentality
• Focusing testing on the simple test cases while ignoring complex situations such as error and recovery handling
• Leaving integration and testing of individual components created in the project until all development activities are complete rather than performing ongoing incremental ingratiation and verification to find and fix problems early
• Testing in a test environment that is configured differently from the target production or operational environment in which the project’s deliverables will be used

Project Tracking and Management

• Optimistically believing that although the team is behind schedule, they will catch up later
• Neglecting to sufficiently follow up or track according to the published plan to allow issues to be identified and addressed early
• Misrepresenting or minimizing problems when presenting to customers, managers and stakeholders
• Dismissing information that might show that the project is running into difficulties
• Allowing schedule and budget to become the driving force, thus cutting corners and compromising quality
• Basing project tracking only on large work items rather than small increments
• Failing to monitor subcontractor or vendor performance regularly
• Believing that a task reported by a team member as 90% done really is 90% done  and not realizing that the remaining 10% often takes as long in calendar time as the first 90%
• Failing to put a system in place that reminds people of upcoming activities and commitments

Decision-Making

• Allowing key decisions (strategic, structural or architectural type decisions) to be made by people who lack the subject matter expertise to be making the decision
• Either ignoring or never soliciting expert advice on critical decisions
• Lacking situational awareness, resulting in ineffective decisions
• Failing to bring closure to a critical decision, resulting in wheel-spinning and inaction over extended periods of time
• Avoiding the difficult decisions because some stakeholders maybe unhappy with the outcome
• Allowing group decisions to be made at the lowest common denominator rather than facilitating group decision-making towards the best possible answer
• Making key decisions without identifying or considering alternatives
• Allowing decision fragments to go unanswered (parts of the who, why, when, where and how components of a decision are made, but others are never finalized), resulting in confusion
• Failing to establish clear ownership of decisions or the process by which key decisions will be made, resulting in indecision and confusion