Why 50% of IT projects fail, and how to NOT let that happen to you
The history of project management is somewhat similar to that of the production of matches. Initially, scientists had gotten it all wrong: matches were toxic, explosive, and huge in size. It wasn’t until two Swedes, Gustav Erik Pasch and Johan Edvard Lundström, came up with the red phosphorus prototype that matches became the safe commodity that we use today.
Software projects seem to follow the analogy, if distantly. Some 50 years since the inception of project management, more than 50% of IT projects still fail because they run out of time, resources, funds, etc. Will there come a day when we’ll be able to plan and execute projects successfully? We’ll live and see.
Preventing project management failure
While the majority of modern companies realize they need a mature, best practices-based process for carrying out software projects, many don’t know where to start. Below, I’ve gathered some useful stats that point to the most critical aspects of project management that probably need to be addressed first.
Organizations that invest in proven project management practices waste 28 times less money because more of their strategic initiatives are completed successfully.
Source: PMI’s Pulse of the Profession Survey, 2017.
77% of high-performing organizations* have actively-engaged project sponsors, while only 44% of low-performing organizations do. Source: PMI’s Pulse of the Profession Survey, 2017.
*As per PMI’s definition, a high-performing organization is a company that completes 80% or more projects on time, on budget, and meeting original goals. In a low-performing organization, only 60% or fewer projects hit the same marks.
46% of CIOs say that one of the main reasons IT projects fail is weak ownership. Source: The Harvey Nash/KPMG CIO Survey, 2017.
33% of IT projects fail because senior management doesn’t get involved and requirements/scope change mid-way through the project. Source: A Replicated Survey of IT Software Project Failures by Khaled El Emam and A. Güneş Koru, 2008.
78% of respondents feel that business is out of sync with project requirements and business stakeholders need to be more involved in the requirements process. Source: Doomed from the Start Industry Survey by Geneca, 2011.
45% of the managers surveyed say business objectives are unclear to them. Source: Doomed from the Start Industry Survey by Geneca, 2011.
Companies that align their enterprise-wide PMO (project management office) to strategy had 38% more projects meet original goals than those that did not. They also had 33% fewer projects deemed failures. Source: PMI’s Pulse of the Profession Survey, 2017.
According to the same research, a majority of companies either lack the skills or fail to deploy the personnel needed for strategy implementation.
40% of CIOs say that some of the main reasons IT projects fail is an overly optimistic approach and unclear objectives. Souce: The Harvey Nash/KPMG CIO Survey, 2017.
Poor estimation during the planning phase continues to be the largest (32%) contributor to IT project failures. Source: PwC 15th Annual Global CEO Survey, 2012.
Projects with effective communication are almost twice as likely to successfully deliver project scope and meet quality standards than projects without effective communication (68% vs 32% and 66% vs 33%, respectively.) Source: PwC 15th Annual Global CEO Survey, 2012.
As you can see, while the research mentioned above comes from different sources and has different timestamps on it, it covers a similar scope of problems. Hence, we can single out some key factors that can have major impact on your project.
Professional PM/PMO needs to be there
Research data indicates that having someone take care of project management for you professionally correlates strongly with successful project outcomes. After all, there’s a reason so many companies employ Product Owners, Scrum Masters, Agile coaches, and other project management personnel.
A lack of explicit product ownership is a recipe for disaster
In the old Waterfall model, it was the Project Manager who single-handedly managed the project. With the new Agile way, we now have self-organizing teams where everyone is their own manager. Plus, there’s the Product Owner to keep the eyes on the business aspect and the Scrum Master to facilitate the process.
The new paradigm helps ensure the product is economically profitable and not just built to a specification. However, if the product does not have a dedicated owner, this is less likely to happen.
Business people (stakeholders) need to be involved
As a rule, senior management is too busy to get directly involved with the project, and that’s a shame. When there is a lack of such involvement, the requirements are not clearly communicated and changes are made late into development, which can even derail the whole project at some point.
The person responsible for providing sufficient C-Suite oversight is called a product sponsor. Unlike the Project Manager or the Product Owner, it’s not a full-time job, but it’s important that someone within your organization is available for communicating and clarifying strategic vision to the team from time to time.
Requirements should be aligned to business goals
Closely connected with the above two points (#2 and #3) is the idea that insufficient stakeholder involvement and the absence of a product owner (who is, essentially, your “voice of business”) may lead to misalignment of project requirements to the product's business goals.
Requirements and scope need to be accurate
Many companies have learned (and this is especially true of large enterprises that have enough data to draw such conclusions) that when developers and business representatives take part in planning activities, this makes estimates more accurate. In addition, the shorter your release cycle, the bigger the odds that your estimate will be spot-on.
While every software project is unique, there are common problems that frequently lead to project failure. These include weak product ownership, little involvement of senior business execs, misalignment of business goals and development, inaccurate (overly optimistic) estimates, and making changes mid-way through the project.
with ObjectStyleSee our work