Monday, January 23, 2012

Five Ponderings on Why IT Projects Fail

Stakeholder satisfaction, timely delivery and staying within budget top the list of measures that indicate a project’s success.

In the United States, we spend more than $250 billion each year on IT application development, statistically, 31% of projects will be canceled before they ever get completed., 53% of projects will cost twice as of their original estimates, overall, the success rate is less than 30%. Why did the project fail?  From symptoms to root causes -what are the major factors that cause software projects to fail? What are the key ingredients that can reduce project failure?

1.     IT Project Success Definition

Stakeholder satisfaction, timely delivery and staying within budget top the list of measures that indicate a project’s success, the other success factors such as quality, acceptable ROI, whether it achieves the result that are in line with strategic objectives.

2.     IT Project Failure Definition

  • The project impaired: The project is canceled at some point during the development cycle.
  • The project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.
  • The project devalued:  IT projects are always done in the current environment and so the effect on users such as “push back” needs to be carefully considered,  the project is not defined  specifically, measurably, consistently and dynamically, to reflect the continuous change 

3.     Ten Root Causes of  IT Projects Fail

  • Business purpose of project is not well-defined and communicated.: Every IT project is the business project, clear-defined project purpose need well describe the business problems need be solved or the strategic vision need be implemented.
  • Business Plan is a lack of structure or detail, such as project management model, technical solution, resources, skills. Poor planning (not allocating time to design, testing and requirements gathering), do not capture the essential of the old adage “if you fail to plan you must plan to fail”. And you need to remember the 5 P's: Proper Planning Prevents Poor Performance. 90% planning, 10% implementation.
  • Lack of executive support: compete for priorities across various stakeholders. The politics & power play in an organization has a lot to bring to the table in the success potential of a project, especially when it impacts multiple stakeholders high up in the organizational ladder, potentially competing with each other & having conflicting priorities for the project & overall running of the organization. "Probably 90% of application project failure is due to politics!"
  • Poor execution: the failures exist because there are humans in the process. And humans make mistakes, cut corners, and never have unlimited access to all the information they need at every step in the process to make a perfect decision, over promising and under delivering by the vendor, lack of quality project management  not follow the 3C Rules (communication, coordination & collaboration).
  • Over specification: trying to cover every minute detail in an initial release - almost always results in a system which very quickly becomes obsolete because operational processes will always change once a new system is introduced.
  • Failure to adopt and adhere to a suitable project methodology. Using waterfall in an organization where the business has an agile mentality leads to failure. Using Agile without a full sense of the overall plan/roadmap leads to failure. If you have a sound methodology, and it is actually followed, then it is much harder for a project to "fail". 
  • Poor change management that does not start when the project starts, every organizational chart has a 'shadow' of movement, opinion, and power underneath it, so does every project. That undercurrent must be managed with strong relationships that outlive any project and with a team culture that is unafraid of direct questions and healthy conflict. 
  • Business initiated projects run as an interesting technical challenge, Business initiated projects may have relatively simple and sensible scope but get over-engineered by an excessively risk-averse IT department, adding so much cost and complexity that the project exceeds the cost / benefit or technical viability hurdles. 

  • Governance was missing or was skipped; no significant Project Board was developed for the major development works. Projects that compete for resources should be assessed on the metrics of the business - they should be at least ROI but could include balanced scorecard metrics; or strategic input. The focus of many IT internal methodologies is the technical delivery of the software, not the delivery of a business solution that must require business participation. 
  • Miss the components of project management processes such as standardization and institutionalization of project management processes, integration with other corporate processes (e.g., procurement, strategic planning),  prioritization of projects and application of a standard project life cycle, utilization of project portfolio techniques, and continuous improvement.
 Both business and IT are to blame for project failure. Organizations do need to establish a project management framework with four core elements: processes, organizational structure, people, and systems. An effective project management methodology is required for managing scope, time, resources, change, risk, cost, issues, configuration, quality, and communication.

4.     Twenty Failure Symptoms

  • The project is a solution in search of a problem. 
  • The solution wasn't fit for purpose or projects not being scoped properly
  • Only the project team is interested in the end result. 
  • No one is in charge
  • The project plan lacks structure.
  • The project plan lacks detail. 
  • The unrealistic project plans
  • The project is under-budgeted. 
  • Insufficient non-financial resources are budgeted. 
  • The project is not tracked against the plan.
  •  The project team is not communicating
  • The project strays from its original goals
  • Incomplete Requirements
  • Lack of User Involvement
  • Lack of Resources
  • Unrealistic Expectations
  • Lack of Executive Support     
  • Changing Requirements & Specifications
  • Lack of IT Management
  • Technology Illiteracy  

  5. Ten Project Success Factors

  • User/customer Involvement
  • Executive Management Support
  • Clear Statement of Requirements
  • Clear Vision & Objectives
  • Proper Planning defines the project carefully.
  • Realistic Expectations
  • Smaller Project Milestones
  • Scoreboard Metrics, ROI
  • Ownership
  • Hard-Working, Focused Staff
 Top management need understand that project and portfolio management are key to drive many business initiatives such as strategic planning, investment priority, capital budgeting, new product development, organizational changes, M&A, etc, the businesses understand the vital importance of project management will outperform the competitors and reap the business benefits for the long term.


You just repeat after Standish group report. These explanations explain nothing and cannot help to solve the problem. Think, human factor presents in any production process. There are ones not less complex and innovative. For example, ships construction, especially war ships.
Why are they much more successful than software projects? I'll give you just initial hint: they use drafts! All details and systems are created from drafts. Try thinking this way or try proof that the draft (or some its replacement) is totally inapplicable when it is spoken about software development

To be successful in your career, a positive interaction with people working around is a key. In a similar manner, it is extremely important to identify and manage stakeholders. Stakeholder management is important to the success of every project. Involving and engaging with the right people in a positive manner is highly important for project success.

IT projects fail on semantics, every time. Look again at the list.

John O'Gorman
Disambiguation Specialist

Post a Comment