WHY DO PROJECTS FAIL? – 101 COMMON CAUSES

08 Jan WHY DO PROJECTS FAIL? – 101 COMMON CAUSES

Leadership and Governance

1. Failure to establish a governance structure appropriate to the needs of the project (classic mistake award winner)
2. Appointing a Sponsor who fails to take ownership of the project seriously or who feels that the Project Manager is the only person responsible for making the project a success
3. Appointing a Sponsor who lacks the experience, seniority, time or training to perform the role effectively
4. Failure to establish effective leadership in one or more of the three leadership domains i.e. business, technical and organizational
5. The Project Manager lacks the interpersonal or organizational skills to bring people together and make things happen
6. Failure to find the right level of project oversight (e.g. either the Project Manager micromanages the project causing the team to become de-motivated or they fail to track things sufficiently closely allowing the project to run out of control)

Stakeholder Engagement Issues

1. Failure to identify or engage the stakeholders (classic mistake award winner)
2. Failing to view the project through the eyes of the stakeholders results in a failure to appreciate how the project will impact the stakeholders or how they will react to the project
3. Imposing a solution or decision on stakeholders and failing to get their buy-in
4. Allowing one stakeholder group to dominate the project while ignoring the needs of other less vocal groups
5. Failure to include appropriate “change management” type activities into the scope of the project to ensure stakeholders are able to transition from old ways of working to the new ways introduced by the project
6. Failure to establish effective communications between individuals, groups or organizations involved in the project (classic mistake award winner).

Team Issues

1. Lack of clear roles and responsibilities result in confusion, errors and omissions
2. There are insufficient team members to complete the work that has been committed to
3. Projects are done “off the side of the desk” (i.e. team members are expected to perform full time operational jobs while also meeting project milestones)
4. The team lacks the Subject Matter Expertise needed to complete the project successfully
5. Selecting the first available person to fill a role rather than waiting for the person who is best qualified
6. Failure to provide team with appropriate training in either the technology in use, the processes the team will be using or the business domain in which the system will function
7. Lack of feedback processes allows discontent in the team to simmer under the surface
8. The Project Manager’s failure to address poor team dynamics or obvious non-performance of an individual team member results in the rest of the team becoming disengaged
9. Practices that undermine team motivation
10. Pushing a team that is already exhausted into doing even more overtime
11. Adding more resources to an already late project causes addition strain on the leadership team resulting in even lower team performance (Brooks law)

Requirements Issues

1. Lack of formality in the scope definition process results in vagueness and different people having different understandings of what is in and what is out of scope
2. Vague or open ended requirements (such as requirements that end with “etc”)
3. Failure to address excessive scope volatility or uncontrolled scope creep (classic mistake award winner)
4. Failure to fully understand the operational context in which the product being produced needs to function once the project is over (classic mistake award winner)
5. Requirements are defined by an intermediary without directly consulting or involving those who will eventually use the product being produced (see also lack of stakeholder engagement above)
6. Individual requirements are never vetted against the project’s overall objectives to ensure each requirement supports the project’s objective and has a reasonable Return on Investment (ROI)
7. The project requirements are written based on the assumption that everything will work as planned. Requirements to handle potential problems or more challenging situations that might occur are never considered
8. Failure to broker agreement between stakeholders with differing perspectives or requirements

Estimation

1. Those who will actually perform the work are excluded from the estimating process
2. Estimates are arbitrarily cut in order to secure a contract or make a project more attractive
3. Allowing a manager, sales agent or customer to bully the team into making unrealistic commitments
4. Estimates are provided without a corresponding statement of scope
5. Estimation is done based on insufficient information or analysis (rapid off-the-cuff estimates become firm commitments)
6. Commitments are made to firm estimates, rather than using a range of values that encapsulate the unknowns in the estimate
7. The assumptions used for estimating are never documented, discussed or validated
8. Big ticket items are estimated, but because they are less visible, the smaller scale activities (the peanut list) are omitted
9. Estimation is done without referring back to a repository of performance data culled from prior projects
10. Failure to build in contingency to handle unknowns
11. Assuming a new tool, process or system being used by the team will deliver instant productivity improvements

Planning

1. Failure to plan – diving into the performance and execution of work without first slowing down to think
2. The underestimation of complexity (classic mistake award winner)
3. Working under constant and excessive schedule pressure
4. Assuming effort estimates can be directly equated to elapsed task durations without any buffers or room for non-productive time
5. Failure to manage management or customer expectations
6. Planning is seen as the Project Manager’s responsibility rather than a team activity
7. Failure to break a large scale master plan into more manageable pieces that can be delivered incrementally
8. Team commitments themselves to a schedule without first getting corresponding commitments from other groups and stakeholders who also have to commit to the schedule (aka schedule suicide)
9. Unclear roles and responsibilities led to confusion and gaps
10. Some team members are allowed to become overloaded resulting in degraded performance in critical areas of the project while others are underutilized
11. Requirements are never prioritized resulting in team focusing energies on lower priority items instead of high priority work
12. Failure to include appropriate culture change activities as part of the project plan (classic mistake award winner)
13. Failure to provide sufficient user training when deploying the product produced by the project into its operational environment (classic mistake award winner)
14. Failure to build training or ramp up time into the plan
15. Change requests are handled informally without assessing their implications or agreeing to changes in schedule and budget

Risk Management

1. Failure to think ahead and to foresee and address potential problems (Classic mistake award winner)
2. Risk management is seen as an independent activity rather than an integral part of the planning process
3. Risk, problems and issues become confused as a result team isn’t really doing risk management

Architecture and Design

1. Allowing a pet idea to become the chosen solution without considering if other solutions might better meet the project’s overall goal
2. Teams starts developing individual components without first thinking through an overall architecture or how the different components will be integrated together. That lack of architecture then results in duplication of effort, gaps, unexpected integration costs and other inefficiencies
3. Failure to take into account non-functional requirements when designing a product, system or process (especially performance requirements) results in a deliverable that is operationally unusable
4. Poor architecture results in a system that is difficult to debug and maintain
5. Being seduced into using leading edge technology where it is not needed or inappropriate
6. Developer “gold plating” (developers implement the Rolls Royce version of a product when a Chevy was all that was needed)
7. Trying to solve all problems with a specific tool simply because it is well understood rather than because it is well suited to the job in hand
8. New tools are used by the project team without providing the team with adequate training or arranging for appropriate vendor support

Configuration and Information Management

1. Failure to maintain control over document or component versions results in confusion over which is current, compatibility problems and other issues that disrupt progress
2. Failure to put in place appropriate tools for organizing and managing information results in a loss of key information and/or a loss of control

Quality

1. Quality requirements are never discussed, thereby allowing different people to have different expectations of what is being produced and the standards to be achieved
2. Failure to plan into the project appropriate reviews, tests or checkpoints at which quality can be verified
3. Reviews of documents and design papers focus on spelling and grammar rather than on substantive issues
4. Quality is viewed simply in terms of testing rather than a culture of working
5. The team developing the project’s deliverables sees quality as the responsibility of the Quality Assurance group rather than a shared responsibility (the so called “throw it over the wall” mentality)
6. Testing focuses on the simple test cases while ignore the more complex situations such as error and recovery handling when things go wrong
7. Integration and testing of the individual components created in the project is left until all development activities are complete rather than doing ongoing incremental ingratiation and verification to find and fix problems early
8. 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

1. Believing that although the team is behind schedule, they will catch up later
2. The project plan is published but there is insufficient follow up or tracking to allow issues to be surfaced and addressed early. Those failures result in delays and other knock-on problems
3. Bad news is glossed over when presenting to customers, managers and stakeholders (aka “Green Shifting“)
4. Dismissing information that might show that the project is running into difficulties (i.e. falling prey to the “confirmation bias”)
5. Schedule and budget become the driving force, as a result corners are cut and quality is compromised (pressure to mark a task as complete results in quality problems remaining undetected or being ignored)
6. Project is tracked based on large work items rather than smaller increments
7. Failure to monitor sub-contractor or vendor performance on a regular basis
8. Believing that a task reported by a team member as 90% done really is 90% done (note often that last 10% takes as long in calendar time as the first 90%)
9. Believing that because a person was told something once (weeks or months ago), they will remember what they were asked to do and when they were supposed to do it (failure to put in place a system that ensures people are reminded of upcoming activities and commitments)

Decision Making Problems

1. Key decisions (strategic, structural or architectural type decisions) are made by people who lack the subject matter expertise to be making the decision
2. When making critical decisions expert advice is either ignored or simply never solicited
3. Lack of “situational awareness” results in ineffective decisions being made
4. Failure to bring closure to a critical decision results in wheel-spin and inaction over extended periods of time
5. Team avoids the difficult decisions because some stakeholders maybe unhappy with the outcome
6. Group decisions are made at the lowest common denominator rather than facilitating group decision making towards the best possible answer
7. Key decisions are made without identifying or considering alternatives (aka “First Option Adoption“)
8. Decision fragments are left unanswered (parts of the who, why, when, where and how components of a decision are made, but others are never finalized) resulting in confusion
9. Failure to establish clear ownership of decisions or the process by which key decisions will be made results in indecision and confusion

Article written and researched in 2022 by Robert Goatham, Calleam Consulting and Universtiy of British Columbia Sauder School of Business – Continuing Business Studies

www.calleam.com /why-do-project-fail?