In “The Phoenix Project,” Bill and John use the GAIT-R principles and methodology (described in far more detail here) to discover how all the top company objectives on the CFO’s two-page PowerPoint slide deck rely on IT.
(This blog article continues the description of the “body of knowledge” that underpins “The Phoenix Project,” which started in Part 1: Reading Lists, Part 2: Kanban And DevOps and Part 3: Auditing and DevOps ).
Here are links to all four posts:
- Part 1: Where To Learn More About Concepts In “The Phoenix Project” https://itrevolution.com/learn-more-about-concepts-in-phoenix-project/
- Part 2: Kanbans https://itrevolution.com/resource-guide-for-the-phoenix-project-kanbans-part-2/
- Part 3: Audit and correctly scoping the IT portions: https://itrevolution.com/audit-101-for-devops-resource-guide-for-the-phoenix-project-part-3-correctly-scoping-it-using-gait-and-gait-r/
- Part 4: The Gartner Risk Adjusted Value Model: https://itrevolution.com/gartner-risk-adjusted-value-model-resource-guide-for-the-phoenix-project-part-4/
More specifically, when the CFO declares that the organization must understand customer needs and wants, have an effective product portfolio, ensure R&D effectiveness, fast time to market, and so forth, all of those depend upon IT, requiring effective Development and IT Operations.
The challenge then becomes link the risks and controls that reside in ITso that its importance becomes obvious to people outside of the technology organization, for funding, prioritization, reporting, etc.
The technique that Bill and John use in the book was co-developed by a good friend of mine, Paul Proctor, now Chief of Research, Risk and Security, at Gartner. It’s called the Gartner Risk-Adjusted Value Model (RVM). RVM provides a pragmatic set of patterns that any IT manager can use to translate typical business objectives into the required IT processes and controls. Any CFO or COO can then readily understand how IT relates to the business, and appreciate how it helps the organization win.
RVM provides a wonderful set of typical business process goals and Key Performance Indicators (KPIs) that you might find in R&D, Marketing, Sales, Finance, etc., and then provides how IT application and process failure can impede the achievement of those goals and indicators. They have a construct called “Key Risk Indicators” (shown to the right) that provide a formula of how those KPIs should factor in IT performance.
(All three slides: Source: Gartner, Inc.)
One of my favorite Erik lines in “The Phoenix Project” comes right after Bill and John meet with the CFO, where they see his two slide PowerPoint, containing the top corporate objectives. The line is taken right out of RVM.
Erik says, “You must understand the value chains required to achieve each of Dick’s [the CFO’s] goals, including the ones that aren’t so visible, like those in IT. For instance, if you were a cross-country freight shipping company that delivers packages using a fleet of one hundred trucks, one of your corporate goals would be customer satisfaction and on-time delivery.”
I hear him continue, “Everybody knows that one factor jeopardizing on-time delivery is vehicle breakdowns. A key causal factor for vehicle breakdowns is failure to change the oil. So, to mitigate that risk, you’d create an SLA for vehicle operations to change the oil every five thousand miles.”
Obviously enjoying himself, he keeps explaining, “Our organizational key performance indicator (KPI) is on-time delivery. So to achieve it, you would create a new forward-looking KPI of, say, the percentage of vehicles that have had their required oil changes performed.
“After all, if only fifty percent of our vehicles are complying with the required maintenance policies, it’s a good bet that in the near future, our on-time delivery KPIs are going to take a dive, when trucks start getting stranded on the side of the road, along with all the packages they’re carrying.
“People think that just because IT doesn’t use motor oil and carry physical packages that it doesn’t need preventive maintenance,” Erik says, chuckling to himself. “That somehow, because the work and the cargo that IT carries are invisible, you just need to sprinkle more magic dust on the computers to get them running again.”
“Metaphors like oil changes help people make that connection. Preventive oil changes and vehicle maintenance policies are like preventive vendor patches and change management policies. By showing how IT risks jeopardize business performance measures, you can start making better business decisions.”
As Bill and John go around interviewing the business objective owners, they piece together the value streams, identifying where they have reliance on IT functionality.
(Again, I marvel at how RVM paralells the GAIT-R thought processes.)
Here is the resulting table that they generated is shown below: (You can also find it in a Google Sheet here)
| Performance Measures | Area of IT Reliance | Business Risk Due to IT | IT Controls Relied Upon |
|---|---|---|---|
| 1. Understanding customer | Order entry and inventory | Data not accurate, | |
| needs and wants | management systems | Reports not timely | |
| Requires rework | |||
| 2. Product portfolio | Order entry systems | Data not accurate | |
| 3. Manufacturing R&D effectiveness | |||
| 4. Time to market (R&D) | Phoenix three-year cycle time | ||
| WIP makes clearing IRR | |||
| hurdle rate unlikely | |||
| 5. Sales forecast accuracy | (same as #1) | (same as #1) | |
| 6. Sales pipeline | CRM | Sales mgmt can’t view/manage pipeline | |
| Marking campaign systems | Customers can’t add/chg orders | ||
| Phone/voicemail | |||
| MRP | |||
| 7. Customer on-time delivery | CRM | Customers can’t add/chg orders | |
| Phone/voicemail | |||
| MRP | |||
| 8. Customer retention | CRM | Sales can’t manage customer health | |
| Customer support systems | |||
In the future, I’d like to be able to go through the entire RVM methodology, and show all the artifacts that are generated, and calculate the Key Risk Indicators. I’d also like to show how the absence of automated testing and a continuous delivery pipeline jeopardizes “Manufacturing R&D Effectiveness” and “Time To Market (R&D)”.
I’ll be working with Paul Proctor to see if we can make this so.
In the meantime, for more information on Gartner RVM, email Paul Proctor at mailto:paul.proctor@gartner.com, and follow him on Twitter (@peproctor), or contact your Gartner representative and request a briefing.
(Unfortunately, Gartner RVM, like many Gartner offerings, are behind a paywall. However, if you’re in a large IT organization, you’re likely a Gartner customer. Just ask around the management chain, “Who manages our Gartner relationship, and can I get a briefing on the Gartner RMV model?” Tell them I sent you. 🙂
