« July 2005 | Main | September 2005 »
August 31, 2005
Be careful what you ask for: you might get it
IT expert N. Dean Meyer runs down the sources of confusion about products versus services, and internal versus external customers, which plague organizations trying to establish business-grade accountability for their efforts by using catalogs.
This one should not be missed.
Posted by Malcolm Ryder at 9:49 PM | Comments (0) | TrackBack
When Measurement doesn't help Management
Organizations increasingly manage the support, timing and priority of activities by using metrics. And the activity called "measurement" should not exempt from being managed, so naturally there should be measurements about measurement. This might be a hidden dimension of "management".
If we can't manage what we can't measure, and thus if measurement is a basic component of management, then the performance of our management effort is dependent on the performance of our measuring effort. But how dependent?
In what follows, let's look at how and why measurement is:
- critical but can still fail to support good management; and,
- potentially strategic to good management, if measurement itself is properly managed.
Measurement creates the formal definitions that will be used to identify and track states and events in operations and in the operating environment. So, what we come to "know" about our conditions can be deeply tied to the way our measurement allows us to recognize things.
In the classic hierarchy of data leading to information and information leading to knowledge, definitions generate data, or "facts", that are interpreted by a perspective into information, but information is not knowledge until it is assigned to a class of concepts. (This perspective-driven assignment of information is what we call "context".) Meanwhile, the definition of the concepts is not dependent on metrics, but rather on classification -- a different discipline.
Concepts is where management first stands beyond measurement. At this point, though, what management gains from measurement is the engineering, refinement and/or updating of prior knowledge into current knowledge.
The value of this knowledge then begins with applying it. The two main ways of applying the knowledge are:
- to distribute it; and,
- to use it as a decision-point.
For the purpose of "management", there are two distinguishing keys to applying the knowledge.
The first key is to remember that it is not "information" being applied, but "concepts". We're properly very leery of trying to manage without information; but measurement is only one source of information, and regardless of the source, information is not meaningful without conceptual associations. When information is received and processed, what should be further distributed for management's sake is the concepts. That is, in the next step, communication should drive the simultaneous, interlinked distribution of both the information and the meaning.
The second key to the management-oriented application of knowledge is to see that action is another way of propagating concepts. When actions are classified -- by purpose, impact, and propriety -- they can represent a model of operations that describes how the organization qualitatively distinguishes itself from others. Decisions typically select preferences that in turn select and promote actions. This is what "management" does with knowledge that drives opertional performance. Additionally, it reinforces or proposes the prevailing desired identity of the organization.
Because of what it represents, proposed or dictated action becomes a form of communication in itself. Starting with decisions, management must do a good job of forwarding both the ideas and the actions that matter.
This forwarding or promotion is the second point at which management stands beyond measurement. For many reasons, managers promote things according to preferences and tolerances, not just neutrally or automatically. Whether the driving reasons are psychological, political, tactical, or whatever, promotion can run independently of measurement.
However, when the promoted actions and ideas are then monitored and measured for their timing, compliance, impact, etc., management comes full circle as there will be new data generated about resulting states and events. Recognizing states and events can be facilitated by using the language of measurements, but not all states and events will have already been discovered before: unprecedented effects will occur and will need a way to be identified beyond the current terms of measurement. Research on possible effects should extend beyond the local or immediate management milieu, and measurements should be upgraded to accommodate the newly acknowledged effects.
In review of the above, looking at how definitions, concepts and promotion line up offers the picture below:
How good is your management at getting all the way around the circle? This question asks about the performance of management itself. Seeing that there are at least three major components in the cycle highlights the idea that measurement will be a prerequisite of good management but not necessarily a cause of good management.
The ideal situation would be that measurement is refined to the point where it is not just critical to management but actually strategic. This would mean that measurement should have both methodologies and deliverables that actually make management's overall effort the differentiating factor in generating the value of what is being managed.
We know that poor measurement can be a significant inhibitor of good management, because measurement is critical -- that is, it is a prerequisite whether it is helping or not.
By explicitly addressing tie-ins with knowledge and communications, measurement stages an opportunity to become strategic and not just critical.
Note: The discussion above focusses on characterizing the relationship of three types of "business information" (measurements, knowledge and communications) in a singular management lifecycle. One online resource of many in-depth papers more conventionally discussing measurement is the "TechRepublic" free-membership IT library. A good current example of the available content offered is the whitepaper The Metrics of IT: Management by Measurement from the Enterprise Computing Institute -- reached via TechRepublic membership at this URL: http://techrepublic.com.com/i/tr/downloads/home/metrics_of_it.pdf
Posted by Malcolm Ryder at 6:54 AM | Comments (0) | TrackBack
August 30, 2005
Solution Strategies: Solving the Right Problem
Strategic capability is always critically significant, but critical capability is not always strategically significant.
We know that a square is always a rectangle, but a rectangle is not always a square. When we must have a square, the need is what makes the requirements more strict. Understanding that, we can appreciate the idea that "special" solutions are all about the fit to the problem. If a solution is constructed that does not fit the problem, it doesn't matter how elaborate or simpe the solution is.
In an elaborate solution, it is often the case that tremendous amounts of energy are spent on being precisely or accurately elaborate; but in the end, what really matters is only what is relevant.
Taking relevancy as the major guidepost provides an interesting context in which to consider the three dominant modes of solution construction (i.e., change justification) that management usually offers today as having business value:
- Standards compliance
- Continuous Improvement
- Optimization
In the context of relevancy, we get to ask what these efforts "fit" that accounts for why they should be considered "valuable". How do we know that these well-intentioned efforts, usually initiated with a sense of both importance and urgency, are not solving the wrong problem?
I.
The idea of "solutions" makes sense primarily because there is a preconceived "problem". Where the essential problem is that we need something that we don't already have, we can take the basic idea of value as starting with the initial acquisition of something appropriate to our need -- that is, simply marking the difference between having something significant versus having nothing. Typically, organizations think in terms of needing capabilities, so the initial or baseline value is "enablement".
With enablement as the target value proposition, we can think about how each solution mode "fits" or contributes. Each one has a potentially distinctive affect on the objective -- but moreso each one is likely to be requested to address a certain aspect of enablement.
For example, implementation is a baseline concern or aspect of "enablement". In this concern, standards compliance readily exerts huge influence.
Then, for the sake of making the implementation as secure and stable as possible under demand, continuous improvement takes the initial implementation "up a level" from its basic compatibility to greater utility.
That higher value to enablement is not hard to appreciate. But enablement might not be the priority! It is not so unusual that we have a realization of a problem and at that same time see that the solution must not merely enable. Our terms of acceptance, or of what makes the solution "appropriate", virtually begin with a need that is more special than basic enablement will fit. Here, we need an enhanced solution. This asks us to consider how the three solution modes fit enhancement.
In the following diagram, a framework of highly typical solution issues completes this kind of consideration. It shows that the organization's managers can move from basic standards-oriented enablement through a wide range of options that represent "fit-to-need" -- ultimately reaching optimization-oriented innovation.
II.
The main management challenge is to ensure that the solution mode chosen is being applied to the right problem or need.
In the framework, Optimization is identified more specifically as "Effective Optimization". Here, effective means that the optimization being pursued is willing to "break the rules" that may have already been established by standards and continuous improvement in order to adapt the solution to the particular requirements of the current operating environment. Optimization involves real-world trade-offs that allow the solution to actually work.
In the right side of the framework, Innovation identifies a need in which the calculated opportunity to succeed is based on capability that lies outside of the previously established boundaries of expectation.
Generally, the contents of the framework cells name the "justification" or "goal" that is to be addressed by the solution. While no issue within the framework cells is exclusive to its shown location , each represents a point where the application of the solution mode to the business need reaches a threshold of criticality not expected anywhere to its left or lower.
Posted by Malcolm Ryder at 4:33 PM | Comments (0) | TrackBack
August 29, 2005
Balancing Governance and Strategy with Portfolios
I.
Old-timers and enthusiasts in the camera buff crowd know about the old twin-lens cameras. Back in the day, the camera had two lenses. One lens let you see what you wanted to take a picture of. The other lens let the film see what it was going to take a picture of. The problem was that because the lenses were in two different places, the film didn't always see the same thing that you saw; and the proof of that would come up in the actual picture produced.
If your business is spending a lot of time looking at things through the lens called "ROI", what follows below is for you.
II.
Strategy would be pretty uninteresting if it didn't promise to enhance the state of the business.
Of course, a lot of things can fit under the umbrella of "enhanced states"... Typically, strategy talks about a future condition making the business either more immediately valuable or more secure in its ability to become more valuable. So naturally, the circumstances that strategy tends to address include business inhibitors to resolve, or business opportunities to exploit. The business idea of value is in managing those resolutions and exploits in the desirable direction.
None of this is news, but sometimes it helps to restate the obvious as a way of bringing a line of thought back into focus. This is a good thing to do whenever discussions about something press the notion of that "something" being "strategic" or not.
Did someone say "value"? Much of the time, business discussions decide that something is strategic if it delivers "ROI" -- or at least the assumption is that it better deliver ROI if it is strategic.
This view makes it seem practically easy to distinguish the non-strategic from the strategic, while it allows that the problem of actually determining the ROI might still be a bit gnarly. But a neglected problem, in practice, is that at this very point in the train of thought people too often forget that the actual strategy might be pretty complicated, too.
Why is this a problem? Because, without the framework of the strategy, it is too easy to mistake ROI for actual strategic value. How can that be? Easy: the only payback that is by agreement "strategic" is payback that promotes the objectives defined in the strategy -- yet not consulting the strategy won't prevent getting a payback anyway.
One of those lenses -- ROI or strategy -- is going to generate the picture you get, regardless of what the other lens sees. The trick is to put them in the right positions, and try to get them to agree.
III.
The real point of the exercise for projecting ROI is to maximize approval of the affordability of whatever effort is made. If "strategic" approval, or strategic justification, is the name of the ultimate game, then we must insist on being able to recognize value even if the net cost of the effort doesn't reach zero.
Through example, let's look closer at what this really means. Often there is a set of efforts that are just called "keep the lights on" efforts. These are not usually considered to be "strategic" efforts, although no rational executive would allow them to be ignored -- because of course if the lights are out then nothing else is likely to get done. Clearly, keeping the lights on is critical, and the value of doing that is enablement of something else. But what is the ROI of keeping the lights on?
The point is that ROI is an idea that should "inform" investment but probably should not dictate it. Something more important than ROI should be in control... namely, value. Meanwhile, the main thing to care about regarding investments is that a strategy must be invested in or it likely won't be realized.
IV.
Investments are commitments, so they link the strategy to the reality of managing the business.
With that said, the investment portfolio jumps into the scene.
But what is portfolio management? In "ROI and IT Investment", Tom Pisello of Alinean (via SearchCIO.com) states: "dollars are appropriately distributed between risky and stable investments according to a [portfolio owner's] profile and goals."
Heads up: the most important word in the whole definition is "appropriately"... Along with that, the key thing to understand is that a portfolio is not supposed to determine what is appropriate -- rather, it is supposed to ensure that commitments are in line with what has already been defined to be "appropriate".
Normally, that definition of "appropriate" will come from two sources: outcomes defined by strategy, and constraints defined by governance. What most businesses are after is outcomes that are opportunities, and constraints that are only minimally inhibitors.
This especially makes sense when the constraints and outcomes are aligned explicitly enough for managers to see and explain where their commitments can make the desired difference. The alignment will include prioritizations and trade-offs that decide how much opportunities and inhibitors are respectively allowed to influence actions.
In this situation, portfolios express what is "appropriate" by mapping the alignment of governance and strategy.
V.
Tom Pisello's key points about investing (i.e., commitment) logically start with the task of developing a view that also generates the elements of a strategy:
- Companies need an industry analysis to understand how new initiatives will achieve competitive gain.
As he sees it, IT governance then steps in, fulfilling two tall orders...
- CIOs have a solid grasp of business issues and communicate IT value across the executive team.
Then the portfolio steps in...
- Technology executives have a holistic view of all IT projects and resources across the enterprise.
It might at first seem unlikely that "communicating IT value" would be convincing without the accountability provided by a portfolio, so is this step out of sequence? No -- there is an even more fundamental value-based view to include before the portfolio is constructed: architecture. For the moment let's ourselves just assume that architecture is placed in the mix during governance.
The final two items from Pisello together describe a gatekeeper function:
- Companies take new investment analysis from that business-need perspective first.
- Companies need a foundation of credible third-party ROI analysis on current and proposed projects.
Notably, business-need establishes why a proposed investment should be analyzed at all, while ROI analysis can provide a take on what the economic impact of the commitment might be. However, this is radically different from determining the economic impact of the outcome. There may be no more important thing to understand about a portfolio than this distinction.
Governance and Strategy are two lenses of the same camera. In managing commitments, how does the portfolio assure alignment of governance and strategy?
VI.
We already noticed that architecture is the base level of description for "IT value". This is the case because the technology product and the management agenda together called "I.T." have a single essential purpose: to provide a structured operational environment designed for business functions. Without this purpose, IT is simply another collection of assets. With the purpose, IT is a resource.
But the ability to actively translate that environmental support into business functionality means modeling the assignment of the existing resources to meet the necessary business priorities and trade-offs. Effectively, the demand on the resources must be modeled.
Portfolios represent assets as resources, and represent needs as demand, and synchronize the two, bringing the influence of governance into alignment with the influence of strategy.
Posted by Malcolm Ryder at 10:53 AM | Comments (0) | TrackBack
August 26, 2005
The Structure is the Strategy
Years ago, Sun Microsystems launched the thought-campaign called The Network is the Computer. This idea absolutely flouresced with the charge it took from an elegant certainty about what "computing" was -- a state of continuous interactive processing of information resources. But implicit in the message was that the interactivity within a single processing unit or node could not deliver the real value of computing. Anyone who agreed with this idea of value essentially designated themselves as a target audience for the campaign's value proposition. With the ambition we have about computing, who would disagree?
So it is that the fantastic Marakon Commentary paper written by Richard Kibble and Neal H. Kissel proposes value of similar sexiness, but in another flavor: "Structure is Strategy". Scanning the main parallel, strategy would be, for us, an activity whose minimum threshold of value is reached only by the grace of the nature of the environment that breeds it.
To embrace the parallel, we have to agree on a concept of "strategy" that highlights its dependency on its host's organization instead of the inherent autonomy of its insight.
I.
Famously, Marshall McLuhan had already pronounced that the medium is the message before the Sun campaign began -- pounding the originally popular sign in the ground that semed to warn we cannot get anything from what we make other than what it allows us to get. But the flip side of the pronouncement was that the message always talks about the medium -- or in our case the strategy is always "about" the organization.
Echoing that in terms of business operations, Kibble and Kissel in effect identify strategy as the connection needed between (on the one hand) business issues that need to be resolved and (on the other hand) the way that an organization deploys the opportunity and authority to make the decisions that address and resolve those issues. In their view, that deployment, which is an organizational design (or structure), predetermines the prospects for successful resolutions -- in pretty much the same way that a language predetermines what kind of concepts can be transmitted between people. Essentially, this influence of language is what we refer to in some instances as programming, and in other instances as architecture -- with the general sense that the former's influence is active and the latter's is passive.
But does this mean that "strategy" can only shop around within the programing or architecture to find things to do?
II.
Programming an organization and running that program will produce directed behaviors and outcomes, which Kibble and Kissel synonymously call "strategy" -- but what we know about programming is that it, too, exists in an architecture, and that a given architecture can host more than one kind of program. So it seems that there is an important ellipsis in "structure is strategy"... and that there is wiggle-room for variety.
How, then, do we finally reach strategy from the structural point of view?
If structure really means organization, and organization really means enabled behaviors and outcomes -- then the threshold of what we would consider to be "strategy" is the point where begins the management of the specification and direction of those behaviors and outcomes.
This contrasts interestingly with what we might consider to be "governance", defined by Peter Weill and Jeanne Ross in their book IT Governance (Harvard Business School Press) as "specifying the decision rights and accountability framework to encourage desirable behavior in" an objective (page 2). Their definition, aside Kibble and Kissel's, clearly positions governance in a role supporting strategy: governance provides the mechanism for managing the behaviors that strategy has identified as desirable.
III.
Logically, this means that governance provides organizing principles that maintain the structure as a base from which strategy is addressed. At the least, that should let us avoid the dreaded circumstances in which, eyeing a target, we realize that "we can't get there from here..."
But if in that sense strategy "comes from" structure, then to parse that value proposition are we really saying that performance come from governance?
Using the term "performance" to signify the success of executing the strategy, the answer should be "yes" because we give governance the assignment to make behaviors align with strategy.
But there's a catch. To understand things in terms of performance, we have to agree that the phenomenon we call strategy is always, both essentially and in effect, responsivity, and that responsivity might be intentional OR unintentional.
We have no habit of calling unintentional responsivity "strategy" but this is exactly the intellectual challenge posed to us by Kipple and Kissel (whether they intended to or not!) when in their paper they cast the understanding of "strategy" as "the ability to tackle strategic issues"...
IV.
Using responsivity as the underlying focal point, the key idea that links strategy and governance is that when governance is exercised, strategy can be intentional instead of inadvertent. This is an important understanding because the deliberateness with which an organization pursues objectives (i.e., problem solutions and opportunities) may be a matter of strategic impact whether the deliberateness follows the officially desired strategy or instead follows an "other" strategy. If the other strategy is inadvertent (that is, proceeding outside of the attention of designated authorities), there may still be value generated and captured -- but the measurement of that value might be based on other kinds of expectations, and therefore that measurement may not reflect "good performance".
What we really want here, then, is to clarify the relationship between responsivity and structure -- and then complete the picture with the relationship between goals and responsivity.
Enterprise Architecture solutions vendor Troux defines [IT] governance as "a framework that delivers strategic alignment, performance measurement, risk management, value delivery and resource management."
What's most interesting about that definition is its set of multiple "deliverables": it doesn't say that the framework is exclusively responsible for any of them; so the real importance is that it shares, with other things, responsibility for all of them. The implication is that they are inherently related to each other and that the framework can make this relationship explicit and help the relationship.
V.
In a scenario of multiple related parts, we can show the space between structure and strategy, and see that a more precise claim would be "Structure is Competency"-- where competency is the abilities to willfully respond.
Further, we can see that:
- Strategy, using the terms of competency, translates goals into responsivity.
- Meanwhile, governance, using the terms of objectives, translates structure into responsivity -- in the same way that a model translates (i.e., organizes) functions into a program.
Thus strategy is moderated by governance. Performance ultimately measures the value of the responsivity -- the link established between competency and objectives.
This set of relations shows that structure might change very significantly without necessarily altering the purpose, activity or effect of strategy. If there's more than one way to skin a cat, the cat is Responsivity. That said, the specific implementation of a particular strategy is clearly beholden to the available underlying structure. But the common issue, or general one, is whether or not the structure provides strategy with something good enough to attain high performance and meet objectives. This is the value proposition of alignment.
VI.
If in fact governance is the lever for making structure enable strategic performance, a governance framework has the responsibility for relating tactics and priorities across the range of issues such as those we saw in the Troux definition. For a discussion on how management addresses the issue of alignment, see the article Managing Strategy versus Managing Performance here in the Archestra archives.
Posted by Malcolm Ryder at 10:00 AM | Comments (0) | TrackBack
August 25, 2005
Alignment, Configuration, and Enterprise Architecture
According to Telelogic/Popkin, the brand leader in enterprise architecture management solutions, "BUSINESS MODELING enables you to realize an advantage over your competitors. By accurately knowing how your business runs, you can enforce efficient processes, and change not-so-efficient processes to make your company more cost-effective and adaptable to change than your competitors."
What that modeling includes and offers is very well explained in numerous publications and studies, such as Yogesh Malhotra's specific but introductory 1996 paper, Enterprise Architecture: An Overview. And after a few of those descriptions have rolled by, the thought that jumps to mind is not "what is business-IT alignment" but instead "why didn't architecture already do that trick?"
One answer to this question is that the business management team responds primarily to what it knows how to measure. In this case, that was a barrier. The speed and cost of business impacts from architectural practice are more evident in a contrast to architectural alternatives than they are from comparison of current period activity to previous time periods of equal length. Because financial accounting has dominated management culture for so long, that accounting mode of period-over-period measurement and response was naturally but mistakenly applied to architecture, giving unusable results.
Different architectures are like different game plans; we know that both can play on the same field, and for long stretches of time neither one may establish superiority in terms of the score. But game in, game out, the always immediate prospect is that one plan is more likely to offer up the game-breaker than the other; and the longterm prospect is that one plan is more likely to win more games than is the other.
Another answer to the question of architecture's delayed impact comes from the now familiar Tim Russert quote, "The older I get, the smarter my father seems to get." How is this an answer? Well, the quote attests to the fact that youngsters don't have the wisdom of their parents, and not having it, the youngster's naivete makes the father's wisdom invisible. Only experience allows the youngster to begin to recognize what the father already knew. Businesses have lost a lot of their naivete in the last four years, as global and scientific forces have brought many different game plans onto their field more frequently and persistently, exposing the weaknesses in the business model. Suddenly, the design-level flaws that architects had always wisely strived to prevent and repair are surface wounds that the business responds to with a proper urgency and respect.
So why is this response -- in particular the flavor called business-IT alignment -- most often invoked by names other than "architecture"?
Here, the answer is an apparent phenomenon that is just not obvious. The answer is that the business experience has to go through stages of maturation, and at different stages, the architectural issue tends to have a different driver or focus, and thus a different name.
We can track this maturation in a maturity matrix. Not to be confused with hierarchical "maturity models", the maturity matrix for the business finds it positioned within classic x,y coordinates of architecture -- functionality and reliability, or here, competency and responsibility.
In the maturity matrix, a business could at any point in time be:
- in the upper left quadrant (multi-competent, less responsible)
- the upper right quadrant (multi-competent, more responsible)
- the lower left quadrant (uni-competent, less responsible)
- or the lower right quadrant (uni-competent,more responsible).
The reason for that point of view is that companies often add functions to their existing arsenal, only to find themselves overwhelmed by the resulting complexity or by being stretched too thin in support obligations.
More typical, though, is a linear or trend-type view. In the historical pattern of 1999 to now, issues such as supply-side economics, hypercompetition and regulation have followed each other on a trajectory that tracks enterprise adaptation to the changing business landscape. In the maturing adaptation on that trajectory, the business goes respectively from getting to be really good at what it does, to being really good at more than one thing, to being able to manage the intricacy of its means for being good at more than one thing.
Correspondingly, one step in this maturation concerned itself mainly with process efficiency, which drove a focus on the supporting assets and therefore BPR and asset management.
A following step concerned itself mainly with innovation, which drove a focus on the supporting infrastructure and therefore e-business transformation and change management.
Now currently the concern is with control of the functional complexity, which drives a focus on accountability and governance, or performance risk management.
A logical next step will be portfolio strategy management, as the business learns to be more than one kind of business simultaneously.
By calling these episodes "steps", we suggest that in some strong sense there is progress being made. The notion here is that the mastery of enterprise architecture is incrementally achieved as the operating environment increasingly demands it. The fittest survive -- not because they "picked the right architecture", but because they have the ability to manage an architecture comprehensively, so that an advantageous architecture could be effective for them.
With related I.T. issues, progress comes along in like manner. Attention to the mounting volume and diversity of assets and resources has been progressing from inventory to investments to configuration and deployment -- while attention to proliferating functions has been progressing from selection to integration to policies and orchestration.
As a result, business intelligence is necessary for analyzing the underlying elements appearing in newer perspectives on business processing models. The need for this intelligence is stimulating new automation dedicated to logical information services such as CMDBs (configuration management databases) and simulation -- emphasizing the management arts of What Could Be over those of What Should Have Been.
For a closer look at this business intelligence see the article "The Conceptual Basis of Configuration Management Data", here at Archestra.
Posted by Malcolm Ryder at 12:00 AM | Comments (0) | TrackBack
August 23, 2005
Business Enhancement and Constructive Innovation
This just in from the 23 August 2005 Member Edition of the McKinsey Quarterly: McKinsey surveyed what global executives think about technology and innovation. Their results stated:
"Fifty-three percent of CIOs and CTOs cite the ability to innovate as the most important capability for growth... [but] 33 percent of technology executives see improving their companies' current products as the key driver of growth -- a significantly higher proportion than the 19 percent who favor developing new products..."
In other words, when growth is the objective, improving existing products is more effective than developing new products, so is "innovation" -- the top tool -- primarily important for product improvement, instead of for new product development?
This is interesting largely because of the persistence with which the business value of IT is debated. Looking at overall business spending on IT, various analysts (collectively) calculate that only 10% to 30% of the spending on IT is dedicated to what is generally termed "new initiatives" as opposed to "sustaining initiatives"... On the surface, it would seem that IT is already doing what the business wants!
But that makes us wonder what IT organizations consider to be "new" -- because we want to know what part of that "new" is about growth: a little of it, or most? And does "sustaining" include improvement? Or do budgets actually leave out improvement as a target? Meanwhile, where does "improvement" best fit in: with "sustaining", "new" or both? Sorting it out looks like this:
This larger perspective helps to organize our questions and formulate better ones. For example, now we know to also ask how both new and sustaining activities contribute to growth, and we can imagine that they contribute to other objectives as well.
In fact, a better and higher-level unifying theme for the language of IT's business impacts is the idea of strategies for business enhancement. The importance of this phrasing is that it separates the problem of how something is getting done from why something is getting done.
In the case of the McKinsey survey finding, "growth" is the "why" of what people want to get done. The exact point of interest in McKinsey's findings is that the folks who "run IT" believe that the reason why products should be changed is that it will cause the business to grow. Although it doesn't initially seem like it, the baseline contrast to consider in those findings is the emphasis on products rather than on something else -- not so much about whether development is more important than improvement. What do we do about products, to drive growth?
And yet, development versus improvement is still a big issue, because those are two pretty different types of capabilities. More importantly, they are two different types of responsibilities to charge to the business managers, who either way will look for support from IT. The business, not IT, needs to establish the case for why one or the other offers the better competitive advantage that we can assume will foster growth.
II.
One of the most basic management beliefs is that growth comes from "competitive advantage". This idea means that the company's most significant difference to its customers and partners is preferable to the difference offered by other companies. Furthermore, it means that achieving the particular differentiation must be a sustainable capability if it is to be realized as a critical success factor in the business. Sustainable need not mean "permanent" -- but it does mean consistent throughout the period of need.
The secret in understanding this position, however, is that the "difference" can be of type (characteristics offered) or of amount (supply offered).
Strategically, in the customer's eyes, dissimilar offerings (e.g., products) are different in approach to their needs, while similar offerings are different in quality provided.
Meanwhile, for the provider, what the idea of "advantage" always includes is a gap of one kind or the other between its offering and other companies' offerings. The challenge in business enhancement is how to create and preserve the most opportune kind of gap.
Approach and quality are paths to two different kinds of value, so either one can be a source of advantage. This indicates key ways to think about how products are handled.
Development seems obvious as a way to tackle "approach". A new kind of product is probably the default example of "innovation". Improvement, likewise, seems to be the default for "quality". A product upgrade is a normal example of this.
In both cases, the customer or partner envisions being able to do something "practically" unprecedented due to the particular product; and the distance between the old ability and the new one is the value gap.
In fact, we should appreciate that in both cases, the value gap does not exist primarily because something hadn't been thought of before, but instead because it hadn't been available before. This is why we need an expansive definition of "innovation"...
Meanwhile, what really lies behind the notion that products can drive growth? In reality, "Growth" reflects the market taking advantage of the availability, while "advantage" reflects the supplier finding a way to expose and leverage the gap when other suppliers have not.
Therefore, consider the fact that without changing the product at all, using it in an unprecedented way might generate value where there had not been value before. The context of the product is actually more basic to value than is direct change to the product.
Said differently, if the circumstances are right, new value can be generated without a change to the product. But in turn, this means that the ideal reason for a change to the product is to increase its relevancy to the circumstances into which it is introduced. At the least, we need to master our identification of the circumstances.
III.
Taking a cue from the popular saying that competitive advantage is gained through something that "changes the rules of the game", we can imagine modeling the product's circumstances as the set of perceived rules and/or the apparent system presented by the dynamics of the circumstances.
From there, it's really a question of how we use what the model shows us.
We should assume that the model describes why availability is deficient -- but, that the problem is just an illusion that can be dispelled with one of the following:
- an alternative model (such as a different perspective);
- by closer inspection of the existing one (revealing a "loophole");
- or by high-speed iterative refinement (eliminating interference).
Thinking along those lines, here is a possible breakout of business enhancement options.
Innovation - change the rules and/or system.
Offer Choice - displace the value gap in the current model, by presenting a different model with equal viability. (Transistors versus vacuum tubes; DVDs vs. VHS)
Renovation - reinterpret the rules and/or system.
Offer Resilience - circumvent the value gap in the current model, by combining the boundaries of its given expectations in a different way. (Ali's Rope-a-Dope against George Foreman; Annie Hall's wardrobe)
Optimization – master the rules and/or system.
Offer Quality - close the value gap in the current model, by eliminating barriers to delivering prescribed features. (High-mileage SUVs; synthetic diamonds)
All three of those options can generate a value gap between the supplier and its competitors. But what is equally important is to understand what value gap currently exists in the market (i.e., the mind of the customer or partner), according to the model of the market, and then to choose the best of the three options for attacking it -- Choice, Resilience, and Quality.
In reality, because value is determined by context (the stakeholder's circumstances) more than by anything else, each of those above possibilities might be addressed through either development or improvement -- whichever is more necessary for the targeted context.
But where business growth is the issue, and growth is built on the value, is innovation primarily important as a path to product improvement instead of to development?
Our answer is threefold:
- Growth can be triggered by identifying a new kind of customer. Matching the product to the new "customer-context" might require invention and/or modification. When the customer attributes value mainly to the "new", we are saying that innovation is an effect -- but the approach to that effect might not be innovative...
- Where growth is concerned, product improvement should be seen not just in terms of quality but also relevance and availability. The point is to make the difference that is important at the time to the paying customer. In order to literally make the necessary difference, an innovative approach might be necessary, and there we are thinking of innovation as a cause.
- Distinguishing innovation-as-a-cause from innovation-as-an-effect can profoundly affect the identification of related activities and their priorities. The concept of "whole product", which includes all the issues that surround an item and successfully fit it to the customer, tells us that since customers decide the value, they practically define the idea of the product that is the set of key characteristics to be invented and/or modified.
This warns us that when we are working on operational investment objectives, the most logical generic semantics of "innovation" are that it is one approach to meeting requirements.
Innovative development and maintenance of products in their lifecycle is one level of consideration. Innovation can help meet product requirements at any point in the product lifecycle, from concept to upgrade or retirement.
But as to whether "new products" are more important to business growth than are "improved products", the matter is one of whether business innovation is necessary to meet market requirements.
Posted by Malcolm Ryder at 4:41 PM | Comments (0) | TrackBack
August 22, 2005
A Management Framework for Service Operations
Running IT like a business means that there will be ongoing operations managed on the whole to ensure that deliverables to the business meet business objectives.
Seeing this ability as a competency instead of as a case-by-case event puts management on a different footing. Producing a deliverable is NOT the same as meeting objectives, but management must organize production in a way that it CAN be the same, on demand.
The picture below associates many of the variables in this management effort, by positioning them relative to each other in a framework (central white 3x3 grid).
- The dimensions of this framework (black row and column headers) represent the way the operation applies its structure to the business fulfillment effort.
- The arrows identify the key issues in the structural throughput of operational delivery, from the essential starting points of capacity (architecture) and demand (specifications).
- Managed operational capabilities that are committed to the business are shown at the top three rows. Their influence is concurrent, and their overlaps from left to right show when they influence each other.
- Outputs (in green) result from the activity in the rows, and list the terms or expectations by which the business rates the operation.
For the full secret decoder-ring elaboration of this chart, see the sequence of illustrations that follows.
Here we'll build the framework issue by issue.
Posted by Malcolm Ryder at 6:00 PM | Comments (0) | TrackBack
August 20, 2005
Invention, Improvisation and Innovation
I.
Every day, operations proceed with essential concerns about continuity and direction, within this same basic value-management cycle:
- Can we do it? / What are the outcomes? / Why is that important? / (Repeat) -
At each point in the cycle, operations managers presume that the desirable answer is a logical result of cause-and-effect. Putting pressure on each point, meanwhile, are significant forces (such as, respectively, skills and knowledge, location, and competition) that are tough-to-manage variables affecting the actual answer.
Now, with unexpected or rapid change occurring independently at each of the three points, as well as across them, more and more time is spent trying to overcome complexity in determining the difference and the linkages between intended cause-and-effect versus actual cause-and-effect.
Without this determination, management cannot know whether the most effective operational path to meet currently targeted ultimate objectives is through the existing environment or through a modified environment in the future.
There are many ways to conduct an environmental review that generates both an assessment of the current environment and a design of a future environment. All of them have the purpose of solving the same "You can't get there from here..." problem, by either repairing critical stepping stones or building a new path.
But always just as important as the path itself is how you run on it. For organizations whose management feels (rightly or wrongly) that it is in a known, locked down environment and needs more effectiveness from its activity within that environment, that train of thought is increasingly important. Here is where Invention, Improvisation and Innovation have pushed to the foreground, being additional ways that management can run.
Each option is an idea with important cache that, if abused, will reduce it to a buzzword. To prevent doing that here, let's point out the source of each one's attractiveness --that is, the associations that explain why each merits any attention.
a - invention: relates to products and productivity
b - improvisation: relates to capacity and agility
c - innovation: relates to differentiation and advantage
At a given time, the relative attractiveness of any one of them likely reflects the organization's current estimation of its performance problems. Any week spent reading the management trade mags will bear this out in the columns of strategic advice.
Meanwhile, it also seems easy to indulge the implication that the group of three line up as a "chain" of success factors, a-b-c. Indeed, what often happens in discussion is that the lines are blurred between the three, such that any one of them appears to be a spoke leading to the the same virtuous hub called NEW -- which reduces them to being synonyms for each other, or to being alternatives just requiring some pragmatic prioritization.
Those views are not always the case. But at worst case, misperceptions readily lead to misinterpretation and misuse. For the sake of being more proactively positive and avoiding "lost opportunity", we can look at the way that invention, improvisation and innovation generally get traction, and use that visibility to guide ideas about how to most sensibly incorporate the interest in them, as part of management.
The following diagram illustrates business components and relationships with which managers generate business capabilities. At any of these same touchpoints, management can manipulate capabilities with a range of options including invention, improvisation and innovation. But effective organizations take invention, improvisation and innovation seriously by managing the operational environment necessary to see them through the value cycle of can we do it, what are the outcomes, and why is that important. The high-level view shows infrastructure, goals and culture holding down the three points in the value cycle.
The picture's high-level story is about the complexity involved in the balance to be struck between value and its associated risks, and likewise between requirements and the options for meeting them. Respectively, high-level improvisation and innovation engage those tasks.
Let's look at invention, improvisation and innovation one by one, to start factoring in their opportunity, purpose and effect.
II.
In its literal root sense, Invention refers to "finding something within". Practically, this sense is associated with exploration and experimentation, the two activities that typically host and court the experience of invention.
Because both of those activities can be structured, their practice may be placed on a supporting mechanism designed to make them accessible, accountable, regular and persistent. We can see that underlying mechanism as a combination of methodology and infrastructure.
But once methodology and infrastructure are in place, they become the key constraints on invention. The challenges become to maximize the effectiveness of leveraging them, and maximizing the ability to re-engineer them if necessary. The importance of this is in the need to know whether they are promoting invention more than they are inhibiting it. As we increasingly find in the arena of knowledge management, invention is a fundamental daily activity necessary to site-specific problem solving in the organization. Nonetheless, an equally big challenge is to commit the investment in that methodology and infrastructure to actual invention as opposed to routine production -- otherwise the methodology and infrastructure are unlikely to change towards effectiveness. This commitment is seriously challenged because of the similarity thatinvention has to production activity. The similarity makes it easy for the organization to appropriate the means for one purpose instead of for the other; so invention must compete for priority in order to keep its means:
PRODUCTION
- manage compliance to known causes that effect specifications
INVENTION
- Manage attention to assumed causes that effect theoretical outcomes
If the organization does not have theoretical outcomes representing high mission priorities, then it is less likely to find the fortitude for sustaining use of its methodology and infrastructure to drive invention. This would likely prevent R&D in infrastructure and methodology. With the pace of change in business requirements today, that would be crazy: who was it that said the definition of insanity is doing the same thing over and over but expecting a different result?
III.
Improvisation, in its literal sense, refers to "the unforeseen". From that, it attributes two key characteristics to activity -- unplanned, and extemporary (casually observed as in "the heat of the moment" and "at hand"). Importantly, it involves no lack of understanding of what is to be produced; rather, it is concerned with how the production was organized. Being aimed at a target "effect", improvisation seems to be related to invention. But the real difference is that while invention proceeds according to a plan to make something of undetermined value, improvisation is unplanned but aimed at making something of determined value. The even more important issue with improvisation is that, unlike invention, it occurs under production pressure: that is, an acceptable outcome is already described and targeted, and the means of generating it must succeed within the excited restrictions of available time and materials.
In short, the problem in improvisation is not so much "product" as it is "process". As a shorthand for what could be another whole discussion in itself, let's think here of process as navigation. In this way it is easier to recognize the real significance of improvisation as a production mode -- which is not that it is any less rigorous than following a plan, but that it relies on a different frame of reference for guidance. The star-charts and weather forecasts of the operation's environment -- such as scorecards and dashboards -- must be the basis of decisions about pace and course corrections.
For management, the decision to improvise is challenged mainly by the dual concerns of accountability and risk. Thus, the choice to improvise must be made through prioritizing effectiveness over the expectations of accountability and risk. Deep experience, for example, offers a cognition and frame of reference that allows a manager to abandon what seems to be a failing prescription and improvise instead. We tend to discuss this in terms of "instincts", but for most managers, confidence in actually executing this way requires an understanding of the difference between process and "technique" -- with confidence in technique. Both process and technique are ways of describing "the method of procedure", but the difference is that process is specifically about the method of activity, while technique concerns itself with the method of using available tools and materials. Consequently, the key contrast is between improvisation and construction:
CONSTRUCTION
- organize production procedure around accountability and risk standards
IMPROVISATION
- organize production procedure around resource availability and logic
Usually, for improvisation to take hold, the organization's management must decide that in the face of a construction's projected inadequacy, the consequences of ineffectiveness are too harsh to tolerate. This explains why improvisation is most often considered for issues where unexpected failure looms. But it is also the case that improvisation serves as research for future construction-process improvement. So improvisation becomes an extremely valuable experience for enhancement through re-invention...
IV.
Taken most literally, innovation has the fascinating responsibility of "introduction". In turn, introduction has a core meaning of "to lead into" a position. This accounts for why every vendor touts itself as the "leading" whatever, because the vendor stakes its argument for your attention on the idea that it has "introduced" its particular distinction into some context with which you identify. But if all comers are "the leader" then what matters is what might be new about each one's effect. As noted frequently in content here in the Archestra collection, there are at least three main ways of being significantly "new", and the value of each will obviously depend on how relevant it is to the occasion at hand:
- new solution for a new problem;
- new solution for an old problem;
- old solution for a new problem.
As we know, any of those results might come from invention or improvisation... but to the extent that this is true, it occurs because there is a concept of "solution" that is actually applied to a problem. On the one hand, this application might be speculative. On the other, it might be highly strategic. On either end of that spectrum, motivation levels may be just as important. The issue is to determine the source of the motivation and whether the source remains a catalyst or driver. In short, is the innovation "needed"? The most important context for determining the answer is likely to be one that examines priorities for innovation versus improvement:
IMPROVEMENT
- increases the value of the result by enhancing its current type
INNOVATION
- increases the value of the result by changing its type
The key challenge to management is that innovation creates pressure on competency at an elemental level, possibly interrupting the terms of value already established for resources through their existing configurations. While the point of innovation is to get to a result, the practice of innovation requires that organization and competency are not misaligned through a redirection provoked by innovation.
V.
That leads us to the observation that infrastructure must be balanced against culture if the organization is to "get there from here."
In our environmental diagram (repeated below), this idea is illustrated as components and relationships that management can manipulate, with a range of approaches including invention, improvisation and innovation. Organizations take invention, improvisation and innovation seriously by managing the operational environment necessary to see them through.
Again, the picture's high-level story is about the complexity involved in the balance to be struck between value and its associated risks, and likewise between requirements and the options for meeting them.
At any given time, the current operational environment plays mediator by determining what types and levels of value correspond with given types and levels of risk. Meanwhile, norms (primarily including expectations and standards) usually set the terms on which operational alternatives are committed to requirements.
In situations of potential invention, improvisation or innovation, the broad middle zones of environment and norms are where change (through management) creates the energy and leverage that drive potential results.
VI.
In the diagram, the key change-points can be seen within three perspectives that comprise the environment: infrastructure, goals, and culture.
Strictly speaking, all three are generated by invention -- with the form of invention variously being physical or conceptual, essential or political.
Each perspective includes a characteristic value objective that is associated with a characteristic issue of risk. For example, infrastructure value is essentially expressed through management's ability to assure its availability, but meanwhile the risk inherent in infrastructure is in the configuration that it currently presents, which is also a consequence of better or worse management.
Typically, innovation adopts a new example of the value objective and calls for the risk to be realigned to it through the environmental factor. The major precedents for this have been reorganization and re-engineering, but the main observation that this illustration makes is the layout for integrating a variety of internal innovations. This puts the organization on an evolutionary path to threshold-level ability for producing and supporting a successful external innovation.
VII.
Two facts common to enterprise change also distinguish one organization's efforts from another:
- Direction creates focus; but different cultures have different ideas, which sets or resets direction.
- Competency creates opportunities; but different norms set different tolerances, which motivates or inhibits competency.
Management is working on direction when it tries to link goals to culture. When it tries to link infrastructure to goals, it is working on competency.
Improvisation navigates the potential connections in real time, which is the prerequisite for what the enterprise calls agility. Thus, improvisation works out alignment across the perspectives rather than within them.
However, the horizontal alignment effort that management has usually committed to is process improvement. In the big picture, that helps opportunity, but it only affects things from one perspective. Its relevance to goals and direction is still critical to protect its power to enhance the overall benefit of the operation. Infrastructure must be balanced against culture if the organization is to "get there from here..."
VIII.
A final observation about the model in the diagram is that it is an abstract model, not a literal one. This means that it is "scalable", because it can be applied to a small end-to-end effort as well as to a very large one. Wherever an effort can be described in terms of the related options, norms and requirements, there will be aspects of the effort paralleling "infrastructure" (the means), "goals" (the authorizing target results), and "culture" (the permissions and tolerances surrounding the effort). That means, according to the model, that invention, improvisation and/or innovation may be applicable.
Furthermore, since small efforts combine to complete larger efforts, we can see in a logically abstract sense that, for example, an innovation on one scale might be a component of improvisation on a higher scale.
Is this meaningful? As an example of "yes", consider that an innovation in infrastructure might enable an improvisation in business process -- one way to describe the architecture of a breakthrough to agility.
Posted by Malcolm Ryder at 7:51 AM | Comments (0) | TrackBack
August 18, 2005
A Management Support System for IT Service Value
Very recently I received an invitation from a colleague, Eugen Oetringer from EDS in the Netherlands, to study (and share commentary on) an IT Strategy Management Process design.
The most prominent feature of the design, in my first viewing, is the solution that it proposes to the practical problem of just-in-time research that is inherent in conducting service delivery while coping with change and diversity in IT operations. In fact, the design's emphasis on the responsibilities for "development" and "production" anchors its concepts in terminology that is inherently compatible with addressing Business clients in terms of specified quality and value. The noted challenge is that specifications are forwarded into operational environments that are often not built or managed to ensure successful communication. The consequence of that challenge is that alignment is forfeited or damaged between development and actual production, the second link (after specification to development) in the enterprise's value delivery chain.
Also at first reading, it seems equally valid to consider the design as a governance model instead of as a strategy management process. But for the sake of retaining appreciation of the scope of the design's importance, it may be more useful to emphasize that a process for managing the execution of strategy will have:
- a model that guides it,
- a performance objective that relies on compliance, and
- technologies that support the practical implementation of the model.
Eugen's design explicitly details those items in the context of accountability to business needs and policies, thus linking it conceptually with governance.
That said, the design's primary objective of describing how to bridge the gap between development and production winds up exploring how knowledge management supports change management in order to align IT with the business. One of the most important points to take away from the design is that "strategy" is a set of knowledge to be managed, and cultural adoption of the strategy is a result of empowering users to leverage the knowledge in order to adapt.
What does the support of this leverage look like? It is strategy lifecycle management. As the author puts it, "The IT Strategy Management Process takes the strategy from the owner, runs it through an approval workflow, publishes it to the target audience, drives for compliance, takes the feedback from the user communities, provides the feedback to the owner and drives the owner to release an updated version in a central repository."
The whitepaper reviewed above is here, and its parent book from the same author, published by Van Haren Publishing, is titled "The IT Strategy Management Process: Supporting IT Services through Effective Knowledge Management".
Posted by Malcolm Ryder at 7:59 PM | Comments (0) | TrackBack
Renovation as Innovation
Oftentimes, we arbitrarily restrict the working notion of innovation to a certain idea about what matters. This is a bit of myopia that fuels hype, and past the point of raising awareness, hype is not especially a good thing. Hype discourages looking at a problem from more than one perspective, which increases the chance that a related decision will have more risk than is perceived.
For example, a recent article on Doug Kaye's great weblog Blogorithms talked about how podcasting is allowing music lovers to get more of what they really prefer at a hugely increased level of convenience, which threatens the traditional radio broadcasting companies. This is a heavy-duty general warning for businesses pondering the industrial changes underlying their futures.
But too often in the coverage of pod-vs.-broad, the suggested counsel -- change or die -- is cast very two-dimensionally as "innovation in distribution", leaving out several other factors that distinguish the potential of broadcasting and might account for a positive future of broadcasting.
Note that Doug's article does not have that problem; and meanwhile, there is no prediction right here that broadcasting (including TV and radio) has a rosy future. As a TV guy, I'm way more interested in what TiVO will cause than I am in what podcasting will cause, but I think that good cheap digital video cameras combined with streaming files and RSS over the internet is far more important than TiVo or iPods.
So does broadcasting need innovation? Or maybe just renovation? It's easy to call any new change "innovation", but it's more important to get a grip on where the change is coming from, than it is to automatically indulge the mystique of innovation. I'm looking at the way that we could segment and rearrange the factors important to broadcasting that could make it financially viable on a continuing basis.
Here are a number of touchpoints where, hypothetically, change can occur.
It's probably safe to say that broadcasting needs to find new consumers; it is not necessarily the case that the new consumers should be like the old ones, although they need not necessarily replace them.
Broadcasting is expensive. The reason why broadcasting's expense was tolerated is because it delivered something of equal-to-greater value. But what made its content valuable was a business partner. In radio, the partner created a lot of the buying interest in the product, selecting and positioning it. In the future, new partners might be needed. It's not necessarily the case that the new partners should be the same type as the old ones, although they need not necessarily replace them.
To consumers, the role of broadcasting has been not merely "distribution" but "discovery". In the United States, discovery during the 1960s and '70s culture had radically different performance requirements than it does in the current culture. It's role was always to promote and reflect popular awareness -- and now the question is really one of what awarenesses are most valuable when they are popular (i.e. widespread).
And broadcasting has not been an interactive mode, often held now to be a fatal flaw; the flip side of the coin is that content is more secure in a non-interactive environment. If secure content is "reliable" and in that way more credible, then this is a major value point, although I make no attempt to put a dollar amount on it. Instead, note that news organizations suffer more from their credibility failures than from other competitive media.
Finally, also note that "quality" is not the same thing as "taste". Gathering content according to taste may indeed be more convenient that ever now, thanks to media other than broadcasting. However, transcending one's current taste requires exposure and research. There, the idea of quality is represented by objective insights. Delivering objective insights confidently, under widespread scrutiny, can be the basis of offering a trust relationship that supercedes mere willingness to immediately gratify personal taste. This is really about the producers who put content into the channel. Future producers need not be like those of the past, although they need not necessarily replace them.
Yet what's interesting about that last point is that it is not even a new value proposition, but instead one of the oldest ones of broadcasting. Let's talk about TV: expertise has always been a differentiating key ingredient of produced content -- whether it was authentic or just staged -- and whether the show was Masterpiece Theatre with Alistaire Crowley, the Evening News with Walter Cronkite, Monday Night Football with Howard Cossell, or early veejays at MTV. Where there is no explicit host, the expertise may still be implicit in the production values, the credits, the sponsor, and/or the branding.
However, the broadcasting landscape has morphed to where there are several different camps, and the issue posed in that is one of where consumers should expect their desired kind of value, not just the desired kind of content, to be delivered. For example:
- Non-profit Alternative: this is the camp usually thought of as "public broadcasting", but that label is confusing. PBS was seen as a non-profit station presenting alternative content, with "alternative" contrasting the content typically subscribed by commercial advertisers. But public subscription of content does not necessarily result in different content. And government-supported advertiser-free stations, including local "public access" channels, are in this category as well. This category changes as much as people or commercial advertisers are willing to directly pay for currently perceived alternatives instead of getting them "for free".
- For-Profit Alternative: HBO is now cited as a good example of this.
- For-Profit Conventional: this would be the advertiser-sponsored networks like ABC, CBS, etc.
- Non-profit Conventional: this is what some critics are accusing PBS of becoming.
Currently, each of these different channels actually has a range of content types that offer a range of types of value. Meanwhile, branding is usually the device used to try to herd the cats within any given channel. But when these channels are having problems, it has little to do with being broadcast channels per se.
Is there any reason to believe that changing producers at a channel, regardless of its category, could not all by itself suffice to make the broadcast channel viable? Making that happen would be plenty of hard, complicated work -- but my point is that it would be a renovation, not an innovation, and that broadcasting per se would not be a flaw. Look at what ABC has done in the last 24 months. It is simply not being held back in any significant way by being broadcast-based.
What goes along with this is that broadcasting can change its audience, in the sense that the content it delivers can actually alters their expectations. Break-through content is not prohibited by broadcasting; it is perhaps deterred by management.
So this points to what is likely the most important issue of all concerning innovation, and that issue is risk. Innovation can be an answer, but it is not necesarily THE answer, and a lack of innovation is not necessarily a sign of impending doom. Renovation may generate all the "new" that is necessary.
Posted by Malcolm Ryder at 10:40 AM | Comments (0) | TrackBack
Blink - Using the Mind's Eye
Malcolm Gladwell's book, Blink, focuses on the adventures of the unconscious mind, in which pattern recognition collapses the timeframe of decision-making from minutes, or even months, to seconds.
But Gladwell cautions that speed kills as easily as it charms. Thus he sets out a few basic problems that should be addressed in the Unconscious Mind Owner's Manual. His cautions are good, but I'll propose these summary orientation notes anyway.
How do we decide when to use the unconscious mind?
- turn it on for events requiring decision-making under psychological time-pressure.
What's old about this? Relying on experts in these instances.
What's new about this? Refusing to replace experts with science.
The takeaway: patterns visible to experts are not the same as hypotheses visible to technicians.
How do we operate the unconscious mind?
- by ignoring extraneous information
What's old about this? Several thousand years of Eastern philosophy.
What's new about this? Analytics as opposed to metrics.
The takeaway: Critical correlations are usually few in number; think of Pareto's Principle, the 80/20 rule.
How do we make the unconscious mind safe for use?
- exposure, education and training
What's old about this? Nearly everything.
What's new about this? The return of the Heisenberg Uncertainty Principle; now available over-the-counter in a package with a warning label.
The takeaway: With great power comes great responsibility.
Gladwell's keynotes point out that patterns living in the unconscious mind develop over time from thousands of observations. This is what makes experts Experts. He also cautions that misapplying a pattern, that is, using it out of context, is a serious mistake. So, since we can't all be experts at lots of things, the most difficult part of our interest in using our unconscious mind is knowing in the heat of the moment whether our confidence in it is really appropriate to the occasion. This problem of "context" immediately suggests some options that many people might consider to be "best practices":
- get multiple experts
- specialize our own range of involvement
- use as much time between decisions to increase exposure to similar situations
What does this all come down to? The influence of mental models is the core of the book. In Blink, the central hypothesis that the Getty Museum used was trounced by a bunch of patterns, but both approaches were mental models. Gladwell just tries to help us understand where the two types come from, so that we can appreciate why one worked better than the other.
Going along with that, one of the truly huge messages from the book is that experience is a great trainer, but not always a great teacher. High-speed decision-making relies on experience, but effectiveness still comes from an accurate sense of where you currently are -- which requires high-quality current information in perspective. Thus, the "success" of high-speed decision-making relies a lot on properly recognizing the problem at hand, and then also having the right exerience for it. In other words, solving the right problem might be even harder than solving the problem right. We need to be wary of the silos that experience can put us in.
Another message that runs throughout the book, under the umbrella issue of "problem-solving", is the contrast between scientific management and intuitive leadership. In the stories in Blink, it appears that the intuitives keep beating the scientists (for better or worse); but it turns out that the leaders keep beating the managers. Perhaps the punchline of Blink is that we want to be "scientific leaders", because our intuition derives from what is essentially a scientific evolution -- observe, test, refine, observe again -- of patterns that live in our unconscious mind and that in the heat of the moment become vibrant and noticable. Meanwhile, our leadership springs, just-in-time, from the intuition and the willingness to use it -- which, simply but profoundly, often means to accept its spontaneous insistence on being noticed.
Where on the bookshelf should we keep Blink? I put it right between Thomas Kuhn's The Structure of Scientific Revolutions and Ian Fleming's James Bond thriller Goldfinger. On the one hand, Kuhn describes a lot about why we have the patterns we have, and why we hold onto them. On the other hand, Fleming describes a lot about the pressure that provokes intuition, whether it's life-and-death, gambling and love, or pride and anger. In all three books we get a good strong blast of the glory and folly of thinking.
Posted by Malcolm Ryder at 6:52 AM | Comments (0) | TrackBack
August 17, 2005
Systems thinking: Thought for the Month
Milan Kundera invokes Nietzsche to caution us against "an act put on by system-makers: in their desire to fill in their system and round off the horizon that encloses it, they must try to present their weak points in the same style as their strong points."
Caveat emptor.
Posted by Malcolm Ryder at 4:39 PM | Comments (0) | TrackBack
August 15, 2005
The Conceptual Basis of Configuration Management Data
Technology functionality offers business tremendous capability, but for functionality to be meaningful it must be translated into utility.
For this reason, the most important view of IT asset items is of their configurations -- that is, of the organization of assets as resources. Business awareness of configurations powers managed utilization that proves to be effective instead of just continuous or diligent.
Said that way, the role of data about item configurations is evident. In particular, what is important is data about the business management of the configurations.
The high level business view on IT assets revolves around the main business benefits associated with what they offer to business capabilities -- namely:
- capacity, security and agility.
However, the day-to-day management of the IT item configurations is more directly involved with three key business constraints on those benefits:
- ownership, control and alignment.
These constraints are just one set of several major groups of things that change and that therefore call for management attention in order to calibrate and assure optimal utilization of IT's functionality.
Before we look at an illustration of these changes and how business awareness affects them, let's recap what configuration management data involves in this discussion.
- Configuration: a definition of how asset items are deployed as resources
- Management: specify, approve, implement, support, and modify the configurations
- Data: recorded observations about the management
With that understanding, the illustrations below proceed from the issue of managing against key constraints, down to the relevant level of data about managing configurations.
The illustrations show why information about the management efforts is tantamount to business intelligence about the configurations.
First, the overview, detailing the above comments on business awareness:
Following on that set of business issues is a set of management performance issues, shown below. Business information (matrix at top) about the proposed value of IT deployments must be related to information (cube at bottom) about how deployments are actually being managed. Although the issues are typical for all companies, the information (to be determined) will be unique to each company and will change over time.
A key feature of this overall perspective is that it distinguishes data describing the configurations from data describing their management. While both kinds of data are necessary, understanding utilization requires a description of the management phenomena that account for why IT is impacting the business as it actually does. With that understanding, managers can better decide what to do about configurations, when to do it, and why.
(For a discussion on the Resource Status Information view in configuration management, see the article Operations Intelligence - The Business Logic of the CMDB here in the Archestra collection.)
In summary: the IT impacts on the business are the result of management decisions. Management decisions create resources from IT assets in the form of configurations, and deploy those resources into the operational environment of business objectives. Our illustrations here point out the type of information about management that makes up a huge portion of the "business intelligence" needed for decision-support to direct the assignment, leveraging and optimization of the resources.
Bringing this back into the business management context, companies find configuration management significantly and even strategically influencing planning. In the illustration below, this influence is traced around a closed loop of business enablement typified by enterprise architecture's extension into configuration management.
The understanding and management of events calls for the company to be able to describe events in terms of the items and circumstances that they involve. Why?
The assumption is that everything happens -- whether intentional or not -- occurs because some part of the business is trying to make something happen. Events are effects, so the problem is to understand what events mean when they happen (impacts), and to exert some control over them (causes). To do this, the configuration of the infrastructure is constantly checked to determine how events (and their meaning) relate to (a.) the infrastructure's capacity vs. demand, and (b.) the infrastructure's integrity versus demand. The main objective is to develop manageability of the events. That requires sophisticated ways of describing events, especially in terms of what "items" are involved in the occurrence of an event -- in other words, the collection of item definitions that allows analysis of the infrastructure. So, for example, the analysis drives decisions about whether capacity and integrity need to be addressed through initiatives or problem resolutions (i.e. repairs) regarding development and/or security.
Posted by Malcolm Ryder at 8:56 PM | Comments (0) | TrackBack
Truth-based Management and a Single Version of the Facts
I.
Performance measurement has stampeded onto the scene in even casual literature discussing management.
The force of its impact is hardly about measurement per se, however. Measurement is not new. Rather, the buzz is all about what "performance" means.
Scholars, consultants, analysts, vendors and managers alike are aggressively exploring the scope of the term, searching for standardization of both its philosophy and its application in practice.
The resulting range of perspectives, from scholars to managers, is so sweeping that it often appears we could discuss nearly anything at all under the umbrella of "performance".
Despite this, much of the discussion now centers around a handful of ideas that appear with renewed urgency in many perspectives.
The two biggest of those ideas are:
- you can't manage what you can't measure; and,
- to manage effectively you must have everyone on the same page.
What makes those two the kings of the hill is that they each address the top problem in management today: operational complexity.
But -- what makes them such frustrating goals is that they each run counter to the "natural" probabilities of how management is exercised...
II.
Complexity is simply unavoidable. Business organizes its performance expectations around capabilities that actually require complexity to exist; and then it brings those capabilities into a game that features constant change. But at that point, ironically, the two most attractive characteristics sought of operations are simplicity and repetition.
Knowing that the knot of complexity should not really be untangled, management at least needs to reduce the number of significant variables crowding its moment-to-moment thinking, and improve the signal-to-noise ratio by deciding which ones to keep and which ones can be left out.
The normal strategy for this is to divide up and distribute responsibility for what must be thought about, so that fewer things must be attended to by anyone in particular. But naturally this brings the challenge of agreeing how to divide things up, and soon afterwards, how to overcome the many silos of information that result.
To recover from that, management usually brings a serious determination based on two resolutions:
- fact-based management; and,
- a single version of the truth.
In the typical management scenario, measurement is relied upon to "establish the facts", and decision-making relies on those facts to establish the type and priority of changes that will provoke improvement of performance. Interestingly, this approach makes it clear that measurement is a form of discovery -- and as the philosophers note, we tend to see what we're looking for more than we see what is there. Analysts further point out that the discovery instrument we use predetermines what can be discovered. Consultants note even further that the instrument is only as useful as its user is skilled. And so on... What emerges is a fairly definite realization that these "facts" -- born as they are through selection and invention -- are simply ideas that find agreement amongst the group of users who are considered to matter. But meanwhile, the discipline used to eliminate arbitrariness from "facts" is nothing other than competition from other facts!
Once we see that facts are actually propositions, the need for management to rely on them must move its focus from the facts themselves to the mechanism that validates the facts. When validation stops, the occasion signifies that the group intending to "stand by the facts" considers them to be "truth" -- and only at that point does management actually use the information to make decisions. In other words, the norm is truth-based management.
III.
Managers are responsible for deriving that truth. But managers everywhere have suffered from and battled information overload and inconsistency. That very experience is what has led many of them, whether politically astute or not, to acknowledge that "truth-based management" has been the reality. And, as the management of business operations has itself been segmented into different component departments or functions, the competition amongst different resulting versions of the truth drives executives crazy.
Hence the call for "a single version" of the truth. What this is supposed to mean is a single set of facts that represent the state of any subject or object to the highest degree of undisputed accuracy. The usual expectation is that this accuracy is practically indistinct from the validation that we've just discussed. But why is this expectation incorrect?
The answer is that the call for the single truth is driven by only one thing: the need for confident interpretation. This need presumes that with "one truth" there will be no contradiction in the meanings that can be drawn from the facts. Contradiction is a strong word, but within its literal definition of "speak against", it simply means that there is more than one way to describe something. In business, that variety is usually the desired rule, not the exception.
Naturally, when there is more than one way to see something, there is an underlying reason. The main reason in management is because management itself is distributed. Having different views of the same facts is justified by the same thing that justifies distributing management in the first place: the need for multiple points-of-observation. That does not conflict with the idea that facts should be accurate -- management should pursue a single version of the facts; and yet because they will be interpreted in various ways, the emphasis should be on the objective of the interpretation, not on the results of every available metric.
IV.
And that brings us to today's circumstances. But what does it have to do with measuring performance?
Performance refers to the degree of achievement towards a predefined target pursued in a predetermined way. Due to operational complexity, it is increasingly difficult to determine the extent to which achievement levels are the result of the predetermined activity path. If achievement levels are too low, too inconsistent, or too brief, then underlying chains of cause and effect must be identified to reveal the mechanism needing adjustment.
But the next thing that management has to do in that investigation is decide what it is that must be assessed about the "performance" mechanism. The assessment problem stems from confusing "performance" with other issues such as "value", "quality", "efficiency" and "execution". The common fault is that one of these issues crowds out the necessary visibility on the others, and poses as the whole story of performance.
In managing the business, each one of these issues is a mandated interpretation of circumstances -- one that results in more and more data being cultivated in a search for more precision in their respective explanations of what's going on. The challenge becomes to select from each perspective only what is necessary to construct a logical end-to-end account of the causes of achievement levels (effects).
The second thing management must decide is what degree of precision is necessary to basing the assessment on measurements. The third thing is then to decide what to do about the results of the assessment. Differences between the apparent chain of causality and the desired chain will have to be rated for their entrenchment and criticality. If the chain is altered, management may need to follow suit...
Most businesses have operated with the assumption that precise interpretation by a manager is the higher responsibility. But complexity is forcing us to realize that the base level of effective interpretation likely lies across management perspectives, not within them. Meanwhile, the higher responsibility within a given perspective is accurate but judicious observation.
V.
In an environment where complexity is the rule, performance is a concept that must be articulated across multiple perspectives. Performance is not just an event; it is the outcome of a competency that navigates diverse opportunities to direct activity towards goals. This often means seeing a single event in multiple ways, to find the chance of making it mean the most in terms of value.
A classic example of a single-fact with multiple interpretations is from the customer service world, where telephone support is expensive by the minute yet building customer relationships is the source of long-term profit. In this situation, the average length of a support call should be determinable with high accuracy and little debate. But the impact of that call length can be assessed in several dimensions. One point of view on a 10 minute call can be that 10 minutes is a high dollar cost. But another view is that the information exchanged in the ten minutes might increase the strength of the customer's efficiency thus loyalty and likelihood of buying again. Or it might signify that the support agent has now finally mastered a range of skills sufficiently to take the full range of issues in a call and resolve it without transferring it (even more expensively) to some other agent. These different dimensions are important to acknowledge and assess, but what should not be in dispute is the fact of how long the call was. Meanwhile, support costs need to be calibrated such that they enable impacts that drive the development of business value for as long as necessary. Since there is that important relationship between time, costs, and impact, the relationship must be managed, not just the parts, if the goal is to "improve levels of achievement against target levels through that means" -- that is, to improve performance.
VI.
In managing performance through measurement, the challenge is to first have an agreed model of performance that is comprehensive enough to address the important multiple dimensions; this is the "truth" aspect, the same page. Meanwhile, within any dimension of interpretation, consistency in point of view should be a goal; that is the "fact" aspect, the measurement foundation. Therefore, a mechanism must also be established to conceptually share "facts" across dimensions.
VII.
The biggest point of complication is where the interpretation of facts is also required to generate new data that must be used as "facts" in another dimension. Experience has shown that the classic way of doing this -- namely, hierarchical rollups of reports across management levels -- must be supplanted by information translation across dimensions.
This means nothing less than that a framework must be in place to provide an architecture of development and interpretation of facts. The framework is used by all management perspectives and levels. It provides a standing logic that explains the nature of the information needed to account for performance -- thus relieving anxiety about levels of accuracy and precision without discouraging them. Without this framework, performance measurement always risks merely replacing, at no reliable benefit, one kind of complexity with another.
Posted by Malcolm Ryder at 7:35 AM | Comments (0) | TrackBack
August 13, 2005
Business-IT Alignment: Three Levels of Change
It's most commonly said that the alignment of IT and Business focuses on the way that IT "delivers business value". Because of the pace and intensity of change within and around the business, the alignment effort emphasizes the need to define and protect both the deliverables and the integrity of the delivery path.
Said more carefully, IT delivers support of the value-capture modes of the business. This clarification points out that business value is not just "created at the IT point" and then run through a gauntlet of business issues on a delivery path.
But even that should be put more precisely. Instead, interlinked value-creating modes in a "value chain" are managed by the business, and IT is managed distinctively at each link, thus affecting the way that business value is ultimately realized.
Viewing that value chain as a hierarchy of dependencies lets us associate certain changes with different depths or levels of intervention, while still seeing that changes can simultaneously and independently occur on all levels. The challenge of alignment is to identify and coordinate these changes.
From the business point of view, change in the business affects the integrity and performance (i.e. success) of that "value chain" on three general levels.
One change level involves the definition of the basic components that are used to construct the business's production tools and procedures. Change alters the quality of the components.
Another and higher level involves the arrangement of the components into the various forms of facilities, resources and locations that the business uses in daily execution. Change alters these forms.
The highest level involves the agreements and expectations by which the business executes its activity towards goals, opportunity, and stakeholders. Change redirects activity and the demands it makes on underlying levels.
The following tabular diagram illustrates the active business elements in the management of the value chain versus change.
- A software application is taken as an example of IT being managed for alignment.
- As shown by the far left column and the center arrow, management expectations drive and constrain the cultivation of value at each link or level.
- These business expectations bear particular ways that IT functionality is developed into business resources.
- In turn, the effectiveness of those approaches is leveraged through operational management that works to confirm and conform the IT utilization to the business expectations.
Alignment must be seen as a business success factor if change across these levels is going to be strategic instead of merely opportunistic. Because the different levels and types of change are each independently sensitive to the strengths, weaknesses, opportunities and threats of the organization, management must continually view and assess the benefits and risks that various changes present to the value chain -- specifically, lowering the risk of driving benefits to the business bottom line.
Posted by Malcolm Ryder at 8:20 AM | Comments (0) | TrackBack
August 12, 2005
When "ROI" means Return on Insight
Best quote of the week comes from Thomas Davenport, director of research for the executive education program at Babson College, who was interviewed by CIO Insight magazine:
The only way we can get people to use knowledge on the job is to understand how they do their jobs, and then figure out some way to inject knowledge into the course of their day-to-day work, not make it a separate thing [they] have to consult when [they] need knowledge.
In this lengthy interview, Davenport also leaves us with the ironic thought that this might be pretty difficult to do for knowledge workers (!) because so often knowledge workers don't expose or formalize the process(es) that they use to get their work done.
Well, that's gotta hurt. As a group, knowledgeworkers are these days tagged as the source of innovations that are the source of business growth. Growth is good, yes? So...
Setting aside the alchemy of k-worker production, we can still always say that the rate at which innovations prove to drive growth is a performance measure, and the resource efficiency with which k-workers produce effective innovations is another performance measure.
But certainly there can be innovations that, regardless of how efficiently produced, prove not to be growth drivers; and there can be innovations that were "produced" outside of any intentionality other than ultimately acknowledging the effectiveness of something unexpected.
This reminds me to bring up Post-It Notes and Silly Putty, two famous accidents that luckily got seen in a different way, were trademarked (or something just as fierce; please take notice), and went on to revolutionize work and play. They exemplify one of the three types of innovation:
- new solution to new problem;
- new solution to old problem; or,
- old solution to new problem.
But which one? What's so interesting about deciding which type of innovation they represent is that it depends on who the customer was. Let's face it, for some people, being able to temporarily copy a comic strip and bounce the copy across the floor had never been a problem. For them, the discovery of the gooey means to do so was... enlightening? Aggravating? Confusing? I found it Compelling, almost shocking, as did my fellow fourth graders.
Thanks to some guy with insight, when the accidental putty was christened "Silly" and re-purposed, it became an innovation instead of sunk cost. How do we assess the "productivity" of that sequence?
Effort of all kinds involves on the one hand the intended vs. unintended, and on the other hand the expected vs. unexpected. What are the possible outcomes? We actually have names for them that are already pretty conventional:
- Intended and Expected: product
- Intended and Unexpected: experiment
- Unintended and Expected: risk
- Unintended and Unexpected: accident
In hindsight, the lab work that failed its purpose yet output the putty dubbed Silly could be called "research" (experimentation); while in foresight, the intent to "salvage" value from the putty could be called "development" (production)!
Knowledge that was contributing to (or at least consumed by) the research is one thing; knowledge that drove realization of the market potential of the re-purposed putty is quite another. The labwork methodology was likely pretty well prescribed, in an explicit way. The likely tacit and intuitive method of recognizing "Silly Putty" might simply not be practically proceduralized. Is this difference one of being mechanical versus organic? Scientific versus artistic? And/or other dimensions?
This inspires me to list key touchpoints in a dynamic that might account for both the "failed" labwork and the "successful" marketing vision:
inspiration -> improvisation -> insight -> innovation
Inspiration: much of this comes from observation, experience and especially memory; deciding to see or think about something in a certain way.
Improvisation: this is very much like exploration and especially testing, whether it be conceptually and logically as with "thought experiments", or instead materially as in the lab; designing the relationships indicated within the inspiration.
Insight: this is very much like comparison and analysis, especially inference; understanding the implications of the improvisation.
Innovation: on a practical level, this is very much like categorization and especially contextualization; finally deciding what to do with the insight.
In considering modes of injecting knowledge into the "process" of knowledge work, we need to be willing and able to respect the difference between a dynamic and a process. The most important difference is that:
- a dynamic is the behavior of a network of simultaneous influences, whereas
- a process is typically and essentially linear even if it is able to contain detours, shortcuts and sideroads along the way.
It does makes sense that a dynamic can generate a pattern of behaviors that we might finally describe as a process if the pattern is recurring -- or more to the point, intentionally repeatable. But, it might be that the problem of increasing "productivity" in knowledge work is to feed information into the touchpoints of the dynamic in an effectively influential way, rather than to shoot for a process that might not exist.
Posted by Malcolm Ryder at 4:26 PM | Comments (0) | TrackBack
August 11, 2005
Performance from Knowledge-based Quality
Readings and conversations frequently put the question in mind, "what is the difference between managing performance, quality and knowledge?"
Described specifically in the context of a business:
- Performance management provides a practice and methodology for ensuring operational alignment to business requirements.
- Quality management provides a practice and methodology for ensuring production compliance to product requirements.
- Knowledge management provides a practice and methodology for ensuring concept relevance to process requirements.
In all three cases there is an issue of usage (using operations, using production, using concepts).
Likewise, all three are associated with some kind of mandatory success threshold (alignment, compliance, relevance).
But their distinctions are critical.
- Performance is focused on organizational design and purpose. (business requirements)
- Quality is focused on customer expectations and demands. (product requirements)
- Knowledge is focused on role-specific competency. (process requirements)
These distinctions are "sweet spots", not mutual exclusions or boundaries. But their relationship to each other has a typical pattern: generally, the business should assume that knowledge will drive quality to a level where desired performance is enabled.
Specifically, concepts inform the production underlying business operations. But each of those three elements can change at any time; and therefore, their relationship -- as practiced by the business -- merits continual re-evaluation and pertinent tuning.
Meanwhile, each respective case (performance, quality, knowledge) has a management process associated with it that has the goal of improving the state of that case. Thus, to improve its own effectiveness in that responsibility, each management process itself becomes subject to better knowledge, quality and performance.
For example, the Performance Management Process itself should evolve with attention to its associated knowledge, quality and performance.
This shows that as a set of abstracted competencies, the pursuits of knowledge, quality and performance can be applied at many scales in the business, from the task level to the project/process or finally the enterprise level. Consider these examples:
- At any given time or place in the life of the organization, there might be a focus on the "performance" of the Knowledge Management practice, while Knowledge Management is under pressure to help improve business production's Quality.
- Or there might be a focus on "quality" within (that is, the quality of) Performance Management, while business operational Performance overall is additionally being supported by business production's Quality Management effort.
And so forth...
The business needs to identify these various more specific emphases and determine whether or how they are complementary (or at least mutually benign) rather than competing.
Posted by Malcolm Ryder at 10:55 AM | Comments (0) | TrackBack
Discovering and Defending Competitive Advantage with Technology
Bob Evans at InformationWeek posed a conference theme of "Business Process Innovation: Using Technology To Redefine and Reinvigorate Competitive Advantage." As Evans reflects, the current resurgence of business attention to managing business process improvement points to breakthrough champions such as Wal-Mart (and Dell), who present the prospect that IT-based superiority is the killer strategy of the day. By describing "what they do with IT" as business process, the call goes out to get business process innovation underway. Bob asks his readers for a reality check on this theme.
Taking him up on his offer, I wonder and ask might this theme be the right incentive pointing at the wrong problem?
Let's look at a company's business processes -- using the analogy that companies are like athletes. Speaking candidly, when we say "a company" we are talking about its leaders and managers. By analogy, leaders represent the athlete's knowledge of the possibilities of how to play the game, and managers are like the trained muscles of the athlete. Processes are simply ideas conceived and enacted in the heat of the moment of play, but rarely are they sustainably effective except when they originate in *both* the concept and the training of how to play. In other words, business processes are a company's "technique"... Yes, it can be memorized, rehearsed, reused and optimized, but technique is not automatically the same as advantage.
Actual competitive advantage originates in having the competency to exploit opportunities anticipated by the understanding of how the game can be played. Otherwise, advantage is just a theory.
Athletes who rely on competency win more often and longer than those who rely on something else. And competent athletes with a better understanding of the game realize that they have to keep refreshing and expanding their competency, to exploit the opportunity that can be envisioned in, and that can develop during, the game. By implication, at least, one's competitive advantage exists because your competitors have an inferior understanding of the game, an inferior preparation for the game's opportunities, or a mix of the two defects.
Unless your technique forces your opponent into those deficiencies, it is rather not likely that you have advantage simply because you have better technique. So, changing technique is not particularly useful unless there is already an expansion or shift in one's understanding of the game. (This understanding is what Brad Gilbert gives Nick Bolleteri's tennis geniuses to make them better than they already were.)
If all things other than technique were already equal between competitors, my claim about technique's limitation might be false. But since all other things are usually NOT equal, most companies do not have to rely on innovation of technique to establish or renew competitive advantage. Instead, technique for most companies is about survival, not advantage, and to get an advantage they need a privileged opportunity. The question for them is how to get that opportunity.
More likely, technique creates that opportunity when the opponent makes a mistake. But whenever it's too difficult to make the business opponent make a mistake, we need something else to "create" the opportunity -- such as vision or fitness. In this light, we want technology to increase our understanding of how the game can be played and/or increase our effectiveness in exploiting opportunities born of that understanding. But that is not business process innovation -- that's architecture.
So, to directly explain-- not by analogy -- this view of competitive advantage through technology , let's look at the details, beginning with the idea of "competitive".
By definition, the occasion of "competition" exists because there is a limitation on the availability of an opportunity. This still allows two different perspectives on the competition: one, who gets the greatest availability; and two, who gets the most out of the effort. This duality is why "agility" and "performance" are so strongly linked in the innovation of management itself, where formerly "strength" and performance were the focus. But let's assume that we're always talking about the condition of being competitive, not the results of the competition. Here, we'd want technology to support our new focus on agility.
Next let's work with the idea of "advantage". This idea has to mean "having the higher probability of gaining a decisive slice of the opportunity's availability." There are various ways that this might occur. And let's say that "a higher probability" is a relative position: then there are various interesting positions. Using technology to approach them makes sense mainly to the extent that those ways have already been identified. But the additional question is, how might technology help us to discover positions that give us an advantage?
Next there is the understanding of the "opportunity" itself and what it depends on. For example:
- If the opportunity originates in being "the timeliest provider of the most urgent value",
- and if the hold on that opportunity is sustained by being the most capable renovator of the value provision,
- and if technology is the dominant critical success factor in both cases,
then a company's key assumption about the technology is that it "actualizes" the business opportunity by enabling dynamic functional alignment with the opportunity.
In sum, this shows technology contributing to "realizing" the availability of business opportunity (i.e., getting competitive advantage) in four ways or levels, which logically progress (from bottom to top) as:
- persistence
- alignment
- enablement
- discovery
These levels, which are objectives of technology utilization, respectively reflect (bottom up) a company's options, capabilities, relevance and presence in the game.
Any given company may be weaker or stronger at particular levels in this setup, but without significant episodes wherein current-state accomplishment is satisfactory at all levels simultaneously, there is little reason to expect that competitive advantage will materialize long enough to take advantage of it. The secret to the success of the Wal-Marts and the Dells is not the use of technology per se but the awareness of the competency needed to make the difference.
Posted by Malcolm Ryder at 9:18 AM | Comments (0) | TrackBack
August 10, 2005
Distinguishing Effectiveness from Performance
First of all, why on earth would anyone care about this difference?
Simple definitions can quickly point out why:
- Performance is a measure of the actual level of achievement compared to the target level of achievement.
- Effectiveness is a measure of the actual level of impact compared to the target level of impact.
The relationship between the two is also logically simple: operations are managed on the basis of achievement generating impact.
For example, an operation might be run on the basis that creating 10 units of something will result in 100% customer satisfaction. But let's look at some possible results:
- If the operation only creates 9 units, it's performance is less than targeted.
- If it creates 10 units but the customer is still not satisfied, then the operation's effectiveness is less than targeted.
We know that these kinds of things happen, and we at least want to be intolerant of them if we can prevent them. So to put a fine point on the significance, let's look at how we respond to those realities.
The pressure point in this comes from the idea of "managing by results". Many management issues are so closely related to "improvement initiatives" and/or to "problem resolution" that it is necessary to know when responsibilities and accountability are being correctly placed or not.
In reacting to situations, error or confusion here can easily lead to counterproductive or even destructive efforts that mismatch the solution approach and the objective. In addition to mistaken responsibility and accountability, using the wrong person, process, or tool to respond to shortcomings generates inefficiency and possibly even collateral damage.
In diagnosing situations, confusing performance and effectiveness can simply, but profoundly, lead to attacking the wrong problem. Let's call this the "shoot the messenger" syndrome. We want operations to be effective above all else, but when effectiveness is lacking, is it because the performance missed its mark, or is it because the defined customer requirements turned out to be unreliable indicators of the true terms of satisfaction? On the other hand, what if effectiveness was sufficient, but performance had actually missed its mark? Let's call this the "house of cards" syndrome. Does the effectiveness mean that the performance mark (i.e., the assumed requirements) is unnecessarily high, or was the occasion merely one of luck?
Again, the pressure on all of this comes from the perspective of "managing by results".
- If the intent of defining and assessing "results" of operations is to drive the next cycle of operations to meet needs and standards drawn from those results, it is important to carefully distinguish when impacts are being specified as opposed to achievements.
- Then, the implied causality of performance driving effectiveness must be frequently reviewed and re-validated.
- Finally, it is crucial for executives and managers in charge to know that they will neither "shoot the messenger for delivering an undesirable message"...NOR build the business as a "house of cards".
Posted by Malcolm Ryder at 10:26 AM | Comments (0) | TrackBack
August 8, 2005
Strategy vs. Governance vs. Alignment
When is a solution not a solution? When it solves the wrong problem!
Hunting for solutions is so complicated because it is a multidimensional issue.
First, solution approaches vary:
- re-engineering, or "designing the problem out"
- innovating, or defining a new relationship of a technique to a task
- renovating, or correcting mismatches of current configurations to current requirements
Additionally, a choice must be made between pursuing the root cause of the problem or pursuing something less (such as symptoms). This choice is affected by:
- timing
- execution risk
- cost
- agreements
And not least of all, stakeholders affect the prioritization of the solution effort. In general, stakeholder concerns include:
- solution scope
- benefits and liabilities
- safety
These issues of approach, range and priority are almost invariably brought up in discussions about strategy, governance and alignment. Relying on the guidance of these discussions, a very substantial checklist of action items can easily be built. This level of awareness is a critically useful shot of clarity, but how do you decide which action items are the "right ones" to put at the top of the list?
First, defining the list's "top" region should follow the technique of rating alternatives according to both importance (the need for a certain impact) and urgency (the starting time needed to ensure likely achievement of the impact). Items that rate highly on both counts go to the top.
This won't prevent high-priority issues from competing with each other. And the competition doesn't mean that something big should be dropped... But the different items should be distinguished by their purpose.
This is where most of the confusion reigns in the literature about strategy, governance and alignment. There is no debate that most of the concerns in any of those articles and studies are vital to preserving and improving business opportunity, but that doesn't automatically communicate how to incorporate the advice at the appropriate times and levels of the organization's operations. Such incorporation is a critical success factor to the solution really being a solution.
Too often it seems that every concern is trumpeted as an item essential to every cause, whether the cause is strategy, governance or alignment. But if there is any importance to the different names for these causes, then how can the most effective distinctions between their respective basic concerns be drawn out?
The quickest way may also be the most reliable and comprehensive. Often the difference between the causes is mainly a difference of "perspective" -- and perspective is something that by definition is generated by looking around from a certain point of view. It is possible to see the same item in more than one perspective (or literally, from more than one point-of-view), and this is how the same item comes up in different stories. But the item's meaning can and often does vary with the perspective. The trick is to detect that difference, and this relies on point-of-view.
We can describe the key organizational management perspectives called strategy, governance and alignment, as follows:
- Strategy: addresses needs; needs are about the values of the organization, which reflect its idea about where it is in the scheme of things and what importance is attached to that position.
- Governance: addresses requirements; requirements are about the critical dependencies that exist amongst interactions that define the organization's functioning.
- Alignment: addresses specification; specification is about the particular definition of deliverables that are measured for their level of impact (whether benefit, neutral, or liability).
How confident can we be that these distinctions are correct?
The first way to test that confidence is to simply imagine if there is any importance to the initiatives for strategy, governance or alignment if they did not focus on the key components in these descriptions. Strategy that does not organize things around needs is pointless. Governance that does not organize things around requirements is pointless. And so on.
The second way, in case the first is not decisive enough, is to look at what the three perspectives respectively show us about the organization's current state and therefore what kind of problem is at hand. Generally:
- Failures of strategy pertain to the way an organization became disassociated from the basis of the opportunity that it pursued. It lost relevance.
- Failures of governance pertain to the way it became unable to control the dynamics of the opportunity pursuit. It lost viability.
- Failures of alignment pertain to the way it misunderstood the importance of its output versus the way its stakeholders did. It lost value.
As a result, we can finally understand the differences in an even more rudimentary way:
Is it time to change directions? -- Strategy
Is it time to change the rules? -- Governance
Is it time to change measures? -- Alignment
In order to follow up on any of those three things, certain actions prove to be constructive, and some of those actions prove to be constructive in two or even all three of the areas.
This further explains the recurrence of certain points and advice across all the various topics. But the key to their being "successful" solution components is to understand why it is important to achieve the difference that they make, set expectations accordingly, and then use them explicitly for that reason.
Posted by Malcolm Ryder at 11:08 AM | Comments (0)
August 6, 2005
When your Objective is to define Objectives
One of the best sets of definitions I've seen to distinguish goals, objectives and actions is a Planner's Guide having nothing to do with IT or business strategy but simply with organization. Getting to the point immediately, the guide states, "Objectives are more concrete than goals. They represent results we want to achieve within a specific time-frame."
It's seemingly a simple, efficient definition, but looking into it carefully, there are several points worth elaboration.
For one, the idea that "we want" means agreement amongst all parties. It is assumed, furthermore, that the relevant parties have some form of authority. The interesting question to ask here is, which came first -- the relevance, or the authority?
For another, the idea of "results" must be defined. This is most often where things get really confusing unless some standard or categorization is in use. For example, either of the following could be seen as the path to results we want to achieve:
- meet a specified requirement (would be "agreed", but could still be arbitrary)
- satisfy a critical dependency (would be logically mandated by a model, but the model might be hypothetical)
Although those two paths can account for virtually all instances of "results" we might consider, they both typically leave plenty of room for debate or negotiation amongst stakeholders about how important the result is to each stakeholder's perspective on fulfilling the ultimate purpose. Why is this the case? Because the truth is that depending on the active perspective, all "requirements" are not necessary, and many "dependencies" may be unknown or overlooked.
This points to the need for first reaching agreement on what the meaning is of the stated ultimate goal or purpose. From there, defining objectives is a step that begins to build a model of fulfillment for that purpose.
The general experience of practical science is that many phenomena are observed before they are understood. When a mechanism has been observed that succeeds at fulfillment, it tends to be adopted as the model until something else appears to do the job better. Comparing the dynamics of the two different approaches can yield an explanation of why one works better than the other. If obtained, that explanation typically becomes adopted as an "objective" of the fulfillment effort.
Modeling fulfillment is an exercise that runs in two directions -- analytic (diagnostic) and synthetic (inventive). But in management, based on the example above, more objectives are likely to be iteratively discovered than theoretically conceived -- because in management, "good enough" is largely dictated by "on time." In business, this means further that it is typically less expensive in the end to do trial-and-error based on known precedents.
Analysis is a method of attempting to discover precedents in order to make them known; this is generally called "business intelligence". In this way we can see that defined objectives may be the result.
A famous example of this is the original "Chaos Report" from the Standish Group in 1994, which studied the performance of project management in fulfilling the goal of "successful project". A standardized working definition of the goal -- "success" -- was applied for all projects studied. Projects were evaluated for success or failure. Then, reasons for failure were catalogued. Since the moment that the information was published, the "failure-reasons" have been dealt with as project management "success factors" -- where avoidance of failure is predicated on meeting the requirements of eliminating those errors that lead to failure. The Chaos Report ranked these success factors in order of highest criticality to lowest:
Project Success Factors
1. User Involvement
2. Executive Management Support
3. Clear Statement of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision & Objectives
10. Hard-Working, Focused Staff
So -- are those ten items "objectives"?
As an experiment, let's group those items into a smaller number of categories.
- Buy-in: items 1, 2, 8, 10
- Stakeholder Communications: items 1, 3, 5, 9
- Technical competency: items 4, 6, 7, 10
It's not difficult to imagine that timely, persistent buy-in would result from successful communications about relevant capabilities. Since that logical interaction is a way of modeling support of projects and thus adding assurance to the project's potential fulfillment success, then are the three categories "objectives" ?
The answer is Yes, from the perspective of "project support"...
But how about from the perspectives of "project control" and "project development"? Those are two equally important aspects of project management. Each aspect may need a respectively different group and grouping of success factors, which might lead to differing higher-level requirements or dependencies being identified.
But in any case, this generally suggests that a diagnostic approach to performance will yield success factors that roll up into objectives, with objectives being categories of desired effects.
In quickly surveying (via Google and Teoma) a history of related terminologies, the term CSF (Critical success factor) is generally synonymous with "Objective", while the measurable execution of action and events underlying the CSF is typically referred to with the concept of KPI (Key Performance Indicator).
Yet the problem persists that a logical distinction of underlying issues largely depends on what "goal" is considered to be the top-level starting point and who sets that point. How do we bring a standardized discipline to branching or cascading from the starting point, regardless of where it is?
An important related observation fitting the bulk of those here in Archestra's content is a simple one: acts and events underlie execution, and execution underlies performance. Said another way: behaviors have effects, and effects change states. Objectives are typically concerned with important states. In parallel to that:
- the ten sins of project chaos that Standish uncovered would be seen first as execution items (KPIs, effects) needing better underlying behavior (operational success factors);
- and the three derived categories of effects are performance-level success-factors (Objectives) representing positive states or conditions needed for success.
For another extended discussion of this issue, visit BPMMag.net
Posted by Malcolm Ryder at 12:37 PM | Comments (0) | TrackBack
August 5, 2005
Communications in Performance Management
The number one problem in managing performance is not a matter of correct processes but rather a matter of knowing what is currently really going on. Therefore, a proper solution offers an integrated management communications platform that allows all members of the organization to:
- continuously observe and immediately understand the context and implications of operational events;
- communicate the issues pertinent to the observations and understanding, and appropriately collaborate on timely follow-up decisions and actions that create or restore critical alignment of activities to the directions of strategic and tactical goals.
Observation becomes meaningful when the items within view have definition. In performance management, the importance of communications is to indicate the impact of events, but this cannot be done unless both events and impacts are specifically and suitably defined. Events are defined within the mode of monitoring, and impacts are defined within the mode of interpretation.
Understanding is accomplished when the definitions allow relationships of events and impacts to be determined and classified, and when those relationships can be used to account for the status and dynamics of circumstances both present and future. Typically, this understanding is represented in a degree of compliance to rules and plans that are intended to control the status and dynamics by force of design.
As imagined in the diagram above, the performance management solution must bring practical visibility to the fact that any of the terms of the operations environment, and any of the values in the management context, may change at any time.
Changes will affect the events and impacts observed, thus their relationship can change and take on a different meaning. Ultimately, what the "manager" must attend to is the need for orchestrating the changes in order to direct affairs in a logically calculated way towards the desired meaning. Given the number of variables involved, the role of "manager" may be executed collaboratively; therefore, a major purpose of the communication is to assure that the currently desired meaning is known to all parties in the management collaboration.
Posted by Malcolm Ryder at 7:20 PM | Comments (0) | TrackBack
Value Capture through Execution
What is the real point of an IT business case?
Most proposed changes to the IT infrastructure of a business are intended to make "execution" better. Better execution goes by many names: productivity, efficiency, resilience, intelligence, and more. Since a proposed change typically competes for attention and support against other proposals, the idea of "better" cannot be separated from the sense of what is "necessary"... This means that agreement on priorities must occur, and the black arts of winning agreement commence.
Certainly, the job of presenting a business case is to win the agreement, just as a prosecutor or defense lawyer is out to win. Yet in competition, these adversaries are unified in taking the same piece of strategic advice: "Don't confuse your issue with facts!" In other words, they openly give each other permission to exercise poetic license. But if your business decides to accept this modus operandi from its managers, then it should also just dispense with the requirement to argue in terms of ROI, as well.
In fact, the ROI bit is often misguided, anyway. If building engineers were held only to the standards that ROI calculators so often are, we've have to conduct the business mainly in large disposable tents. Why build a business case that won't stand up?
Instead of ROI, the business case should be argued on value. Strictly speaking, value is what you call the importance of a difference. If that importance is measurable in dollars then so much the better; but since the dollars come from the value, you first have to make the value . And just how is that done? A business case must be able to identify and convey the value generation. To do that, it has to start with a logical understanding of the phenomenon.
Let's start that with a solid working definition. Execution is: the pursuit of a goal, as based on certain enablers (means), in the context of desired types of achievement.
Organizing activity in terms of execution is the typical result of planning. Plans therefore might be prescriptions, formulas, methods, programs, or other designs for interaction and interdependency of activities.
According to the achievement level realized in execution, we say that a certain "performance" has occurred.
According to the importance of that performance in its context, we say that "value" has been generated.
The most straightforward example of a practical context is an objective. That brings us to the key point: that value accumulates towards an objective, and different types of value may collectively apply to a given objective. (For example, imagine watching various contributions of cash, supplies and services push up the red dye in the big "thermometer" poster used to advertise progress in a fundraising campaign...)
The objective represents a concern such as a perceived business need -- essentially, a strategically critical success factor of the way the business believes it must be or act in order to generate "business success". The most straightforward description of the business success is (when properly defined) the mission statement. Usually, a mission depends on several different things coordinating and cooperating effectively, which indicates that there is a variety of ways to add value. At any time, based on the collective effect of those things, the status of the pursuit may thus be deemed more-or-less "successful".
From that perspective, the proposal's idea about changing the way that the business is enabled to execute must always be, logically, about:
- improving the value of its performance, which means...
- improving the achievement of its underlying execution, which means...
- improving the effects of its enablement.
Therefore, any enablement option is meaningful because of its presumed and targeted effects; this describes the basic level of discussion of a business case for an enablement proposal.
Will the witness please answer the question!
Typically, enablement is seen as a deployment of resources, with the now classic categorization of resources being people/process/technology. Of course, there are other resources -- such as time, money and permission -- that are equally critical. But here, the main point is that investment in enablement will be directly attached to ways that resources are affected (moved, added, changed, combined, deleted), and those ways will be described in a plan. The resource view of the investment, however, is merely the left side of the proposal...
The right side must attach the investment directly to the execution that will drive "performance." How? Since value is derived from execution-in-context, and since the context is about what kind of difference is made, then what must be understood is the difference claimed to be addressed by the type of enablement proposed for funding.
As described by example of the following chart, this is a general perspective on planning and justification. The chart gives answers to the question "what is it about the business that the proposed enablement will affect, and how?" The answers to "what" are (across the top) aspects of the business for which improvement is a desired benefit. The answers to "how" are (down the left side) itemized issues that represent success factors addressed in the planning for performance.
In viewing this chart, it is important to remember that the overall business goal is not "value" but instead that the goal is a "mission success" -- a success that is predicated on the value added, by execution, towards business benefits. These benefits (across the top), which are high-priority for the business, are thus understood to be "objectives"... Finally, in our scenario, where the proposal is going to bring a "new" configuration of technology to the existing situation, the IT organization gains more power to enable the business -- which makes the IT organization more successful; therefore, the types of enablement that the proposal identifies are logically seen as "objectives" (down the left side) of the IT organization. This lets us understand why funding the proposal is an investment in both the business objectives and the IT objectives.
What's clear from the above is the investment idea of value for money. Each of the issues in the chart (such as exposure, efficiency or capacity) is an opportunity to generate value, using the support of funding. What's important about the detailed logic of the discussion is that "value" is not left casually misrepresented by so-called ROI. Instead, value is something showing explicitly why the proposal makes sense; and in turn, that provides more logical support for economic impacts that are associated with the proposal. Without establishing the logic of the value-generation, calculations of economic impact are speculative.
Punchline: ROI does not validate the business case; instead, the business case validates the ROI.
Posted by Malcolm Ryder at 3:08 PM | Comments (0)
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 6:34 PM | Comments (0) | TrackBack
August 3, 2005
Business Cases: a pound of prevention
My colleague Sid Kemp, President of Quality Technology & Instruction, Inc., zeroes in on a "point of sale" aspect regarding ROI when he comments on my previous post ("ROI: the Echinacea of Change").
I described a problem wherein false expectations are placed on the meaning of ROI, leading to its misuse. The question Sid asks us to consider: how do you make ROI most effective when it most matters?
Here's Sid's comment, en toto. He promises a very healthy elaboration of this in later efforts that span articles, workshops and other items.
"This article [Ryder's] assumes that return on investment does not measure value. Granted, forecasting value is very difficult. But I believe it is possible to forecast value, and then use an ROI calculation as ROI = (forecasted value)/(forecasted cost), adjusted for the time value of money.
What about value that is not quantifiable, called soft-dollar value? I recommend that each competing project be required to submit a business case in identical format following standardized development procedures that identify ROI, soft dollar value, alignment to business purpose, and a feasibility assessment.
- Project managers can assist the best possible executive decisions by performing this analysis and providing this information.
- Executives can provide PMs what they need by defining and communication the value they are seeking to deliver to customers and to the company and setting performance goals.
The business case -- including ROI -- can then be used to align projects so that they create optimal value. Executive evaluation of the business case can support the fact-based decision-making in project selection.
I would suggest that ROI is more like a heating pad for a strained muscle than Echinacea for a cold. Misapplied, ROI does more harm than good. If used as a single remedy, ROI is insufficient. If used properly, and in combination with other methods, ROI --like a heating pad -- is a useful part of the solution.
Sid Kemp,QTI, Inc. (Copyright 2005 QTI) "
This is clearly a good overview of organizing a use of ROI.
BUT... I can't resist running the pitch in slow-motion for a bit, to see the seams and spin of the ball. The two things that I think are worth special consideration are as follows:
1. How do you put a financial measure on "value"? Here, I'm using the customary Archestra definition of "value" as being "the distinction that makes the difference". Value is a state, and in most business instances it signifies "a desired state having given importance". This makes it clear that value can be represented by many modes of description, only some of which are numeric. When we attribute a dollar impact to value, we have to provide the reason for which -- and the logic by which -- that dollar amount was associated with the achieved state. In that logic, assumptions will have to be tested. This means that executive evaluations have to test the assumptions and determine their plausibility. (To consider the effects of not testing them, take a week off and Google the phrase "voodoo economics"...)
2. What is "soft value" ?? Here are two good ways to show it, the first of which is the head-knocking cartoon by S. Harris about assumptions, called "Then, A Miracle Occurs..." A lot of venture capitalists in the Dot-Bomb era saw, in effect, elaborate powerpoint versions of this cartoon titled (ahem) "Business Model" -- but to be fair, it hasn't gotten any easier to describe the miracle than it was in 1982 when M. M. Parker wrote his "Enterprise Information Analysis" paper in the IBM Systems Journal and presented a taxonomy for intangible benefits --turning the lights on with his observation:
"As a system grows and supports multiple functional areas... it can no longer be readily expensed to products or product lines because of its sphere of influence over the ... total management structure of the enterprise."
It's not the value that is soft! It's the measuring system. Today, most of what is in Parker's taxonomy is considered to be "key performance indicators" or "objectives".
NOW... Where this matters the most is against the idea of what it means to "create optimal value." The easy way to handle it is to rely on executives taking the responsibility to say up front what is most important -- because for the record that is what the company's management will consider to be most valuable. But that is not a forecast. And when executives (as managers) do that, are they referring to (a.) the formula (model) for success, or to (b.) the after-the-fact dollar-impact of the outcomes? The answer is, it can be both, therefore it is not necessarily the latter. (That said, I'll keep an eye out for how Sid Kemp forecasts value.)
Meanwhile, to understand how "valuable" soft or intangible stuff is, just name it explicitly, then plan on leaving it out, and then watch the credibility of the proposal's forecasts disintegrate. It starts to look like the soft stuff is actually at the hard core...
Forbes Magazine and Ernst&Young drilled down on this issue in the year 2000 with their Value Creation Index , making explicit the point that the high-performance companies have certain attributes that are the critical success factors of their performance and thus their corporate value. Companies without the attributes simply did not lead their markets nor their industries. Further, different markets and industries required different attributes.
And this is the point of their Value Creation Index: performance is something that can be modeled, and executing to the model is something that can be measured. The model makes certain kinds of execution important, but that is operational-level value. In the end, the importance of the impact of the execution is context-sensitive, and there is another level of value determined in that context. An objective, market or industry are each examples of context.
Value is firstly the importance of the impact. Assigning dollars (i.e., "worth") to that impact is a follow-up step that may or may not be done. To easily recognize this difference, consider that a non-profit organization takes grants (investments), executes, but then does not measure its value in dollars; rather, its value is in the outcomes that its constituents find beneficial. Donors understand this, and they are not looking for dollar "payback" to themselves as a "return" on their "investment".
So what about forecasting value? Forecasting execution and forecasting context are both essential to forecasting the likelihood of achieving desired value from targeted performance levels. A given performance level is more likely to generate certain levels of value, and less likely to generate others.
What must be understood is the requirements for reaching the performance levels necessary to the value targets.
Then, investment in meeting those requirements should occur.
Payback on those investments might be arranged to occur regardless of the performance level reached. But payback on the investment is not the same as the worth of the performance's value. Investors must understand the difference and make arrangements accordingly.
Posted by Malcolm Ryder at 11:54 AM | Comments (0) | TrackBack
ROI: The Echinacea of Change
The trial results are in. The University of Virginia most recently confirmed what has been repeatedly determined in earlier testing: that the most popular non-pharmaceutical remedy for the common cold simply doesn't have any scientifically evident positive effect.
Key commentators on the new results pointed out on NPR that because of the way colds work, there's no difference between the way a cold subsides with echinacea versus without -- and it won't subside any sooner. So, why do people take it anyway?
Clearly, some "benefit" is being obtained. It's just not the particular benefit that people use to "officially" justify their use. For the most part, people actually take echinacea because:
1. it's important to them to take action -- specifically, to do something therapeutic that they control themselves but that must therefore be low-risk;
2. their judgement of credibility about what to do is largely driven by the credibility that they attribute to people ("act-ors") who they personally know or identify with -- which includes friends who use the stuff;
3. and here's the zinger: they hear about people using it, so often that they have become suspicious of what it would mean to not try it.
What we know about the sum of these influences is that people will likely keep taking echinacea as long as it does not become inconvenient and does not prove to hurt them. OR... until something else comes along that fits those three conditions even better than does echinacea. (Likely, however, it will take equally successful "viral marketing" of the upstart challenger, to actually alter their preference.)
Of course, it's great when that cold you had finally goes away; and when it's over, it is easy to attribute the relief to whatever you were taking during the malady.
And right there is the lesson for business. In business, when confronting change, the top self-therapy has been "ROI", although over and over again it turns out that as a medicinal it has little to no impact on surviving a business change. The change commences, and progresses how it progreses, ROI or not. In the culture of a very high percentage of sustainable businesses, accepting and executing a controversial proposal is like catching a cold.
Why? Because, we treat it that way. Excepting when we already know we are being hurt by current conditions, we naturally resist change. But what testing proves is that ROI is frequently an attractive "additive" to change, like echinacea is to a cold, not because it "cures" the stressful situation but because it cures the anxiety about the situation.
This might not be such a bad thing, though. One could argue that feeling better about having a problem helps other parts of the recovery mechanism to be more effective. The biological benefit of lower distress is that valuable energy is not diverted from the mechanisms that prove to be directly critical to improvement. This is what the approval process is all about in business: stress reduction. And ROI's role is to improve approval.
So what's the harm? Well, as the famous saying suggests, give some people a hammer and they think all problems look like nails. If the use of ROI crowds out the use of what is really needed to solve the problem, then the real problem is not being solved.
The danger in mis-use of ROI is in applying it as if it was a measure of performance to distinguish competing opportunities. To show why this is true:
- begin with a definition of what "opportunity" means
- describe the difference between what life is expected to be like if the opportunity is realized versus not
- rate the probability that executing towards the opportunity is any harder than executing towards a different and no less interesting alternative
What comes out of that is:
- a direct consideration of how competency and scope relate to each other, and...
- a direct awareness that the viability of the opportunity only exists within those terms. These are not formulated by ROI.
For managers, the punchline here is that ROI should not be used to describe why it is important to do one proposal versus another. Instead, ROI should be used only to provide incentive to parties who might support proposals that need to be executed. As incentive, ROI can be a "success factor" -- but the actual value of doing the proposal is determined by how important it is to achieve the changed circumstances targeted by the proposal -- that is the true value of the proposal's objective.
With competing proposals, Choice A may have lower ROI than Choice B, but Choice B may still be more important! Said somewhat loosely for dramatic effect, it is Value, not ROI, that solves the problem. The challenge is to determine how to measure and represent value; stopping at ROI misses the point.
But what about that viral marketing for the newcomer? Look no further than Performance Management.
Posted by Malcolm Ryder at 7:50 AM | Comments (0) | TrackBack
August 2, 2005
Laisse Les Bon Mots Roulez
I still don't know who Kathleen P. Wall is, but her collection of Cool Quotes for With It managers was too good to not pass on -- primarily because one of them is from a hero of mine, Eric Severeid. If you're too young to know who he is, you're still young enough to do something about it and get the credit; and there's always Google/Alta Vista/Teoma/etc.
"The chief cause of problems is solutions..." Eric Sevaried
"It isn't that they can't see the solution. It is that they can't see the problem..." G.K. Chesterton
"A solution is no better than its implementation..." Kepner and Tregoe
If you read her paper, you get a Gandhi quote too, but I didn't like it.
Oh yeah, okay, it turns out that Wall is (or was?):
Kathleen P. Wall, Vice President at CMS Healthcare Solutions, Inc., who has over 18 years experience as a management consultant, specializing in operations and materials management. Her background includes systems analysis, selection, and implementation; workflow optimization; and facilities planning.
Posted by Malcolm Ryder at 9:47 PM | Comments (0) | TrackBack