The "Point Nine To The Tenth" (.9^10) situation and using math to drive organizational implementation.
Jeff Hulett, November 28, 2020
Background
I first heard the “point 9 to the tenth” (.9^10) (1) situation statement used by Richard Fairbank while his company was implementing a new loan system. Mr. Fairbank is the CEO and Founder of Capital One. He was mathematically describing serial step processes and the probability of successful project completion. His point was, the more dependent steps in project implementation and/or the lower the available step precision; then the lower the chance of completing the planned project.
As you can see from the graph, the expected outcome is non-linear, both based on the number of steps and the probability of successful step completion (or precision). So, if implementing a new loan system takes 10 serial steps to implement it, and each step has a 90% chance of successful completion, then there is a good chance of completing the loan project, correct? As you can tell from the graph, the answer is a resounding NO! There is only about a 35% chance of successful project completion, and each incremental step decreases the chance exponentially. (project success = .9^10= 35%)
Project Implementation Risk Principles
One can generalize this situation statement for all projects. From a process implementation risk management standpoint, this leads one to manage risk by:
Decreasing the number of dependent serial steps (2),
Increasing the success probability of each step, and
Managing the risk severity associated with the project outcome.
These risk management principles may or may not always be practical, but good to keep in mind when planning an important project. Also, we can actively apply .9^10 thinking in our day-to-day life. Please see the appendix for examples, Managing Family Laptops and Managing Personal Devices. The first 2 risk principles are specific to the project's implementation. That is, whether the project will get implemented accurately and in the time and cost promised. The last risk principle (Managed Severity) goes beyond the implementation and to the ongoing operation supported by the project implementation. Before jumping to .9^10 examples, we will discuss Managed Severity planning for the ongoing operation.
Managed Severity for the ongoing operation
Any project is supported by operation-specific business requirements. Designing and implementing a capability that manages ongoing operations risk severity appropriately is critical. Keeping with our Capital One preamble, the following is a Loan Origination System (LOS) example for considering Managed Severity.
Most loan systems have 2 major goals, both of which focus on data, the banking industry raw material:
Provide a current customer-focused experience to provide speed, quality, and transparency. This is facilitated by "customer-focused data."
Provide a future customer-focused experience to provide product knowledge to improve future products and channels. This is facilitated by "analytical-focused data."
You may be thinking, "data is data, what difference does it make from a risk severity standpoint?" The answer is it makes a tremendous difference. From a business organization standpoint, the current customer advocates are the sales, production, compliance, and secondary marketing associates. The future customer advocates are the marketing, credit, portfolio management, and data science associates. Each has a different data need and data timing. As such, a best practice is to keep separate data repositories. That is a separate data repository for the current customer advocates and a separate data repository for the future customer advocates. Separate data repos are redundant, but redundancy is managed severity's best friend! The cost of disk space and processing power is inexpensive compared to the challenge of managing the same repo for different advocacy groups with very different needs. Plus, the redundancy can be part of a data disaster recovery or fail-over.
The moral of the story, the business and technology folks need to work closely together to design and implement a Managed Severity- enabled capability. This will take insightful operators and capable IT professionals.
.9^10 Situation Examples
When we think of a loan system, the severity of missing the project implementation goal is relatively mild. It probably means the project will be a little more expensive or take a little longer to implement. Other than being mildly annoying to shareholders and those dependent on the new system, this result is not the end of the world.
On the other hand, let’s discuss the Space Shuttle program. In 1986, the Space Shuttle Challenger crashed. Tragically, the missed project implementation goal was the end of the world for 7 astronauts. This occurred because of the failure of a rubber O ring. The generalized .9^10 problem for the Space Shuttle program is significant, in terms of serial steps, needed precision, and the severity of the failure. There are tens of thousands of serial steps to complete a Space Shuttle mission. So let’s use our math. Let’s say there are 10,000 serial steps and a 99.99% chance of success for each step. That means there is only a 37% (3) chance of mission success. To get mission success over 90%, each serial step needs over a 99.999% chance of success. Given the needed precision and the technical complexity, it is not surprising the Space Shuttle program was beset with another disaster in 2003 when the Space Shuttle Columbia disintegrated upon re-entry. Seven astronauts lost their lives. Given the high number of dependent steps, plus, the needed precision and the attendant severity, it is not surprising that Space Shuttle accidents periodically occurred.
The use of Agile software development and related implementation techniques is a relevant example of using the .9^10 situation awareness. Agile uses self-organizing and cross-functional project teams to incrementally implement a software project. Each increment (or “sprint”) in the project is smaller and independent, thus helping to
reduce the overall number of dependent steps and
increase overall project success likelihood.
In late March 2021, the Suez canal was blocked by a 200,000-ton metaphor for the .9^10 situation problem. That is, a massive ship, representing the world’s globalization focus, was stuck in the Suez. While globalization is supposed to enable supply chain-based efficiency, it can also increase risk. In the case of the ship, the related risks include the concentration risk and related increased severity.
Conclusion
Awareness of the .9^10 situation implications is a great start to implementing sound risk management principles. The active management of the number of dependent project steps, their chance of completion, and project severity are helpful to overall project success.
Appendix - day to day examples of managing the .9^10 situation
1) Managing Family Laptops
When my kids were in grade school, they each needed a school computer. Since we have 4 kids, we had at least 6 laptops going at once, including my and my wife’s laptop. I had the auspicious role of being our family IT help desk! From a .9^10 situation risk management standpoint, we did the following:
Each of our computers was a low-end, used laptop. (.9^10 principle - managed severity)
Each laptop had enough processing power, memory, and disk drive space to host basic internet and productivity applications like word processing, spreadsheet, presentation, etc. (I spent about $150 / laptop at the time.)
I also had a server laptop. This laptop had access to our cloud account. This meant our files were safely backed up in a professionally managed cloud environment. (.9^10 principle - managed precision)
We used standard, OS resident home networking capabilities to network the individual laptops to the server. (I taught myself with the help of Google....not hard at all.)
All our files were stored in the cloud. Invariably, every few years, one of my kids’ laptops failed. (Either mechanically or from a virus) At this point, I would either buy a new one or, more likely, just wipe the existing laptop and reset it to its initial state. (.9^10 principle - managed precision and severity)
Other than the mild annoyance of reloading some application software, remapping network drives, and resetting printer settings, it really was quite easy to get back up and running. (.9^10 principle - managed serial steps)
I appreciated having the peace of mind knowing all our files were safe. Plus, we didn’t have to spend a bunch of money on technology! In case you are wondering, I did not really have this specific article in mind when I started our home computing environment. It just evolved this way...
2) Managing Personal Devices
This example is a little different. Like the Suez Canal ship mentioned earlier, this example is about concentration risk and managing severity risk.
We all use electronic devices to help manage our life. Increasingly, the same devices are used for both our business and personal lives. There is a certain elegance to integrating all our electronic usage needs into a single device. I have gone the other direction. My approach is decentralized device usage by employing multiple devices to perform similar tasks. I think of the devices in terms of our "Activity and Doing."
All these doing, activities, and device support are supported by the cloud. A professionally managed, backed up, secure, and low-cost capability to store information and interrelate the devices.
As such, I need to keep up with 5 devices. All are small and simple to maintain. Ultimately, the advantage is if any device fails, I can quickly replace and rely on the other devices in the short run. Also, none of the devices are particularly expensive. Because the devices are independent, the .9^10 situation is not relevant. The probability of failure is separate. So, if there is a 1% of failure of each device, there is only a 1% failure of each device. The devices, while independent, do compensate for each other if one should fail.
Notes
(1) The math notation is a bit clunky, owing to the website capability. The proper notation is:
but we will use .9^10 for this article.
(2) To clarify the use of the words “dependent serial steps” - It is assumed the outcome of the project is dependent upon the successful completion of each step. There may or may not be some step dependence between individual steps. For example, resource competition between steps will cause dependence issues. The degree of dependence will (negatively) impact step probability and successful outcomes.
(3) .9999^10000 = .3679 or rounded to 37%