The Top Reasons for Software Project Failure

Every IT project is a business project. 

The success story is perhaps similar, but in terms of failure, there are so many influencing factors (large and small) on negative project outcomes, what’re the aspects of analyzing the top reasons for software project failure.  

Communication: Speaking the common business language, not the domain dialect gives executives the foundation for better strategic conversations. If they have a better understanding of how coding and data process work, they get realistic expectations of their speed and their power. If executives are able to think in the same terms, it will enable them to have the context in which to make business decisions. The same applies to customers. If they also don’t speak the same language, requirements specifications will be problematic from the beginning. With the same language, they have the context in which to make business decisions - and that provides greater opportunity for innovation. A very subtle cause is the misalignment in what business leaders expect a technology to provide and what the technology truly can provide. That is common in recognition-oriented technologies, where the evolution of the technology isn't as advanced as the business expects.

Planning: Poor planning on the scope and breadth of a project tend to cause stumbling blocks with less and less ability to recover from the glitch or set back. Delivery in phases requires triage of requirements and steps of progress evident to the enterprise. Risk planning necessitates options when schedules hit hurdles which are inevitable did too many variables internal and external to our control. In addition, lack of insight into emerging technologies limitations and strengths. Planning is thwarted when user experiences are assumed to be the same when in fact there are different ones due to different requirements of mobile users, those in-house and those remote and off the grid. Success and failures are mostly linked to value/added. Projects bringing measurable values or driven by regulation and compliance are likely to succeed more than vision and strategically driven projects. Management could take a different perspective and attempt to identify the critical success factors that have a major contribution to success, and that if not present, pose a serious risk to the project.

Mindset, skills and resources. Inadequate skills and resources are always a problem; but one should never attempt to start a project unless you have the necessary skills and expertise in place, it's a recipe for disaster, Better doing nothing than screwing up from day one. Poor design again is a question of getting the right person, with the right skills in place so that isn't hard. The main reason for IT projects failure is that they are executed by people with a (great - sometimes at least) technological mindset. However, they don't see the need to execute the project with a business mindset, or if they do, they don't know what it means and what it really implies. Or the management driving force tends to alienate the entire process either forcing something to move faster during a problem with the plan or not engaging enough to ensure the problem is solved.

Change Management: Ensuring the customer, business unit, & support staff are intrinsically involved in change provides the greatest amount of pressure for a successful project. Overall, the root problem of change does not necessarily stem from funding but from the failure of the process team to ensure all key stakeholders involved understand and want to assist with the change involved in a new project. Once you successfully finish a project on one site, it is imperative you use this knowledge to show case the ability of the product and/or the process to down stream sites or partners receiving the change in the future. Innovation is a requirement; even when it is a well-defined project with known technology.

Commitment: The reasons for the failures may come in many folds such as planning, scoping, resources..etc.; however, one common element is the commitment of key resources to the project, when one or more key resources are committed, skilled, and passionate about the project, it is a sure shot; but when you only have a team that is there to finish hours in a day, it is a project that is known to fail. This can be detected at any stage of the project, provided there is a good technical leader who can assess effectively.

Governance: Lack of governance is a very common problem too and can lead to scope creep but can cause a plethora of problems and is something that companies should be looking at seriously in the current financial climate where they literally cannot afford to allow projects to fail. Governance should be a living thing and should not be, as it is in most companies at present, a set of rigid statements that do very little to help anyone working on projects; and they are generally compiled by senior execs, to allow them to say that they have governance in place, in most cases it is a cop out, as they don't. Companies following this course of affairs are building up big problems for themselves, they need to sit down with IT and Business people and rethink the whole governance thing seriously to make it practical and beneficial.

Metrics: The main reason is that too many of those projects doesn't have "business sense", and are not tied to specific business goals and “SMART” measurement principles. Many IT projects require alternatives to financial measures (ROI, NPV, PP, IRR) of success and the negative perception of seemingly failed IT projects outcomes (based on hard measures) could be tempered through the (additional) adoption of more holistic approaches to successful performance such as Information Economics and the Balanced Score Card. These approaches include measures such as: 
- the lifetime value of a project;                                                                                                                - the maturation of a learning organization (starts with building knowledge and corporate memory);    - the evolution of capabilities around core competencies, for competitive advantage and ultimate sustainability 
- the level of contribution to operational excellence 
- the level of contribution to strategic positioning 
- the level of contribution to the mission 
- the level of organizational impact 
- the level of reduction in complexity of EITA

By in-depth understanding the top reasons of software project failure, management can also change the angle to sum up the success factors of project delivery:                                                                   
1) Alignment of project outcomes to business goals and strategy 
2) High-level management oversight of the project 
3) Complete project plan 
4) Sense of urgency relating task completion to project milestones 
5) Proper resourcing in terms of both number and fit for the project 
6) Scope control / Effective change control to meet users need at the end, not the start point.              
7) SMART metrics and KPI to keep track of progress and ultimate business goals and strategy.

Posted in: Lessons from Failures,Project Management