a compilation from LinkedIn forum IASA: The Global IT Architect Association by Jan Popovic

Top Reasons why Projects Fail
Instead of focusing on the reasons why the project fail, it is important to be focused on the reasons of SUCCESSFUL ACCOMPLISHMENT the project in each stage:

1. Meet the deadline
2. Meet the budget
3. Meet the functionality
4. Without major bugs
5. Well accepted by users
6. Deliver business values (ROI)
7. Complete & updated documentation

On the other hand, why projects fail?
It is also important to address this issue. The project team, the suppliers, the customers and other stakeholders can all provide a source of failure, but the most common reasons for project failure are rooted in the project management process itself and the aligning of IT with organizational cultures (Tilmann and Weinberger, 2004).
The failure may be identified in estimation mistakes (poor planning, vague requirements, or unclear project goals and objectives, and project ever-changing requirements during the project development as key factors in project failures.

The following list the primary causes for the failure of complex IT projects:

- Poor planning
- Unclear goals and objectives / Vague requirements
- Objectives changing during the project / Project creep
- Unrealistic time or resource estimates
- Lack of executive support and user involvement
- Failure to communicate and act as a team
- Inappropriate skills

PLANNING
Without adequate planning, it is difficult to really understand what it will take to complete a project successfully. Lack of planning leads to inadequate preparation, unexpected problems, and poor execution of milestone tasks.

Poor planning is a worst practice because:

If you don't have written plans, you are using your memory to keep track of things, what is unreliable and dangerous. Planning is an excellent tool for getting things out in the open. Good planning forces you to think about your projects before you set about doing it and to put your thoughts down on "paper". This alone can help you prevent many project failures and delays.

Without plans, it is difficult, sometimes even impossible to get a clear picture of all the things that you are working on and what still needs to be done. ROAD MAP Planning allows you to identify all your projects and tasks and gain a much better understanding of what it will really take to complete them. Without planning, you won't have a clear idea of what you need to do and you won't be able to prioritize your time properly. How can you prioritize your time if you don't even understand what you are trying to accomplish? When you don't have clear priorities, you are much more vulnerable to distractions and unexpected events.

Lack of preparation - Imagine that you and your friends are going on a two-week trip to the wilderness. Would you do any planning? Of course you would. You plan so that you are fully prepared for the trip: you know where you are going, how to get there, how to get back, what obstacles to avoid, what type of terrain you will be facing, how many and what kind of supplies you need to make your journey, etc. Reasonable people would never venture out into the wilderness without proper planning and preparation because it could easily cost them their lives. The location and duration of the trip makes a big difference in the type and level of preparation that is required. Lack of adequate preparation in your own projects can easily cause them to fail or fall deep behind schedule.

Lack of risk management - Without proper planning, it is difficult to anticipate and avoid major problems and risks. Without actively monitoring and avoiding these risks, they can easily sidetrack or even cause your project to fail.

Planning is one of the most important activities in time management, it has been estimated that every minute spent planning can save three in execution, and yet it is one of the least practiced.
In fact, for most people, this worst practice is not poor planning, but no planning at all.


-------------------------------------------------------------
Requirement changes during the project development
-------------------------------------------------------------
Many project managers had the feeling that their IT project features and requirement would never stop growing. Often the "initial" requirements for the software to be developed are changed more than one time after the development began. The Software and similar IT projects suffer from two classical problems in project management:
* Scope creep
* Feature creep.
Scope creep refers to uncontrolled and unexpected changes in customer desires and expectations as a project development progress, while feature creep refers to uncontrolled introduction of new of features to a system with a wrong assumption that one small feature will add nothing to cost, schedule or complexity.
Some Project managers do not understand project trade-offs, and it will result in not making correct decisions regarding objectives and priorities on the basis of rational insight.
Often staying committed to the initial requirements will result in failure when the requirements of a project changes during the newly arrised issues which have not been initially envisioned. So some development flexibility and development roadmap milestone adjustments are often required.

-----------------------------------
Top Reasons why Projects Fail?
-----------------------------------
Top reasons encountered which have led to Project failures.

1.a Absence of thorough problem/solution analysis, i.e. wrong comprehension of the problem. Poor alignment of Solution with Problem - i.e. design of solution doesn't address the problem adequately.

1.b Ambiguous requirements - poor, vague and ambiguous problem definition

1.c Wrong approach to solution

1.d Poor Analysis that include overall planning issues like: Risk, Stakeholder, Scope, Cost/Budget, Schedule, Development Road Map


2.a People management and communication issues
2.b Lack of clear goals, lack of leadership.
2.c Lack of communication within the team
2.d The right people in the project
2.e Poor communication between client and development team
2.f Lack of task assignment and quality control on delivery of each task and feature
2.g Incompetent team
2.h Risky customers *budget, legal, development timing or vague requirements issues, also Lack of Transparency
2.i Poor Management that include project management and people management

3. Lack of fail-safe planning in every task

4.a Unrealistic deadlines or Under estimated deadlines
4.b Unstated or unclear goals to every member of the development team




The most successful activities are usually those done without management oversight.

- This page can give a good conclusion:
http://www.projectperfect.com.au/info_it_projects_fail.php
- Poor planning
- Unclear goals and objectives
- Objectives changing during the project
- Unrealistic time or resource estimates
- Lack of executive support and user testing during development

- It seems that most failure reasons listed or described here are, in most cases, more symptoms than causes. Why does a project get poor planning, unclear goals and objectives, changing objectives, unrealistic time or resource estimates, lack of executive support and user involvement, failure to communicate and act as a team, inappropriate skills, inappropriate tools, bad management, lack of stake holders commitment, etc.? They all seem to confirm that it is the wrong project, in the wrong context, with the wrong motivations, or else, why would it be so bad? It is quite possible that some resources are not good for a project but if the project and its motivations are right, there should be enough good resources to pick up the slack. Why would a project requirements exceed available resources by so much that it fails and that this could not be foreseen, if not because it was the wrong project, planned for the wrong reasons? Of course, too much/many resources can also corrupt any otherwise valid project or set of resources...

- McConnell's "Software Estimation Demystified"

REDUCING COMPLEXITY
If you want to succeed, try and simplify what you are trying to do.

- communication, scoping, ownership, accountability and poor management. As architects we must ask why it seems so hard to "communicate" as this in my opinion is the root of most failures. The challenge appears to be to communicate the correct information to the correct individuals and most important get agreement - don't just assume that because you have sent an email that someone agrees. As architects we must be forceful in our messages and bring everyone along in the project -- where we see an issue we must raise concerns -- we are part of the leadership and ultimately response for failures.


Otherwise there are lots of technical, planning, scoping and other resource issues that influence how and whether a project can ever be delivered. But the key factors in failures are more due to misalignment, or wrong solution to wrong problem, or wrong solution for wrong customer.

Top reasons for project failure? Depends on what you call failure. There are a hundred definitions of what it means to fail.

If failure means "inability of a customer to accept delivery of expected benefits on time and on budget" then I'd have to list the top three reasons to be:

a) poor relationship between expected benefits and solution that is supposed to deliver them (poor alignment, poor design, infeasible choices, design-by-politics)

b) poor preparation of the execution team to deliver (unqualified staff, poor project management, under-resourced, over-stretched, poor communication within team, poor relationship to client), and

c) poor preparation of the customer to use the resulting system (unprepared users, poor flexibility management, poor resource planning, conflicts with other projects, poor technical infrastructure, etc).


Conclusions

The past failure need not discourage project managers from future efforts. Past examples of IT project failures gives us the opportunity to point to the relevant lessons that can be derived from recognizing areas where IT projects is more likely to fail.

Project managers can position themselves to reduce the possibility for project failure by considering the following recommendations:

* Project Management Software Make sure to plan before starting the development or implementation.
* Pay attention to tasks in the critical path.
* Set up the necessary processes to calculate and inform the risk.
* Ensure that the IT project has clear objectives.
* Understand project trade-offs when making decisions regarding objectives change.
* Use the duration instead of the time on task to estimate schedule.
* Avoid using linear approximation when estimating time or resources.
* Get the support from the executive management and ask them to be open if they have any reservations about the project.
* Ensure and communicate regular about the progress, even if it seems invisible.
* Require that users participate in design and implementation of your project
* Make sure you have the appropriate planning, communication, and technology skills.

These recommendations, along with solid project management, can reduce the risk that an IT project fails.

..................................................................................................................
In a landmark 1995 study, the Standish Group established that only about 17% of IT projects could be considered "fully successful," another 52% were "challenged" (they didn't meet budget, quality or time goals) and 30% were "impaired or failed." In a recent update of that study conducted for ComputerWorld, Standish examined 3,555 IT projects between 2003 and 2012 that had labor costs of at least $10 million and found that only 6.4% of them were successful.
Combining the inherent problems associated with very large IT projects with outdated government practices greatly increases the risk factors. Enterprises of all types can track large IT project failures to several key reasons:
-- Poor or ambiguous sponsorship
-- Confusing or changing requirements
-- Inadequate skills or resources
-- Poor design or inappropriate use of new technology
Strong sponsorship and solid requirements are especially difficult to come by in a political environment (read: ObamaCare), where too many individual and group stakeholders have reason to argue with one another and change the project. Applying the political process of lengthy debates, consensus-building and multiple agendas to defining project requirements is a recipe for disaster
.................................................................................................................