64 Reasons That IT Projects Fail
posted by Anna Mar, August 15, 2013IT projects commonly fail. Studies peg the average project failure rate somewhere between 50%-80%.
In recent years, many organizations have mandated lessons learned sessions for every project. This has led to a better understanding of why projects fail.
Failure often has more than one root cause. In other words, many projects are ripe with problems. The following list (with examples) represents the most common reasons projects fail.
Business Case
1. Failure to evaluate alternatives
The business case fails to consider alternative approaches to the project. This exposes the project to challenges later (i.e. why didn't we consider ____ approach?).
2. Poor financial forecasts
Financial forecasts in the business case are inaccurate.
3. Optimism bias renders business case unrealistic
The business case makes rosy assumptions that don't reflect business realities.
4. Cooked numbers in forecast
Lack of objective financial analysis. The developer of the business case makes the numbers "work".
5. Metric based approvals
Reviewers approve a business case based on a handful of forecast metrics without examining constraints and risks.
6. Missed future costs
The business case promises to reduce existing costs but fails to anticipate new costs the project will introduce. For example, a system project may free-up administrative resources but increase the need for system administrators (who are generally more expensive).
7. No business case
The project proceeds without a formal analysis of its merit.
Project Planning
8. Budgeting errors
A low quality project budget that leads to financial chaos.
9. Poor risk analysis
Failure to identify, analyze and communicate risks.
10. Failure to identify all stakeholders
The project manager fails to involve IT operations. When it comes time to launch, the head of operations rejects the project.
11. Optimistic resource assumptions
The project plan assumes key resources are 100% committed to the project when they have other commitments.
12. Optimistic estimates
Estimates that are overly optimistic or fail to consider true project scope.
13. Coerced estimates
The project manager directs the team to provide low estimates.
Can you estimate this? I don't expect it that it will take you any longer than a few days.14. Naive estimates
Those who provide estimates don't have the requisite experience (e. g. the project manager provides estimates for the testing phase).
15. Rough estimates
Ballpark estimates are assumed to be rock solid (no formal estimates are produced).
16. Failure to properly estimate tasks not considered critical
Tasks that aren't on the critical path such as data migration are severely underestimated.
17. Poor task scheduling
The work breakdown structure is missing dependencies.
18. Big bang releases
It's well accepted that releasing a project in incremental phases tends to reduce risk and cost. Nevertheless, projects tend to be planned with major releases.
19. No Methodology
The project is executed according to an ad-hoc process that's likely to fail.
Requirements
20. Inadequate requirements
Unclear requirements that leave too much room for interpretation. In many cases, the project manager or developers end up filling in the blanks.
21. Gap between requirements and expectations
Business users begin to dream that the system will do things that aren't captured by the requirements.
22. Requirements aren't compliant
Requirements are not in compliance with laws, regulations, standards, best practices or requisite audits.
23. Silo requirements
Requirements fail to look at the project at the enterprise level. For example, they fail to consider integration with key business processes.
24. Naive requirements
Lack of due diligence in developing and validating requirements (e. g. subject matter experts aren't consulted).
25. Solution in search of a problem
The requirements don't solve business problems.
26. Requirements don't match the business case
The requirements drift from the original goal of the project.
27. Requirements dictate architecture
Requirements specify the solution. For example, specifying that a particular COTS product must be used without proper due diligence.
28. Inaccurate requirement priorities
Nice-to-have requirements are classified as high priority.
Project Execution
29. Project plan becomes outdated
The project plan isn't kept up to date during the execution phase. It quickly becomes obsolete and the project essentially runs without a plan.
30. Tasks aren't tracked
Schedule slippage isn't addressed until deadlines have passed. The project becomes hopelessly behind schedule and over budget.
31. Issues aren't managed
The project manager fails to aggressively escalate and resolve issues.
32. Scope management failure
Severe scope creep throws the project into disarray.
33. Risk realization
A risk identified in the planning phase is realized. For example, a project plan may identify a heavy dependency on a critical resource. If that resource resigns or becomes ill, the risk is realized and the project may fail.
34. Financial controls failure
The project manager fails to control the project budget.
35. Low performance
The performance of a key team member fails to meet expectations.
36. Communication failure
Project goals, objectives, progress, productivity, quality, risk and constraint information isn't transparent to key stakeholders. Expectations become out of line with project reality.
37. Low customer satisfaction
The customers (e. g. project sponsors or users) aren't happy with the project. For example, executives get the perception that the project is out of control.
Business
38. Business strategy change
New business priorities lead to project cancellation.
39. Business environment
A recession or industry event takes place that triggers project cancellation.
40. Organizational changes
Organizational changes disrupt project execution.
41. Business disruption
Project launch often requires time from key business talent (e. g. learning a new system or launching new business processes). For this reason, there is sometimes resistance to launch.
42. Low user adoption
Users refuse to adopt a new technology or process.
43. Excessive quality sacrifices
Business demands a fast, cheap project. They sign off on risks that the project will have quality issues. The result is a low quality product that's unusable.
44. Negative business results
A project that's delivered to specifications but the business results don't meet expectations. For example, a new product that decreases sales instead of improving sales.
45. Force Majeure
An act of war or nature.
Political
46. Loss of sponsorship
The sponsor changes their mind about the project.
47. Loss of executive support
Powers larger than the sponsor step in to stop the project (sponsor lacks support).
48. Project Infighting
Interpersonal conflict between team members.
49. Passive aggressive tactics
A stakeholder secretly sabotages the project.
50. Vendor management failure
Your relationship with a key vendor turns bad and project issues quickly pile up.
51. Vendor infighting
The relationship between vendors turns bitter and issues mount.
Technical
52. Naive technology selection
Business chooses technologies without understanding the full implications of their decisions.
53. Inadequate technology evaluation
Technologies are chosen without a diligent evaluation.
54. Poor architectural design
The solution architecture is flawed leading to insurmountable project issues.
55. IT governance
IT governance blocks the project. For example, the project duplicates capabilities that already exist.
56. Loss of key technical resources
Losing a key resource who has no backup.
57. Unforeseen technology dependencies
A technology dependency is identified in the execution phase that delays the project.
58. Gold plating
Developers add features to the product that aren't in the requirements. The added complexity escalates project costs or prompts users to reject the product.
59. Security vulnerabilities
Security vulnerabilities in a chosen technology trigger unforeseen risks, costs and delays.
60. Capacity planning failure
The product fails performance testing and requires hardware or software reworks beyond the project's budget.
61. Tool breakdown
Tools (e. g. development tools) are buggy or ineffective leading to delays.
62. Data quality
The data migration team discovers that data quality is low. The solution is unusable without major data quality initiatives.
63. No methodology
Development follows an adhoc process that's prone to failure.
64. Inadequate testing
Testing fails to uncover serious defects that are later detected by users (shaking confidence in the product).
130 Project Risks (List)
A reasonably big list of project risk examples.
|
|
Management principles are a set of strategies, techniques and ethics that define a management culture. |
|
Quick 90 second overview of PRINCE2 - a popular project management methodology. |
|
How Management by Objectives (MBO) transformed the role of manager from leader to bean counter. |
|
Job analysis is the process of documenting the requirements for jobs across your organization. It is an essential human resource planning activity. |
Recently on Simplicable
| What Are Management Principles?posted by Anna MarManagement principles are a set of strategies, techniques and ethics that define a management culture. |
|
|
| How To Perform A Job Analysisposted by Anna MarJob analysis is the process of documenting the requirements for jobs across your organization. It is an essential human resource planning activity. |
