Root Causes of Project Failure

There is much discussion about project failures. Organizations seeking to establish processes for avoiding failure in the future take the approach of looking for the root cause of failure.

Many voices in the?IT Project Failure?domain reference the Standish Reports as the starting point.?

These reports have severe flaws in their approach—not the least of which is that the respondents are self-selected, meaning the population of IT projects is not represented in the returned sample. Another widespread misrepresentation is the software crisis. Using a 30-year-old NATO Report, it is conjectured that the situation can only be fixed by applying a method without determining the Root Cause—if there ever was one.?

These approaches can be found in?How to Lie With Statistics. That aside, there is another severe flaw in the discussion of?project failure.?

Solutions are looking for a problem to solve: tools, processes, practices, vendors, consultants. However, the needed Root Cause Analysis is nearly always a different starting point. Instead, the symptom is used as the target for the solution. But first, let's establish the assumptions for project success.

Successful execution of Enterprise IT, Aerospace, Defense, and Government Software Intensive Systems (SIS) requires management discipline to identify what “Done” looks like, provide measures of progress toward “Done,” identify and remove risks and impediments to reaching “Done,” and assure timely corrective actions to maintain the planned progress towards “Done.”?

I work in a domain where?Performance Assessment and Root Cause Analyses are standard program management functions. Increasing the Probability of Program Success is a business strategy. There are many approaches to increasing the probability of program success. But first, what are some of the root causes of failure? Here are the top 4 from the research:

1. Unrealistic Performance Expectations, missing Measures of Effectiveness (MOE), and Measures of Performance (MOP).
2. Unrealistic Cost and Schedule estimates based on inadequate risk-adjusted growth models.
3. Inadequate risk assessment and unmitigated exposure to these risks without proper handling plans.
4. Unanticipated technical issues without alternative plans and solutions to maintain programmatic and technical effectiveness.

There are dozens more from the Root Cause Analysis efforts in software-intensive systems, but these four occur most often. Before you suggest any corrective action to any observed problem (undesirable effect), we need to know the Root Cause. Asking 5 Whys is a start, but with some framework for that process, it becomes a cause for failure. A method we use is?Reality Charting. It forces the conversation to?cause and effect and prevents the?story-telling approach where Dilbert Cartoons describe the cause - the SMELL - of the problem.?

The No Estimates paradigm is one common offender of this. Please tell me a story,?and?I'll give you a solution. Estimates are conjectured to be the?smell of?dysfunction. No dysfunctions are named, but suggesting we can make decisions with No Estimates is the solution. Besides violating the principles of Microeconomics, not knowing the outcomes of our work in the presence of uncertainty means we have an open-loop control system. With Open Loop, we don't know where we're going, we don't know if we're getting there, and we need to know when we're done. This lays the groundwork for the Top Four Root Causes of project failure.

1. The performance expectations are just that—unsubstantiated expectations. What is the system capable of doing? Since the system under development has not yet been developed, we have to make an estimate. This is an engineering problem. What's the model of the system's functions? How do those elements interact? There are simple ways to do this. Tools are used for more complex systems. Mathematics for Dynamic Modeling is a good start for those complex projects.
2. Unrealistic Cost and Schedule estimates are widespread. Any business that will stay in business needs to know the cost of developing its products and when that cost will turn into revenue. This is the very core of business decision-making. Poor estimating is a Root Cause of many project failures.?Estimating?Software-Intensive Systems, Projects, Products, and?Processes is a good place to start.
3. Inadequate risk assessment often means ZERO risk assessment.?What could possibly go wrong? Let's just get started. Agile is billed as a risk management process. It is not. It provides information to the risk management process, but it alone is not risk management.?The Continuous Risk Management Guidebook is a starting place for managing risks. As Tim Lister says, Risk Management is how adults manage projects.
4. Unanticipated technical issues are part of all projects. Managing in the presence of uncertainty deals with both programmatic and technical uncertainty. Both are present in the Top 4 Root Causes. As a result of risk management, these technical issues may or may not be revealed. The uncertainties found on projects are?reducible?and?irreducible. To reduce uncertainty, we need to spend money to?pay down?the resulting risk. For irreducible uncertainty, we need a margin. Both of these require us to make estimates because they are about future outcomes. Here's a start to managing in the presence of uncertainty.

So here's the punch line: Dealing directly with the Top four Root Causes of project failure starts with making estimates—estimates of the probability of meeting the expected performance goals when they are needed for project success.?

Estimates of cost and schedule are used to assure that we have enough money, or the cost is not more than the revenue, and that the work for the needed cost will show up on the needed time, so our revenue stream will pay back that cost. Showing up late and over budget, even with a working product, is not project success.

Risk estimates are the basis of risk management - managing like an adult.?What could go wrong requires estimating the probability of the risk occurring or the probability distribution function of the natural variances, the likelihood of impact, the possibility of the effectiveness of our mitigation, and the probability of any residual risk.

Unanticipated technical issues are more complex. But if we know anything about the technical domain, we can come up with some problems that can be solved before they become problems. This is called?Design. If we know nothing about the technical domain, nothing about how to deliver a solution for the customer, nothing about the cost to provide that solution, we're the wrong people on the project.?