With IT now recognized as one of the top-performing and fastest-growing industries, the need for perfect and optimized project execution has never been greater. As with all large industries that comprise of a broad spectrum of projects, it can be difficult to pinpoint the exact root causes of project failure. However, by analyzing other reports on IT project failure, patterns and common culprits start to emerge.
According to the 2013 CHOAS Manifesto by the Standish Group, only 39% of IT projects succeeded in 2012.
While each project has its own unique reasons for failure, most can be connected to these three areas: poor budgeting, a lack of communication and transparency, and resistance to change.
Poor Budgeting
It will come as no surprise to anyone that money has a big role to play in the eventual success or failure of a project. Even the most financially savvy entrepreneurs and IT managers can find themselves on the receiving end of a failed project due to financial reasons.
Startups and entrepreneurs, by nature, are generally financially limited, especially in their early stages. While some startups may receive some initial financial help, the needed investments to fund the entire development process are hard to come by, as most venture capitalists require a working or near-complete application before they hand over large sums of cash.
A common decision made by startups is to choose the cheapest option available. This mistake will prove not only to be the biggest, but also the most costly. You can rarely find quality in very cheap offers, and your application MUST be built with quality in mind. The quality of an application is fundamental to its ability to perform the required tasks and operations, handle large amounts of requests, and be further extended and developed.
If your application’s codebase is built with poor-quality code, it will soon become inoperative, and even when you transfer your project from one development team to another, the time spent fixing the defective codebase will severely cut into your budget.
Another common budget-related reason for project failure is not so much do with the lack of funds, but, rather, the way these funds are managed and spent. Even if startups have more than the required funds needed to develop an application, they can soon find that the funds are not being optimized as well as they could be.
The most common reason behind poorly managed funds is concerning the payment method, often referred to as Fixed Bid. By deciding to build your application based on a fixed price, you are essentially stripping away the most critical elements responsible for a successful project.
Transparency, communication, and the client-developer relationship are all damaged by the fixed bid model, as the goals of both parties differ greatly – the developers want to produce the application as soon as possible to cash in on the unspent hours, and the client wants the most bang for their buck.
Also, with the fixed bid model it is harder to see exactly where your money is going and how much is being spent on each part, since the project is viewed on the whole instead of on a step-by-step basis.
Lack of Communication and Transparency
Having open channels of communication throughout the planning, development, and deployment phases cannot be emphasized enough, as a breakdown in communication is one of the easiest and fastest ways for a project to fail. Both parties (client and developers) need to work closely to ensure that the ideas and requirements from the client are clearly passed onto the development team.
Assumptions and a lack of client involvement lead to developers producing an application that is far different from the one the client had in mind, and it’s important to remember that a failed project isn’t just defined as an inoperative application. If the application doesn’t meet the client’s requirements or produce the results it’s supposed to, then it will definitely not be labelled a success.
Resistance to Change and Redirection
Change is the only thing that is consistent, and few know more about this than software developers. The sheer nature of software development requires constant change and redirection – both forced and intentional.
Roadblocks and issues are part of daily life when building an application, but so, too, is discovering new paths that more quickly lead to the desired results; change and redirection in software development don’t need have come from a negative reason. There are many ways to build an application, and new ideas and ways of achieving certain objectives are quite often found during the development process.
A software development team’s ability to change the project’s course relies solely on the project management method. The two most common models used in software development are Agile and Waterfall (traditional). The Agile methodologies are highly flexible in structure, and therefore allow and encourage change and redirection. The Waterfall model, on the other hand, is very linear and doesn’t allow for any change in the project’s development – each phase is completed one after the other and doesn’t return to any previous stages.
