" />

« March 2006 | Main | May 2006 »

April 29, 2006

KM, and Measuring the Value of Change

We normally perceive change in terms of "good" change or "bad" change. That is, usually, the value of change seems readily measurable. But why is this? The answer is, because we have a preference before we notice the change, which gives us a reason to notice it.

The usual approach is to first define "value" -- namely, the difference that we want the future state of affairs to have from the current state -- and then to go about measuring the progress that action and time make towards achieving the desired difference. Here, the issue is that although actions and time are both highly various, we usually decide (prescriptively) which actions and timing we will watch.

Because that approach is such a routine for managers, it is all the more baffling to go about it the opposite and less frequent way -- defining the changes that action and time make, and afterwards figuring out what is the meaning of the changes to the current state of affairs. That is, in what sense are the changes recognizable, post facto, as "progress"? What, exactly, is progressing, and do we want it to?

Said that way, we might conclude that, as in the former approach, the majority of management's attention to the phenomenon of change is "regular" and pragmatic, concerned with oversight and with assigning old or current meaning to new observations.

Yet that passes up the home territory of insight -- or, as in the less frequent latter approach, assigning new meaning to old or current observations.

Put more precisely, the distinction is one of being practical versus theoretical. For most business concerns, the problem with theoretical value is that it's either too slow or too speculative to realize -- which makes it expensive to sustain.

Case in point: the influence of knowledge in the organization is often seen as stealthy or unmanaged, provoking changes of unknown value. But harnessing it for managed value frequently appears to lean towards the expensively hypothetical.

This is where many KM efforts get stranded today. Yet meanwhile, that makes it similar to the issue of R&D. In R&D, there is normally some investment justified by the expectation that significant future value will come from new products -- or said more forcefully, justified by the belief that innovation in production is necessary.

Justifications specifically call out the connection between motivation and measurement -- which indicates the importance of thinking about why to measure -- not just what to measure.

Given the example of R&D, the question in most organizations is whether innovation can also be culturally accommodated as a normal and important phase of the ongoing "production lifecycle" of adopted operational knowledge.

The way most organizations recognize their adopted operational knowledge is as "competency". Thereafter, the way they measure the value associated with changes in competency is by measuring the before-and-after difference observed in what looks like a capability: predictably achieving progress through selected modes of action in given situations. At least casually, everyone sees that as "performance", and thinks about performance improvement.

Of course, one of the practical approaches to incorporating changes of competency is simply to buy the already proved "better" competency -- as in hiring "experience". The catch here is not in the difficulty of finding such talent, but instead in correctly defining what it is about the talent that demonstrates the greater likelihood of providing greater predictability of progress. Ordinarily we look for that demonstration in proof provided by prior known situations, or "performance histories"...

But as we know, all workers must adjust to the complexity of the organizational environment, and those who might have seemed to be the most experienced people coming in do not always prove to be the most "effective" people later. For example, struggles with the current work environment (context!) can strongly frustrate the promise of previous experience.

In fact, the most distinguishing problem to solve through knowledge management -- the most challenging "given situation" to address with competency -- is to enable us to know what to do about what we don't know. The main example of this is an ability to solve new problems brought on by dynamics that currently lie outside of our control. (Politics, competition, economics, or whatever.)

Operationally, we can think of the level of that ability as a demonstration of "intellectual productivity"... the degree to which knowledge inputs generate situational effectiveness. But explaining that productivity puts a premium on recognizing improvements in problem-solving capability, instead of on the historical outcomes of solution efforts. Outcomes may indicate improvement, but managerially, the emphasis must be on the mechanism that produces the outcome.

Articulating the features of "successful problem solving" gives a list of (mainly behavioral) characteristics. Those characteristics are really the desired direct results (i.e., differences achieved) of applying knowledge management as an approach to changing operations.

Bluntly summarized, the main goal of knowledge management is to change how things are done, not to change what the doing delivers. The deliverables may or may not subsequently change because the production changed -- but the primary importance is in transforming the production itself in "necessary" ways, so that deliverables can change.

That gets us back to the motivational aspect: the challenge is to define what it is about the production that is necessary to change and why. If successfully articulated and agreed, that particular notion of "necessity" puts pragmatism into the overall KM effort -- easing justification of sustaining investment in the effort.

In re-engineering operations with KM, two broad categories of response to the necessities are: the type of knowledge to develop and incorporate; and, the mode of incorporating the knowledge in the real-time of operations. Aligning things across the two categories can happen as a matter of determining a best practice (process optimization), or as pursuit of an innovation (R&D), but the point is to ensure that this alignment actually occurs. The difference between the current degree of alignment and the target degree is the value of change to be observed.

Posted by Malcolm Ryder at 6:26 AM | Comments (0) | TrackBack

April 23, 2006

Metrics Myths: Miles Per Gallon, or Gallons Per Mile?

A cautionary analogy of measuring value.

Miles Per Gallon (MPG) is an oft-used example of the "bang for the buck" flavor of value. But as we all know, the fine print that comes with it is pretty much of a whopper: mileage may vary. The fine print makes the measurement a lot less reliable until we know a lot more about an additional little factor waiting to be included -- the driver.

That is, with MPG, what we want to think of as the value it describes is often less than what we're really after: the reality is that the independent efficiency of the system it describes (the car) has a relationship with the driver that is the real source of whatever association we want to make between the system and effectiveness. What we're usually really after is effectiveness, and MPG gets us only part of the way there.

If we don't forget that the driver will be involved, miles per gallon is more obviously an indicator about a resource input and the efficiency of its consumption. Yet although we know better, we tend to use it as if we "make" miles with the resource (gas) and the resource must "efficiently" cause more miles to be made. That is, intuitively, the story we want to tell with the MPG measure is one of effective process production. The problem with this is that we don't really make miles with the resource -- instead, we acquire them. As a measure, MPG is actually more a story about "spending" the resource than about process effectiveness.

For process measurement about effectiveness, we have to look at not miles per gallon, but instead gallons per mile (GPM).

Why? Because the Mile is the target achievement unit of the travel (process). Going from point A to point B, we want to cover the necessary miles regardless of what the cost in gallons may be. The cost might change our enthusiasm for making the trip, but the cost does not change the distance to the target (of the trip). Consequently, GPM speaks to a production efficiency that might be indicated by the phrase "gallons may vary" and brings up effective resource consumption.

Summing up the above:
- MPG pertains to efficient resource consumption for effective process production
- GPM pertains to effective resource consumption for efficient process production

So, what's the management difference between MPG and GPM? It's the difference in what kind of value is determined.

Value through GPM is about deciding which type of resource should be committed.
- Gas, electric, or steam?
- People, process, or technology?
- etc.

Value through MPG is about deciding which resource of a given type should be committed, as in from what category should the given type of resource be drawn:
- Basic/premium? Generic/branded? New/legacy?
- Stored vs. just-in-time?
- Standard? Custom?
- etc.

Put that way, such choices for how to change value relate to each other in a fairly straightforward way. The picture below makes this more visible in conventional management terms:

As an example of how this plays out, consider a company's IT operations. According to the framework above, IT has four kinds of value contributions to offer to the business:
- Capacity: through IT Assets (resource efficiency)
- Outputs: through IT Systems composed of assets (process efficiency)
- Options: through IT Services running on the systems (resource effectiveness)
- Outcomes: through Applications leveraging the services (process effectiveness)

The overall discipline of managing the value would be about making choices in all four cases that systematically increase the likelihood of desired outcomes -- meaning the odds of generating "explicit actual value"... As demonstrated by the framework, it need not be confusing to direct the appropriate measurement of value contributions when the important perspectives are both distinct and logically related.

Posted by Malcolm Ryder at 10:04 PM | Comments (0)

April 16, 2006

This Just In

The Washington Post's Mensa Invitational once again asked readers to take any word from the dictionary, alter it by adding, subtracting, or changing of one letter, and supply a new definition.

Here are the 2005 winners:

1. Cashtration (n.): The act of buying a house, which renders the subject financially impotent for an indefinite period.

2. Ignoranus: A person who's both stupid and an asshole.

3. Intaxication: Euphoria at getting a tax refund, which lasts until you realize it was your money to start with.

4. Reintarnation: Coming back to life as a hillbilly.

5. Bozone (n.): The substance surrounding stupid people that stops bright ideas from penetrating. The bozone layer, unfortunately, shows little sign of breaking down in the near future.

6. Foreploy: Any misrepresentation about yourself for the purpose of getting laid.

7. Giraffiti: Vandalism spray-painted very, very high.

8. Sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.

9. Inoculatte: To take coffee intravenously when you are running late.

10. Hipatitis: Terminal coolness.

11. Osteopornosis: A degenerate disease. (This one got extra credit.)

12. Karmageddon: It's like, when everybody is sending off all these really bad vibes, right? And then, like, the Earth explodes and it's like, a serious bummer.

13. Decafalon (n.): The grueling event of getting through the day consuming only things that are good for you.

14. Glibido: All talk and no action.

15. Dopeler effect: The tendency of stupid ideas to seem smarter when they come at you rapidly.

16. Arachnoleptic fit (n.): The frantic dance performed just after you've accidentally walked through a spider web.

17. Beelzebug (n.): Satan in the form of a mosquito, that gets into your bedroom at three in the morning and cannot be cast out.

18. Caterpallor (n.): The color you turn after finding half a worm in the fruit you're eating.

Posted by Malcolm Ryder at 12:13 PM | Comments (0) | TrackBack

April 9, 2006

The ROI of Complexity

Imagine trying something so simple as opening a door, without the vast complexity of the brain to generate the action. And where opening the door is the kickoff of manuevers that generate greater and higher subsequent value, the investment in complexity is still mainly about enabling the necessary component simplicity. Without the complexity, the underlying manuever of critical value may simply not be available.

This indicates that the appropriate management response to complexity is probably not "reduction" but instead "direction" and "application"... that is, getting complexity to do the right thing. The importance of understanding the nature of the complexity is in finding out how to harness it so that it is directable and applicable. Changes to the complexity have the objective of making it manageable, with the understanding that manageability aims for direction and application.

Posted by Malcolm Ryder at 11:46 PM | Comments (0) | TrackBack

Uncertainty versus Execution

Understanding agility as the solution to executing versus uncertainty.

Everyone is accustomed to the idea that change is now the rule rather than the exception.

But despite this level of anticipation, how will your operations be affected by events and trends that represent sudden or intense change? Are management capabilities up to the task?

Our operational concerns are usually cast in the perspective of Success versus Failure, but measurement in those terms is often accompanied by a significant confusion. Operations typically require several different planes of activity to interact and build up to an ultimate outcome. The factors critical to success on one plane have no necessary simlarity to factors on another plane. (For example, running fast requires energy on hand. But what produces the availability of energy on hand is entirely different from what produces the smooth mechanics of speed.) The problematic confusion of measurement is that distinctions indicating "success" on one level of activity are mistakenly expected to "cause" impacts or "represent" outcomes at some other different level -- and thus may be used as measurements of the other level. . This mismatch makes the problem of decision-making more difficult and/or less effective, as it encourages trying to solve problems with the wrong tools (e.g., inappropriate metrics).

While "success" may go by many names, solutions are generally recognized in terms of "impacts" -- and it is the impact that finally gets measured. To avoid the confusion of looking for impacts in the wrong places, we need an overview of how different basic types of impact generally relate to each other. With that visibility, it is safe to go directly to a consideration of (and plan for) what is fundamental in operational modifications that successfully address change.

Because change may be neither predictable nor temporary or infrequent, the idea of "operational fundamentals" increasingly refers to what is necessary for becoming "agile". Put simply, the challenge is to address how to deal with variety without sacrificing coordination.

As seen in the diagram below, this agility involves two basic kinds of variety -- changes and exceptions -- as they cross reference two challenges to coordination -- complexity and risk. Organizations bring different capabilities to the problem of developing agility; as pictured here, these differing capabilities respectively support agility in limited but interrelated ways that should be set within reasonable expectations.

This view illustrates the possibility (if not necessity!) of maturing capabilities from an relatively static objective of pre-emptive or reactive "control" (lower left) to a very dynamic objective of predictive or real-time "mastery" (upper right). In this maturation:
- controllers become solvers by gaining the ability to accomodate complexity, and likewise they become experts who are able to accomodate exceptions
- change and risk separate solvers and experts from masters;

Even more important, the same key elements of coordination and variety frame the management impacts (i.e., types of "success") that should be expected. As suggested in the picture, managing to more than one type of impact is necessary for developing the ultimate ability to deal with how external change challenges operational success.

The key is to understand that management achievement in one area must translate across the coordination and variety elements to other areas -- finally allowing management of externally-driven demand. Failures of translation mean that agility is not achieved.

To assure successful translations and mature to agility, management must turn its attention to being able to systematically deal with those factors -- typically by creating a policy that allows and fosters agility. For example, the table below clarifies where the challenge of external change hits management directly -- and thereby points out where policy should provide directions, permissions and limits necessary to the agility of operations.

With that visibilty of what is specifically being challenged by events, we can then slot customary target management outcomes like efficiency, effectiveness and so forth into the main framework of coordination vs. variety, and see where they come from.

For example,
- complexity in configurations separates or links efficiency and effectiveness; but to get to effectiveness from efficiency, the key to solving the problem is in the "logic (design) of the configurations" that efficiency is dedicated to.
- Likewise, what separates or links effectiveness and demand is change in preferences, but now we see that "priority of preference" is the solution key.

In fact, this illustration argues that if policy can manage the links between the different types of target impact (and thus align variety and coordination), agility can be strategically developed. To make this more explicit, the illustration identifies that dimensions of strategy such as objectives (top row) and opportunity (right column) are rationaly related by these same linkages established between variety and coordination.

Finally, it gives management a way to address the issue of "best practices" versus "competency". Ordinarily, the two ideas are used synonymously OR competency is assumed to be an effect of best practices. However, we now see that they are complementary yet significantly different, when faced with the problem of operational balance against shifting external demand. Best-practice operations can be derailed by risk, while Competent operations can be derailed by change. As can be seen in the ilustration, management initiatives for "capability maturity" are likely only half the battle when it comes to strategy, because "opportunity tolerance" (i.e., picking your fights) will be likely just as decisive.

Posted by Malcolm Ryder at 12:21 PM | Comments (0) | TrackBack

April 2, 2006

Business-IT Alignment: Revisiting ActiveROI

By the time the Y2K threat got serious in the corporate mindset, IT innovation had already reached a point of viability where replacing old stuff had to be taken as a serious alternative to patching it.

But it wasn't just the technology that needed to be reconsidered. As it is almost automatically remarked in the business conversation about IT, related people and processes also were in the mix -- and here came the dot-com wave.

Among various other things that "e-business" did to reposition IT in the enterprise, it gave an old teaching instrument a new meaning.

You may remember the elementray school spelling aid "I before E except after C"... For it's new web-era use, I translated it to mean "infrastructure before engagement, except after customer." The problem new to the day was that the web was now allowing customers unprecedented aggressiveness in dis-intermediating the corporate mechanics that ordinarily actually provided services. Customers emerged who wanted "do it yourself" relationships, while others emerged who simply had no patience any more for companies that mired them in internal production technicalities.

Effectively, in both cases the customer's punchline was: "if your I.T. doesn't make me happy, change it or I'm gone."

The hugely superior economies of keeping existing customers versus gaining new ones made the most sense of my new translation. But the implications for IT organizations were not really so new. The point-of-view on IT's operational performance just shifted from I.T.'s "internal" customers (business units) to the company's "external" customers. Internal customers had already had this attitude for a while, and everybody knew it.

Still, despite external customers suddenly getting their hands directly on company infrastructure, it seemed brutally obvious that IT organizations should not be held responsible for managing external customers. (Otherwise, what were business units for?) So the message really needing to be drummed was that internal customers needed to be better empowered by IT.

By abstracting the basic management steps to that empowerment -- resources to operations to relationships -- the model I first proposed set a floor under a wide region of research, from which several key further items grew. Among those, a major one well-rehearsed by 2002 forecast the IT Organization agenda as in the article CIOs: Managing the business's IT Agency.

Then, what brought that agenda to the level of the full CxO group was the problem of linking IT performance to enterprise performance. This problem enjoyed a huge rise in importance due to the maturing acceptance of having enterprise applications automate essential operations cross-functionally, despite hair-raising complexity in integrations and change management. While I liked referring to the celebrity of the problem as "Enterprise Chance Management", it wasn't much of a joke since it was also becoming more obvious that business opportunity was relying more and more on IT-enabled responsiveness.

Given the huge level of investment recommended by Y2K, enterprise applications, and the internet, the business need to understand the value of its IT capacity hit a high point that called for a way to put the IT agenda into a model of being managed by the business. In reply, I created (and own) the ActiveROI model -- a construct signifying the generation of business value from IT resource optimization, achieved in a continuous and proactively matured discipline. Translating the model into practice methodology, the consulting firm Renovance, LLP went to market. Renovance's elaboration of methods for applying the ActiveROI model was indicated early on in the whitepaper, "ActiveROI: Achieving Business Processes and IT Infrastructure Alignment through Real-TIme Management". (As a consulting firm, Renovance developed and offered trademarked practice methodologies of my copyrighted model, in its lines of business.)

From a CIO's perspective, the ActiveROI model describes that the enterprise's engagement with the marketplace runs on an organizational platform created by architectural and portfolio management disciplines that can coordinate IT.

But overall, ActiveROI understands performance in terms of relationships and the services that maintain them, while it understands resources in terms of events and the investments that address them. The critical thing to note is that services and investments are the two most highly discretionary offerings of the executive management of the business -- effectively defining the identity of the business that will predispose its opportunity in the market. As explained by ActiveROI, this "drills down" to the IT agenda and its business alignment.

By way of ongoing explanations and by hosting comparisons and debate, Archestra will continue to elaborate the ActiveROI model and several of its already-in-progress successors or offshoots -- including Archestra Runtime by myself, and works that certain colleagues may finalize for presentation via Archestra in the future.

- Malcolm E. Ryder, April 2, 2006


Posted by Malcolm Ryder at 9:50 AM | Comments (0) | TrackBack