When you hear project failure statistics, and no Root Cause for those numbers, there is no hope that any suggested corrections can be credible. As well when you hear those statistics, many times those numbers have no credibility themselves to start with.
This first post is a follow-on from the posts Root Cause of Project Failure, Root Cause Analysis, Discovering the Root Cause - The 5 Whys, Turning Editorials into Root Cause Analysis, Observation Issues and Root Cause Analysis, Without a Root Cause Analysis, No Suggested Fix Can Be Effective.
But before going further, let's establish the definitions we need to understand and apply Root Cause Analysis needed to discover the corrective and preventive actions to increase the probability of project success - especially Software Project Success. AND to learn how to detect the bogus approaches to solving problems we see everywhere in software development.
- A Correction fixed the immediate non-conformance. Corrections can stop the bleeding but do not necessarily address the underlying reasons for the wound.
- A Corrective Action addresses the cause of the non-conformance do it does not reoccur. Corrective actions are put in place to address the "reason" for the bleeding and prevent additional wounds from occurring from the same cause.
In some instances, an isolated non-conformance may require only a correction. This is an example of Stop Doing Stupid Things on Purpose.
- A Cause is an answer to a why question. It should be stated as a noun and verb it comes in two forms - an action cause and a condition cause.
- Root Cause is any cause in the cause continuum that is acted upon by the solution so that the problem does not recur. It is not the Root Cause we seek, it is effective solutions that are sought.
- Root Cause is the fundamental initiating cause on a causal chain leading to a failure of a process which results in a recurrence of the problem.
- Root Cause is the factor that, when addressed and corrected, ensures that the problem does not come back.
- Root Cause Analysis is a systematic documented approach to arrive at the true Root Cause of the process problem.
This last statement needs further clarification,
- Actions are momentary causes that bring conditions together to cause an effect.
- Conditions are causes that exist over time before an Action brings them together to Cause an effect.
- A fact is a cause supported by evidence. Facts outside of a causal relationship have no value.
- Evidence is data used to conclude something. Evidence comes in different quality levels - sensed by the five senses, inferred, intuited, or emotionally sensed.
- Event-Based Problems are centered around people, objects, and rules that occur in time and space. These type of problems are distinguished from rule-based problems by having more than one possible solution.
- Rule-Based Problems do not require people, object, or time and space and always have a predefined right answer.
There are some more definitions needed before we get started,
- Stakeholder is a term taken from Dr. Stephen Covey's Principle-Centered Leadership, describing all persons who have a stake in the success or failure of an enterprise or group.
- Common Sense is the common feeling of humanity. Common sense is an illusion that results from ineffective problem-solving.
The True problem must be identified before any corrective or preventive action can be taken.
The causal chain of Actions and Conditions must be traced back to the initiating root cause. The outcome is not likely the root cause. An underlying factor or root cause is determined by a set of multilayered “why” questions or some other predefined method.
To the Big Foot hunter, all things point to the existence of a Sasquatch. If you've already decided what the cause of the problem is before you start looking for the Root Cause, you have inadvertently distorted the data to support your hypothesis.
The classic example is in Animal Planet's Finding Bigfoot where the investigators have pre-determined the cause of the occurrence. To them, any footprints found in the forest are Big Foot's prints. When the hunter state Sasquatch can disguise their voices to sound like other animals. So if you heard a coyote, it could be a Sasquatch ..."
Begin with an open mind, don't start looking for Big Foot.
An example of a Root Cause Analysis is Benjamin Franklin's Why Analysis †
- For want of a nail a shoe was lost,
- For want of a show a horse was lost,
- For want of a horse a rider was lost,
- For want of a rider an army was lost,
- For want of an army a battle was lost,
- For want of a battle the war was lost,
- For want of the war the Kingdom was lost
- All for the want of a nail.
Why All This Setup?
There is a group in our software development community that has a predefined solution to almost any common problem that - projects run over time and cost and don't provide the needed business value. This solution is usually proposed before the root cause is discovered.
#NoEstimates is the prime example of a solution looking for a problem to solve before any causes have been identified.
Part 2 will take these Root Analysis principles and apply them to actual software problems, and the fallacies that simple and simple-minded corrections will fix anyting - stay tuned.
References
† This proverb comes in many variations over the centuries. It describes a situation in which a failure to anticipate or correct some initially small dysfunction leads by successively more critical stages to an egregious outcome. Benjamin Franklin repeats it, in Poor Richard's Almanack, June 1758.
Anytime you hear the suggestion of any solution to any problem must have a set of principle on which to base that solution. When you hear a solution without references - reference that is not self-referenced or simple-minded reference, stop listening or reading. This approach is core to any credible improvements in our complex software development domains. This approach separates personal anecdotes from actual corrective and preventive actions to increase the probability of project success.
Papers
- Apollo Root Cause Analysis: Effective Solution to Everyday Problems Every Time, Dean L. Gano, Atlas Books, 2007.
- “Research on information systems failures and successes: status update and future directions,” Yogesh K. Dwivedi, Information Systems Frontiers, 17(1), pp. 143‒157.
- “What factors lead to software project failure?” June Verner, Jennifer Sampson, and Narciso Cerpa, Second International Conference on Research Challenges in Information Science, 2008.
- “A Taxonomy of an IT Project Failure: Root Causes,” Walid Al-Ahmad, Et Al, International Management Review, Vol. 5, No. 1, 2009.
- “Why Do Information Technology Projects Fail?” Adam Alami, Conference on ENTERprise Information Systems / International Conference on Project Management / Conference on Health and Social Care Information Systems and Technologies, CENTERIS / ProjMAN / HCist 2016, October 5–7, 2016.
- “The Root Cause of Failure in Complex IT Projects: Complexity Itself,” Kaitlynn M. Whitney and Charles B. Daniels, Complex Adaptive Systems, Procedia Computer Science, 20 (2013), pp. 315‒330.
- “Proposition 22: The Premortem Technique,” Olivier Serrat, Knowledge Solutions and publication of Asian Development Bank, March 2012/113.
1712. “The True Meaning of Root Cause and Root Cause Analysis (RCA),” Gary Jing, 2013 ASQ World Conference. - “Automated Root Cause Isolation of Performance Regressions during Software Development,” Christopher Heger, Jens Happer, and Roozbeh Farahbod, ICPE ’13, April 21‒24, 2013.
- “Agile process Smell and Root Cause Analysis,” Dave Nicolette, International Conference on Agile Processes and Extreme Programing in Software Engineering, 2009. pp. 145‒195.
- “Rationale mapping and functional modeling enhanced root cause analysis,” Marco Aurisicchio, Rob Bracewell, and Becky L. Hooey, Safety Science, Volume 85, June 2016, Pages 241–257.
- “The Analyzing Method of Root Causes for Software Problems,” Tomomi Kataoka, Ken Furuto and Tatsuji Matsumoto, SEI Technical Review, Number 73, October 2011.
- “A Case Study in Root Cause Defect Analysis,” Marek Leszak, Dewayne E. Perry, and Dieter Stoll, ICSE 2000.
- “What Are Problem Causes of Software Projects? Data of Root Cause Analysis at Four Software Companies,” Timo O. A. Lehtinen and Mika V. Mäntylä, 2011 International Symposium on Empirical Software Engineering and Measurement.
- “Development and evaluation of a lightweight root cause analysis method (ARCA method) – Field studies at four software companies,” Timo O. A. Lehtinen, Mika V. Mäntylä, and Jari Vanhanen, Information and Software Technology, Volume 53, Issue 10, October 2011, Pages 1045–1061,
- “Root Cause Investigation Best Practices Guide,” Roland Duphily, TOR‒2014‒02202, The Aerospace Corporation, 30 May 2014.
- “Root Cause Investigation (RCI) Best Practices Guide Product Overview, Aerospace Report TOR‒2014‒02163, May 8, 2014.
- “SCRAM: A Method for Assessing Risk of Schedule Compliance,” Adrian Pitman, Angela Tuffley, and Betsy Clark, DMO General Manager Systems, Australian Government, ASWEC 2013.
- Schedule Compliance Risk Assessment Methodology (SCRAM) Combined Process Reference Model and Process Assessment Model, Released Version 2.0, Australian Government, Department of Defence, Defence Material Organization, Version 2.0 29 May 2013.
- “Root Cause Investigation (RCI) Best Practices Guide Product Overview,” Aerospace Report TOR‒2014‒02163, May 8, 2014.
- “Development and evaluation of a lightweight root cause analysis method (ARCA method) – Field studies at four software companies,” Timo O. A. Lehtinen, Mika V. Mäntylä, and Jari Vanhanen, Information and Software Technology, Volume 53, Issue 10, October 2011, Pages 1045–1061.
- "Root Cause Analysis and Corrective Actions for Project Managers," Gareth Byatt, Gary Hamilton, Jeff Hodgkinson, and Dule Oaks.
- Effective Root Cause Analysis and Corrective Action Process, Branislav Tomic and Vesna Spasojevic, Journal of Engineering Management and Competitiveness, Vol. 1, No. 1/2, 2001, pp. 16-20.
Books
- Root Cause Analysis Handbook: A Guide to Efficient and Effective Incident Investigations, 3rd Edition, Lee N. Vanden Heuvel, Donald K. Lorenzo, Randal L. Montgomery, Walter E. Hanson, and James R. Rooney
- Root Cause Analysis: The Core of Problem Solving and Corrective Action, Duke Okes, ASQ Press.
- Root Cause Analysis: A Step‒by‒Step Guide to Using the Right Tool at the Right Time, 1st Edition, Matthew Barsalou, Productivity Press.
- Root Cause Analysis: Simplified, Tools and Techniques, 2nd Edition, Bjørn Andersen and Tom Fagerhaug, ASQ Quality Press.
- Root Cause Analysis Handbook: A Guide to Efficient and Effective Incident Investigations, 3rd Edition, Lee N. Vanden Heuvel, Donald K. Lorenzo, Randal L. Montgomery, Walter E. Hanson, and James R. Rooney
- Root Cause Analysis: The Core of Problem Solving and Corrective Action, Duke Okes, ASQ Press.
- Root Cause Analysis: A Step‒by‒Step Guide to Using the Right Tool at the Right Time, 1st Edition, Matthew Barsalou, Productivity Press.
- Root Cause Analysis: Simplified, Tools and Techniques, 2nd Edition, Bjørn Andersen and Tom Fagerhaug, ASQ Quality Press.
