CIO analysis: Why 37 percent of projects fail
Summary: New research identifies five important reasons that projects fail.
A study by project management consulting company, PM Solutions, identifies top causes of IT failure.
The report, called Strategies for Project Recovery (PDF), covers 163 companies roughly split between small, medium, and large organizations. On average, respondents manage $200 million in projects each year, of which approximately 37 percent are "at risk." The average company in the study therefore faces $74 million of "at risk" projects each year.
The study identifies five top causes of troubled projects:
- Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
- Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
- Schedules: Too tight, unrealistic, overly optimistic.
- Planning: Based on insufficient data, missing items, insufficient details, poor estimates.
- Risks: Unidentified or assumed, not managed.
According to the survey, the most common obstacles that interfere with recovering failed projects are:
- Getting stakeholders to accept the changes needed to bring the projects back on track-whether they are changes in scope, budget, resources, etc.
- Poor communication and stakeholder engagement; lack of clarity and trust.
- Conflicting priorities and politics.
- Finding enough qualified resources needed to complete the projects.
- Lack of a process or methodology to help bring the project back on track.
STRATEGIC ANALYSIS
This study is useful but not groundbreaking; it sheds light on a common problem, reaffirms existing beliefs on causes of failure, and brings attention to important issues.
The 37 percent failure rate is notable because it falls within the broad range of statistics (thirty to seventy percent) that most studies report, even though it is somewhat surprising the number is so low. This report did not focus on failure rates, but instead emphasized project recovery, which could have affected these specific results.
Failure rates are notoriously difficult to measure and virtually impossible to compare across multiple studies by different researchers. Therefore, consider specific failure rates as suggesting problems and relative magnitude of seriousness; failure statistics are not absolute indicators.
Related: CIO analysis: Defining IT project 'success' and 'failure'
Nonetheless, it's incredible to consider that over a third of projects in this study are likely to have serious problems. The financial impact of these failures is significant and meaningful, to say the least.
It's easy to brush aside the five causes of failure listed above, thinking they offer nothing new. However, such superficial views do not help solve the problem. It's far better to acknowledge the challenge and difficulty of aligning expectations and perceptions across a diverse set of stakeholders, which is a fundamental obstacle to project success. That's why this blog discusses change management so frequently.
CIO perspective: Acknowledge the reality of project risk -- vulnerabilities from so-called "obvious" sources represent a clear and present danger to your organization. To address these inherent risks, develop improved methods for communication, collaboration, and information sharing across silos and departments, both inside your organization and with external partners.
In addition, consider methods for making your projects more adaptive. On many projects, decision-making is a step function where information gathered over a relatively lengthy period culminates in periodic review and analysis. Reduce these decision cycle times to keep your projects responsive to changing conditions and requirements.
Solving the IT failures problem is difficult precisely because there is neither a silver bullet nor a clear target at which to aim. Forward thinking CIOs will recognize these realities and innovate by constructing a broad-based, long-term campaign to ensure that project outcomes align with organizational interests.
Update: Argentinean IT consultant, Carlos Francavilla, translated this post into Spanish, which you can read here.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Incompetent management
Bad requirements capture usually means management has assigned too much weight an analyst who has no talent.
Then the smart people leave, its clear from early on if a project will fail, they want to leave with a CV full of success.
Schedules slip, but that's not because developing software is hard, it's not, it's easy. They slip because nobody wants to rush ahead to hit the dead ends. There is no win in that situation, when you hit the dead end, *you* will take the blame for rushing ahead, as if the dead end isn't there if you don't reach it!
Planning, is meaningless if the project will fail, why rush... milk it.
Risks, well I've even had one manager who had such poor control of a project, any meeting in late beta cycles could send the spec wildly off at a tangent.... this is a guy who really knows how to snatch failure out of the jaws of success.
There's a sort of gap, one the one hand the code says one thing, the computer works a certain way and it needs to be correct because you can't fool a computer. On the other, the management *believes* the code works in a *different* way. They convince themselves their requirements capture was correct. They convince themselves the code so far is fine, and that the process will lead to success, even if every step fails.
RE: CIO analysis: Why 37 percent of projects fail
RE: CIO analysis: Why 37 percent of projects fail
have to agree with Sundowner. Why'd you think software gets released slower than hardware?
Message has been deleted.
Misunderstanding what requirements are is unrecognized culprit
More importantly, what people call requirements generally are actually high-level design of the products, systems, software they expect to create. What they are missing are the REAL, business requirements deliverable _whats_ that provide value when met, satisfied, or delivered by the products/systems/software _hows_.
REAL business requirements are not merely objectives but instead are the _whats_ that will achieve the objectives and thereby provide value.
Products, and thus their projects, turn out wrong when they don?t meet the REAL business requirements, usually because the REAL business requirements have not been defined adequately, usually because people think (and their gurus tell them) mistakenly that product/system/software requirements are _the_ requirements.
See my Artech House book, Discovering REAL Business Requirements for Software Project Success, for further explanation and ways to reduce failures.
RE: CIO analysis: Why 37 percent of projects fail
RE: CIO analysis: Why 37 percent of projects fail
RE: CIO analysis: Why 37 percent of projects fail
From a consultant's perspective
He has already spoken to 3 other consultants who gave him 3 different solutions.
Firstly the technology solution - Use these new devices called 'bow-and-arrow', where you don't need to get close to the beast to fell it
Secondly the process solution - Retain the pointy stick, yet work with colleagues such that they spook/corrale the beasts and push them into a swamp where they get stuck and are easy targets
Finally the people solution - Capture some baby mammoths and 'domesticate' them, therefore making hunting redundant and farming the norm
Clearly all solutions are viable; however some are better than others, yet some are only able to be assimilated by some people. Thag, alas, is not a farmer, and can only operate in very small family units. The bow-and-arrow is the only workable solution - yet clearly he and his clan lacks the technical expertise the build and maintain a good stock of items.
Moral of the story - let's see greater alignment between the project solution and the capability of the client!
RE: CIO analysis: Why 37 percent of projects fail
RE: CIO analysis: Why 37 percent of projects fail
Understanding the business problem and identifying an optimal solution will lead to requirements that a project can deal with.
Starting with requirements and expecting a project to deliver a solution is crazy - but it's business as usual - so are projects that don't "meet expectations"
unless we start designing things like pros in other fields ...
Now suppose I propose to you that we build a custom house in the same manner that most software projects today build custom apps. We'll hire a project manager with an MBA but zero construction experience. The manager will hire a bunch of contractors and hand them a list of requirements and maybe an artist's conception of the house. But there will be no designer and consequently no blueprint. How would this project fare? Most reasonable people, I think, would give the project a zero percent chance of success.
I've been in this business thirty five years and every project that I've seen fail was due to a failed design (which includes the ever-popular "no design"). More recently I find projects staffed with people who simply have no conception that software has an underlying design (whether you design it or not), and that most "designs" are simply intractable. Show me a project that's going down the tubes, and I'll show you a design that could never be implemented, no matter how many contractors and managers you throw at it.
Your five top causes here seem to imply that there's nothing between requirements and a finished product. Until our industry adopts the same commonsense measures that other industries have practiced for decades or even centuries, we will see a landscape littered with failed software projects, gasping for air like the fish out of water that they are.