David Kullman talks to ProductTank NYC about why most projects are doomed to fail right from the very start. David is a Partner and Development Manager at CitrusByte, working with both large corporations and startups to develop innovative software solutions to challenges they may be facing.
IT Project Failures – The Statistics
In 1995, IT spending amounted to around 250 billion dollars in the US alone. In 2015, the worldwide spending in IT was 3.4 trillion dollars. If the majority of projects succeeded, that money would have been well-spent. Unfortunately, that is not the case.
Only about 29 percent of projects ever succeed. Of the remaining, 52 percent are heavily challenged, and 19 percent are cancelled all together. What that means is of the 3.4 trillion dollars that was spent worldwide in 2015, about 2.4 trillion dollars was wasted on challenged or failed projects.
David goes on to explain that on average, successful IT projects are 222 percent late and 189 percent over-budget. Plus, once they are finished, most projects only see about 61 percent of their original scope being completed. Projects are taking twice as long and costing twice as much to only meet half of the original goal.
Why your project is doomed to fail
The process of starting a new project can shed some light on this. When the idea for a new project is hatched, people can be excited. Past failures seem distant because this new project seems different. They look for new methods that they’ve heard of and have been successful. Long-term concerns can develop early on, but action isn’t taken due to short-term focus. After the first few months, dates start to slip and expectations aren’t met. People start to realize that deadlines won’t be met and quality is missing. As they realize that it’s too late to fix things in the original timeframe, panic sets in. Eventually, the project fails despite new and improved methods and technology. To back this up, a study by IBM showed that 54 percent of projects fail because of project management, while only 3 percent fail due to technical issues.
The Size of the Project
The size of the project is partially to blame for failures. A study conducted by CHAOS Report showed that the larger a project is, the more likely it is to fail. This is mostly because smaller projects have less people involved, which means a tighter system of communication, easier access to resources, and less barriers. Brooks’ Law can support this, stating that “adding manpower to a late software project makes it later.”
Lack of Planning
Size is not the only contributing factor to projects failing. Another major cause is a lack of planning. Either the team doesn’t have the expertise or experience needed to plan properly, or planning is cut short to save time and resources. Often, this leads to a month-to-month outline, where each month is focussed on a certain iteration of the project.
Frequently, developers will assume that the least expensive approach is always the best one. This often leads to cutting corners on their best practices, which then leads to severe shortcomings. Worst of all, there is often a delayed impact, meaning those shortcomings aren’t apparent until it is too late.
David states that investing in the right team for a project, or choosing the project based on the team’s expertise and experience, can go a long way in terms of the project succeeding.
People tend to be much better at coming up with ideas than sticking to plans. Because of this, it can be difficult for team members understand how and why plans change and certain ideas are dropped. David explains that there needs to be a vetting process in place for agreeing on an idea, and sticking to the plan. That way even though people may not like the idea, they can still understand and believe in the process and be fully vested in the project.
David explains that the point to his presentation was not to simply teach how to make your project succeed, but rather, how to setup your project to best avoid failure. In short, his three major pieces of advice are to plan large projects just as you would smaller ones, invest wisely as opposed to minimally, and use a cadence-based planning model with economic prioritization.