Thursday, March 31, 2016

Reasons IT Project Fails

IT projects commonly fail at a rate of somewhere between 50% to 80% and here some reasons:

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. 

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.

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.

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 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. 

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. 

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. 

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). 

No comments:

Post a Comment