There is much discussion around project failures. Looking for the root cause of failure is the approach taken by organizations seeking to establish the processes for avoiding failure in the future.
Many voices in the IT Project Failure domain reference the Standish Reports as the starting point.
These reports have serious flaws in their approach - not the least of which is the respondents are self-selected. Meaning the population of IT projects is not represented in the returned sample. Another popular misrepresentation is the software crisis. Using a 30 year old NATO Report, it is conjectured the crisis 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 serious flaw in this project failure discussion.
There are solutions looking for a problem to solve. Tools, processes, practices, vendors, consultants. But nearly always the needed Root Cause Analysis is not the starting point. Instead, the symptom is used as the target for the solution. But first let's establish the framing 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 is a standard function of program management. 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 Root Causes of failure? Here's the top 4 from research:
- Unrealistic Performance Expectations, missing Measures of Effectiveness (MOE) and Measures of Performance (MOP).
- Unrealistic Cost and Schedule estimates based on inadequate risk adjusted growth models.
- Inadequate assessment of risk and unmitigated exposure to these risks without proper handling plans.
- 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 suggesting any corrective action to any observed problem (undesirable effect), we need to know the Root Cause. Asking 5 Whys is a start, but without some framework for that process, it too 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 are describing the cause - the SMELL - of the problem.
One common offender to this tell me a story and I'll tell you a solution is the No Estimates paradigm. 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 don't know when we're done. This in turn lays the groundwork for the Top Four Root Causes of project failure listed above.
- The performance expectations are just that - unsubstantiated expectations. What is the system capable of doing? Since the system under development is not developed yet, we have to make an estimate. This is an engineering problem. What's the model of the systems functions? How do those elements interact. There are simple ways to do this. There are tools used for more complex systems. Mathematics for Dynamic Modeling is a good start for those complex projects.
- Unrealistic Cost and Schedule estimates are very common. Any business that's going to stay in business needs to know something about the cost to develop it's 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.
- Inadequate risk assessment many times 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. Continuous Risk Management Guidebook is a starting place for managing risks. As Tim Lister says Risk Management is How Adults Manage Projects.
- 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. For reducible uncertainty we need to spend money to buy down the resulting risk. For irreducible uncertainty we need margin. Both these require we make estimates because they are both about outcomes in the future. Here's a start to managing in the presence of uncertainty.
So here's the punch line. Dealing directly with the Top 4 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 to assure we have enough money, or the cost is not more than the revenue, and that doing to 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.
Estimates of risk are the very basis of risk management - managing like an adult. What could go wrong requires we estimate the probability of the risk occurring or the probability distribution function of the natural variances, the probability of impact, the probability of the effectiveness of our mitigation, and the probability of any residual risk.
Unanticipated technical issues are harder. 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 now 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.
