« Business Cases: a pound of prevention | Main | Value Capture through Execution »

August 4, 2005

How Maturity Models Drive Timely Value-Capture

The most basic problem of IT alignment with Business is the need for IT to improve business capabilities within the business's ability to pay.

Of course, the ability to pay is supposed to be a product of good capabilities, so... the question is this: how far in advance of its payoff can we afford the initial capability improvement?

This reminds me of the promise of cold fusion, wherein two key things are at stake. One, the nuclear reaction must produce more energy than it consumes. Two, the reaction must be manageable, as in non-destructive in room-temperature conditions.

In the business scenario, money is the energy, and change-impact is the risk of disruption, while the existing infrastructure is the "room temperature"... And there are big ambitions that come along with that scenario; but are they any more viable than cold fusion, or is it still mostly hype?

Here's one ambition: most capability improvement is "funded" in advance; let's imagine that the net economic gain from the ultimate improvement is as simple as subtracting its cost from the price of selling the capability.

Here's another: most risk of change-impact is prioritized by severity of interference posed to designated parties; let's imagine that the attractive new capabilities are usually really well siloed.

Now, when I snap my fingers, wake up… that hot new capability and its economic value boosting powers are the children of complexity and integration, not simplicity and separation. Why?

Likely, because the capability is, operationally, a process that is orchestrated and optimized across multiple functions, events, occasions, and/or organizations. That's a lot of opportunity for interference. And the net dollar gain tends to be reached by gradual accumulation of payback, not all at once. That's time during which the unexpected can happen.

So, while we're waiting for the dollar gain to pile up, we're carrying a lot of risk. There is an initial risk of disruption to existing conditions, and there is additional risk of discontinuity and error in the downstream run-time exercising of the new capability itself. Hmmm...

Naturally, we want some kind of quality measures to be in effect to minimize the risks -- particularly since taking the risks and losing will cost more money in the form of needed recoveries and remedies -- thereby eroding the presumed, potential, net gain.

Unfortunately, this game is much more about choosing the right risks than it is about avoiding them. The issue at hand is to choose the risks that must come with the desired changes, but to also manage those risks to the point where the probability of them hurting us is minimized. The risk doesn't go away; it just becomes more contained. That's the quality assurance.

What then about productivity? Generally, since a new capability comes with preconditions, and those preconditions are risky, then practically speaking, the capability becomes available to the extent that the risk is managed away from the scheme for productivity (in both the development and use of the capability). The question is, what is the level of manageability that can currently be exerted on the preconditions? The degree of manageability will impose a *constraint* on what kind and amount of influence the capability can have -- influence that directly drives the type and amount of value that can be generated. If value is generated in a smaller and slower way, there is not as much to redeem for economic gain, and it's not clear that the capability will ultimately generate "more energy than it consumes".

A maturity model directly addresses the problem of determining how to balance the risk, cost and productivity associated with making the new capability available.

The model proposes a universe of factors making up the full scope of complexity pertinent to the capability; those are the preconditions. Further, the model helps segment that universe of factors into various combinations. Different blends of factors -- featuring their types and intensities -- associate with the kind of influence the capability can render under their role as circumstances.

This segmenting allows a user of the model to think in terms of when a particular influence (that is, a possible outcome of the capability) needs to already be in hand, and to then begin investigating (in the segments) what it will take to reach that level from the current circumstances. And each kind of influence may turn out to require that a certain minimum degree of manageability be applied to its underpinning factors. In anticipating net gains, we can imagine what the capability's target influence might be worth, but the manageability behind it determines the cost and risk levels that will be active, making the influence feasible and viable or not.

As an example, let's say that the desired capability is "locomotion"... There are three interesting influences or aspects of that capability: speed, safety and reliability. The ability to generate maximum value (and associated economic gain) through this capability calls for all three aspects to be maximized. But initially, there simply may not be a realistic possibility of hitting all three at top levels. On the way from the initial development of the capability, one or two aspects may progress ahead of the others.

And what propels the progress? Here again there are multiple factors involved, such as capital, negotiating skills, science and technique, and other resources commonly needed for development. These development factors can, individually or in combination, affect the progress of support for speed, and/or safety, and/or reliability. The key issue is, what is the operational ability to apply these development factors against the different aspects of the locomotion capability?

It is always tempting to think of mastering the capability in terms of being expertly comprehensive. But this is not the basis of the capability's value to the business, and therefore it should not drive the roadmap for progress in mastering (i.e., maturing) the capability. Instead, a business-level prioritization must kick in.

Now let's say that for some reason the early desired use of the locomotion capability is for the purpose of shipping cargo. In this purpose, reliability, and possibly safety, might outweigh the importance of speed. But if the main purpose for the capability is to shorten personal travel time, then of course speed might at first outweigh safety and largely outweigh reliability.

Further, for example, if we're selling shipping, we can attribute dollar-importance to those factors (and their combinations) that most strongly enable that aspect of the overall locomotion capability. As a shipper, we might not prioritize speed, and instead look at the requirements and costs to develop and maintain reliability so that we can start shipping and billing for that sooner.

Later, with proceeds from our shipping business, we can invest in adding speed and perhaps expanding operations into personal transportation as well as shipping.

We shape our buildings, and then our buildings shape us. --Winston Churchill

Having been reshaped by our buildings, what should we expect when we build again? Through us, the previous building will have *indirectly shaped* the new building, and isn't that how our operations environment evolves?

What our example shows is how maturity models help to map out a managed evolution that creates value at each stage along the way.

Posted by Malcolm Ryder at August 4, 2005 6:34 PM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/94

Comments

Post a comment