« August 2005 | Main | October 2005 »
September 26, 2005
Competency, Competing, and Strategic Behaviors
When we try to discuss organizational performance, it is often through the question of whether the organization's competencies prove to make its competitiveness effective. And these days, the problem of "competition" versus "competency" merits being called interesting especially because we've found out so much more about how being competent doesn't add up to being competitive despite the costs and lost sleep involved.
Sadly for the management teams of most large organizations, there seems to be no way to avoid spending a huge amount of money on the organization's becoming "more competent" -- because not spending the money almost guarantees that it won't happen. Meanwhile, becoming competent takes time and there's a risk of the competency being irrelevant by the time it matures.
What really helps, then, is to understand how investing in competency does begin adding up to being more successfully competitive.
I.
Ideally, it's possible to clearly state what makes up "competency", so that the necessary investments are well-exposed. Without being overly technical right away, most people would agree that in any given circumstance, competency generally means "effective behavior."
One especially intriguing look into the effective behavior issue is the Booz Allen & Hamilton model of organizational DNA, featured regularly in their publication strategy+business... Organizational DNA dwells on how organizational behavior springs from the internal "programming" of the organization, and suggests that reprogramming will invoke different behavior.
Back in the fourth quarter of 2000, Booz Allen stated, "What sets the top performers apart is the 'how' -- the way they organize and operate to realize their aspirations... The solution lies in changing the organizational environment to encourage decision-making that is aligned with the overall objectives of the company."
The Booz Allen model is aimed at producing solutions that improve organizational alignment with strategy. In this general vein, a typical presumption is that management decisions explicitly pursue an "optimal" prescribed behavior only approximated by real behavior awaiting improvement. Everyone is looking for the secret to improvement.
By 2005, extensive field testing of the DNA model allowed Booz Allen to confidently state:
"To change an organization effectively, concentrate on the deliberate design of four key organizational building blocks:
Decision Rights: the rules and mechanics that govern who makes which decisions -- and how.
Information: the metrics that measure performance, and the practices that transfer knowledge.
Motivators: the incentives, objectives, career alternatives, and other elements that drive people's behavior.
Structure: the overall organizational model, including the 'lines and boxes' of reporting relationships and job descriptions."
Naturally, there are many costs associated with the "before-and-after" reprogramming of each of those conditions... However, the focal point of the Booz Allen "DNA model" is more about the flow of what we often call "political capital". This initially appears in the emphasis on decision rights. But in fact, all of the DNA model's four building blocks have been included because they are (arguably) the factors most affecting decisions.
The DNA model points at the way that decisions (not just the rights) are distributed and made by everyone in the organization, with decisions being the driver of how the organization looks and behaves. While the changes the model supports are to affect the environment for decision-making, the point of the Booz Allen approach is to position and exploit decisions themselves as the generator of performance-critical behavior.
The big issue lurking under that idea is about the difference between how suggested corrective (.e., managed) changes to the environment affects performance and how "natural" changes do. Every day, a huge number of intentional but independently made decisions collectively and "naturally" alter the environment. In detailing that organizational environment, the Archestra view finds and describes a set of basic influences "accounting for" the organizational behavior as encountered by strategy. Since we describe that environment differently from the DNA model, the course of managing it could significantly differ as well.
II.
As does the Booz Allen DNA model, the Archestra account emphasizes that several essential functions underlie (i.e., both constrain and support) the organization's potential behavior at any point. And, when that potential behavior is realized, the behavior is the environment for what comes next. But our functions are different.
DNA says that this environment affects decision-making for better or worse. But the Archestra emphasis is that key performance decisions do not just wait for a friendly environment. Instead, strategic alignment means some decision-making -- not all -- has to work on how that behavior is realized from the underlying functions in the first place; while other decision-making is then critically responsible for whether the behavior executes strategy successfully.
To illustrate these two different layers of effects, first we directly call out the basic "modes" of organizational alignment that provide the environment in which strategy must survive.
Within these modes of alignment, there is a hierarchy of influence, with the most dominant at the top and the least at the bottom. In the interplay of these influences, "competency" leverages taxonomy and standards but is largely constrained by culture. Given that, one thing we can point out is that culture largely determines the competitiveness of a competency.
The alignment hierarchy also exposes an additional crucial dynamic. Namely, within the organization's overall functionality, external or exotic influences such as taxonomy or standards are more readily swapped in and out of the organization from one time to another than are more internal or intrinsic influences such as competency or culture. However, once in, external influences are significantly constrained by intrinsic ones.
In the picture, we see specifically what items the influences work on, noting that those items independently change all the time. Overall, the decisions that bring in and/or shape the four "alignment" influences produce the predisposition aspect of the behavioral environment.
III.
Meanwhile: another essential aspect of the organization's behavioral make-up consists of the way the organization responds to the circumstances that it believes it inhabits -- in short (and coining a term), its responsivity. Typically, this responsivity is what the alignment modes must work on, but when they arrive they find natural forces already at work.
The three key natural influencers of "responsivity" are:
- motivators which encourage certain action)
- generators (which enable and manage action)
- indicators (which suggest action)
More specifically, the interplay of those three influencers "maps" the intuitive dimension of responsivity as in the following picture:
Day to day the organization sees itself in a mirror, noticing key elements (of needs, options and requirements), and directly reacting to what it sees.
But the deeper issue is the way that those key elements are linked by the natural influencers, generating the overall intuitive responsivity -- so what are the origins of those influencers?
In the picture, those origins are awareness, execution, and assessment. The next step in discussing "effective behavior" examines those issues.
IV.
Our first illustration above details the underlying four parts of "predisposition". Likewise, the three underlying parts of "responsivity" shown in our second picture can be described more specifically. For that, one approach is to see the parts -- awareness, execution and assessment -- as tendencies or "characteristics" developed from particular organizational activities and observations.
Awareness is developed from the following factors:
- Decisioning
- Modeling
- Measuring
- Communication
The net effect of awareness is to create the "working image" that the enterprise will have of the circumstances within which it believes it operates. The working image presents options of varying attractiveness to the enterprise. The options are thus motivational. This four-tier hierarchy of "awareness factors" also features, from bottom to top, increasing complexity in the development of the working image.
Execution is developed from the following factors:
- innovation
- collaboration
- optimization
- change
The net effect of execution is to proceduralize activity in the cause of "recognized progress." Understandably, these tend to be the major issues on everyone's operational management agenda. The four factors are stacked relative to each other with the most reactive activity (towards progress) at the bottom and the most proactive at the top. All of the factors are about exploiting requirements, and all of them are at risk without "alignment". Arranged hierarchically, each of these four factors is critically dependent on the factor below it in order to be successful at generating maximum impact.
Assessment is developed from the following:
- Value
- Performance
- Quality
- Risk
The net effect of assessment is to establish the meaning of the "current state" and thus validate or challenge the existing perception of needs. In the context of progress (from execution), assessment tries to understand whether the difference achieved is important enough (or not) to defend the means by which it was gained or to change them. While each of the four factors is a kind of importance per se, they are hierarchically ordered with the issue on top being the most indicative of (i.e., directly relevant to) a specific strategy and the one at the bottom being least so (although perhaps more relevant in general to all strategies).
Summarized from the viewpoint of strategy, awareness must offer encouragement; execution must offer enablement; and assessment must offer clear ideas.
V.
The combination of a working image of circumstances, recognized progress, and an accepted meaning of the current state characterizes the intuitive dimension of responsivity. Again, day to day, the organization sees itself in a mirror made up of those aspects and reacts to what it sees.
But for a full appreciation of how that version of awareness, execution and assessment might really play out as behaviors, the following view gives another perspective crucially important to performance management:
As featured above, behavior is coordinated by approvals, assignments and accounting. Together, they make up the political dimension of responsivity, mediating the otherwise "intuitive" responsivity of the organization and intervening between predisposition and actual results.
The most prevalent characteristic of this coordination is that it is negotiated -- not once-and-for-all, but repeatedly and without guarantee of consistency, due to the continual and irregular influence of internal and external change on the organization. Yet the political formatting of responsivity is what most organizations believe will spawn "effectiveness"...
Since this means that the underpinning assumptions and conditions of the strategy might vary beyond expectations, the organization must grapple with how strongly a policy of adherence to strategy will be enforced. Successful enforcement means resolving the tension between the organization's predisposition and its politics. Even more importantly, since intuitive responsivity is continuously forceful at setting things in motion, the balance of predisposition and politics must "train" the intuition towards the strategy instead of away from it.
VI.
Given the above pictures of predisposition and responsivity, our full account of organizational behavior is based on how the two things affect each other.
From a management standpoint, effective Predisposition presents its influences with dependencies summarized as follows:
- Culture's function of granting permissions involves the relative strength of permission granted
- Competency's orchestration of abilities involves the maturity of the resulting combination
- Standards' presentation of rules involves the degree of adoption generated for those rules
- Taxonomy's offer of definitions involves the stability of those definitions across time and place.
Management can deliberately attend to those dependencies. The current predisposition constrains the likely effectiveness of the functions that make up intuitive responsivity -- by the way that strength, maturity, adoption and stablity are established for each function.
On the other hand, political responsivity will counter-offer different criteria of acceptability and importance to shape behavior, whic can pose a significant problem. If positions, assets or stakes are challenged in any combination, their owners may push for settlements, using approvals, assignments or accounting that either ignore effective predisposition or must attempt to change its underlying terms.
Consequently, if politics compromise the optimal predisposition, then the predisposition will compromise the intuitive responsivity that is the real environment for strategy.
As outlined by these worksheets for detailing intuitive responsivity, very many variables can be changed. Management's challenge is to know where, when and why changes occur -- and to control them by type and degree for benefit to supporting the strategy:
- Awareness details, which combine to envision current states
- Execution details, which combine to create future states
- Assessment details, which combine to determine overall status
VII.
In the intuitive responsivity arena, the awareness aspect's hierarchy of factors bears a superficial resemblance to the Booz Allen DNA model, especially in its inclusion of decisioning. But... the set of awareness factors does not Instead, it presupposes that most decisions have both traction and persistence only when the other three "awareness" factors support them, so if you want a new decision to succeed then you have to "tune" the other factors to support it.
Posted by Malcolm Ryder at 5:36 PM | Comments (0)
September 23, 2005
When is a system not a system?
Peter Senge kept coming to mind after a handful of exchanges with some colleagues about organizations being systems.
To grab a really crisp definition of systems that I knew I'd seen from him, I checked in at Frank Patrick's blog Focused Performance where lots of crisp things get presented in great context.
Frank quoted Peter:
A system...is anything that takes its integrity and form from the ongoing interactions of its parts...Systems are defined by the fact that their elements have a common purpose and behave in a common way, precisely because they are interrelated toward that purpose. - Peter Senge
What's tricky about this definition is the ease with which it's clarity seems self-evident. I can run with the statement up to a point, but only through another point first. Let's be sure we know that when Peter says "interrelated", he's giving us a verb and not an adjective. The elements of a system don't inherently know that they have a common purpose. That is, they have to be "told" about their commonality somehow. The telling involves a lot of things like engineering, configuration, assignment, regulation, and so forth. In other words, we "define" a system by deciding what purpose and behavior it is that the elements have in common. What Peter is really indicating is that if we see a bunch of "elements" and can't decide what is common in purpose and behavior, then we haven't identified a system. In another case, though, we might recognize what we'll call a "natural" system -- in which case we're just saying that the force dictating the system is not our willful invention.
Which brings up another question: how do we know something is an element before we have actually "created" the system by defining it? Usually this puzzle can be solved by taking what we can readily detect, and imagining it as a component that has the potential to be an "element". Once we give the component a job, it can become (or at least contribute to) an element of a system. Even if the inherent capabilities of the component is what gives us an idea for a system, the job actually comes from our idea of the system and may not even ask the component to do what it otherwise might do best. (I really ought to get that PC monitor off of those old phone books, but you know the monitor height is just perfect with them...)
Something related to this is that the more parts the system has, the more chance there is that a subset of the system's parts can develop a new interrelationship and behavior, diverging from the overall system model. So even when we know what components "belong to" a system, we might find that the elements are not sufficiently available.
This gets to the other important thing to think about: the system might be invented or it might be discovered. When it is discovered, it might not be the system that we wanted to find. Then there is the challenge of what to do about the difference. The reason why this is finally so important is that we often invent and activate systems that develop unanticipated dynamics and become different systems from the one we thought we invented. In effect, the system might "find" its own purpose. When that happens, how quick are we to detect it? Just because something's parts are "interrelated toward a purpose" doesn't mean it is cooperating with us.
This reminds me of my working definition of "mythology", which is "occasions when prescription substitutes for description." And therein lies the wariness I have about Senge's definition of a system. I don't disagree with the definition, but I worry about it's use. We should all be careful to find the system that is really there, and not just the one we expected or wanted to see.
The usual practical interest in systems comes from an interest in control. But between engineering a system versus training or coaching one, and between discovering a system versus synthesizing one, the variability in what we should do about systems is pretty vast; thinking in terms of systems gives a distinctive point of view but it's probably the view from the tip of an iceberg. We can be pretty sure that controlling an organization is an iceberg.
Posted by Malcolm Ryder at 7:37 AM | Comments (0) | TrackBack
September 21, 2005
The Objective of Setting Objectives
Working through an approvals process?
"The gap between your personal culture and your corporate culture is what will keep you sane -- or drive you crazy." That's the caution that Steve Andriole from Villanova gives in a great January 24, 2005 article titled Politics, Culture & You.
By pointing out that approvals take place on terms that can as easily be philosophically-based as research-based, Andriole highlights the difference between appearance and reality when it comes to "objectivity". Objectives may make up the known framework for decision-making, but where did the objectives come from?
This is an important issue because an "objective" is, in the practical sense, a purposeful intent -- and the reasons behind that purpose may or may not agree with the motivation behind a new proposal. What's the difference here? Intent simply announces a type and direction of change; but real purpose is about "why" and may even be unannounced.
Now add to this that assessment and evaluation are also different. Evaluation will look for a rational decision based on fixed criteria; but assessment will weigh that decision in a context larger than the scope of the proposal. Approvals lean heavily on assessment.
That said, a proposal will be assessed not just by terms that measure alignment with intent, but also that measure compatibility with the purpose(s) of management objectives. This puts the sponsor of the proposal on the spot -- to understand whether the likely impact of the proposed change really aligns with the value system of the ultimate decision makers.
One way of pointing at this issue is through testing for "favorable demand" -- an approach used by experts such as Charles Chandler of the firm Assumption Analysis. Chandler outlines this amongst three keys to creating objectives that turn out to be reliable and actionable for both sponsors and approvers. He emphasizes that much of what is critical to an approval is "imbedded" in an organization and needs to be carefully exposed as part of shepherding new initiatives and proposals.
Along those same lines, Andriole shows that the implicit and explicit influences are at the personal level as well as the corporate level. By bringing this awareness to the foreground, Andriole and Chandler show why a change that would enable a strategy so often really needs a separate strategy for getting itself approved.
[Click here for a more extensive look into the culture around strategy...]
Posted by Malcolm Ryder at 9:56 AM | Comments (0) | TrackBack
September 20, 2005
Maturing Performance Improvement
Organizations exist in order to enable value to be created from investments.
In this sense, the most general acknowledgement of their improvement sees an increase in the organization's ability to enable value-creation, and/or an increase in the benefits actually obtained through the organization.
Naturally, an executive of the organization has the responsibility to see that the purpose is actually fulfilled by using the organization. But the management of the organization must be primarily about ensuring that the organization is fit for the task of pursuing the purpose -- so this is the focus of management's idea of improvement.
I.
Although "fit-to-purpose" seems like a straightforward, uncomplicated idea, the practical lexicon of "enterprise improvement" consists of many overlapping concepts, and managing improvement likewise consists of many overlapping perspectives such as value, performance and risk. Applying and blending these effectively, without having complexity become counter-productive, is the big challenge to making their influence into improvement as opposed to just change.
In sorting out the overlaps, the conceptual or semantic distinctions allow different roles in the organization to identify the particular issues to adopt as their respective responsibilities -- thereby generating a basis for designing both the infrastructure and processes to actually improve.
Commonly, however, responsibilities for an issue will still overlap after the sorting out has been done. Where more than one role is actively responsible for something, the need is for clarity on how the collaboration is effective for the responsibility.
Similar to the executive and managerial bents, these responsibilities can be readily seen from two points of view: one on requirements, and one on dependencies.
Improvement Requirements:
- Goal (motive) for improvement: such as growth, security, recovery
- Quality (degree) of improvement: maturity, scope, effectiveness
Improvement Dependencies:
- Models (means) for improvement: strategy, governance, architecture
- Deliverables (features) of improvement: agility, competency, continuity, efficiency
II.
In that setup, goals assume that deliverables will enable them, and models prescribe how quality of enablement will be achieved.
However, the listing leaves us with explaining how the two hottest terms in management today fit in -- alignment and performance.
What's universally agreed on is that both things must be managed and both things must be improved. If alignment leads to better performance, and better performance delivers better value, then the emphasis is a no-brainer. But...it's just that the implementation drives everyone nuts.
Relief begins when the situation is thought of slightly differently: better coordination leads to better execution, and better execution delivers intended impact more reliably. In this description, it is more readily apparent at each step that accountability works with planning to influence improvement.
But meanwhile, there are decisions to be made such as whether alignment is to be chased through strategy or through governance or architecture. The different modes affect the organization's potential fit-to-purpose in different ways -- or they should.
For example, coordination (the structural fit) should benefit in different ways.
- Strategy should identify and communicate the target values and why they are targets, thus defining objectives.
- Governance should define policies and programs for linking actions to opportunities as risk-managed capabilities.
- Architecture should methodically specify the integrating and configuring of resources into infrastructure.
Likewise, execution (the practical fit) should benefit in different ways:
- Strategized objectives should influence workload optimization
- Governed capability should influence availability and approval of response
- Architected infrastructure should influence economy versus scope and consistency versus flexibility
Finally, intended impact (the logical fit) should benefit in different ways:
- Strategy should maximize operational focus
- Governance should maximize manageability of compliance to requirements
- Architecture should maximize capacity for repeatability and effectiveness.
When a plan articulates the intended impact and can prescribe (or predict) underlying support (or success) factors at the execution and coordination stages, alignment is being drawn up. But once the alignment drawing is done and everyone sees "what" alignment is, actually making it happen is the daily problem of "how".
III.
This is where "performance" wades into the picture, because the success of making alignment happen is seen as a harbinger of greater things to come. The alignment effort -- especially if conducted as a program -- is executed against certain desirable outcomes, and the degree to which it reaches those outcomes will be looked at as "performance" to be managed. But in the bigger scheme of things, final business outcomes (such as transactions, product launches or contract signings) are being rated against targets and this is "performance" too. The question for both executives and managers is how the performance of the alignment effort is affecting the performance of the business in terms of final outcomes...
Is more alignment closely preceding stronger outcomes?
IV.
The strongest history of argument in favor of alignment driving increased final benefits is usually found in two locations: the Continuous Improvement literature, and the Maturity Model literature. In both instances, the thesis is not just that alignment is a performance "good-to-have", but instead a performance "must-have".
Competition and economics drive the argument in the continuous improvement (CI) camps; the expense of providing a competitively advantageous product is mitigated through proactive quality measures. Meanwhile, complexity and competency stoke the maturity modelers (MM); meeting the multiple obligations of a contracted role is tackled through systematically calibrating defined levels of expectation versus defined levels of effectiveness. Both CI and MM have the perspective of "engineering" improved business outcomes.
With maturity models, however, the problem has developed that there are so many different ones which are seemingly interlinked that it is difficult to understand which ones to use or where to start amongst them.
For example: using a web search engine, one can easily trace consultative literature in IT performance from analysts, researchers, service providers and vendors, to organize a collection such as this:
- Howe School of Technology Management: Luftman and Dell, the Strategic Alignment Maturity Model
- Pink Elephant: J. Duffy, the Strategic Alignment Maturity Model
- Forrester Research: the Strategy Alignment Maturity Model (April 2005)
- InfoTech Research Group (IT BusinessEdge): the IT Governance Maturity Model
- Gartner Group RAS Services: the IT Management (ITSM) Process Maturity Model
With this collection, one finds that:
- the top maturity level of IT service management calls for business alignment
- the top maturity level of business alignment calls for governance
- the top maturity level of governance calls for strategy alignment
- the top maturity level for strategy alignment calls for ...
These interdependencies pose a difficult question. Does maturity in one area depend on maturity in another area (and if so, how much is enough?) -- or does "maturity" in one area simply require a program in another area to be implemented?
Practical experience says that different roles take on different areas of maturation, and the ad-hoc recipe of the interdependencies calls for them to leverage each other's progress. Ideally, synergy develops amongst the different roles, and if so then the most interesting observation will be that the "culture" of the working environment will be intentionally evolving -- whereas the typical approach to this interconnection has usually been to develop a "process".
What management likely needs, to fully exploit the kind of clarity that maturity models can offer, is a communications mechanism that is able to express and correlate the cultural issues and events of the role-collaborations. These cultural phenomena may be the most truthful "performance indicators" -- ones that can be used as inputs into the efforts to optimize the organizational design for its purpose.
Posted by Malcolm Ryder at 6:27 AM | Comments (0) | TrackBack
September 19, 2005
Productizing IT Resources for Business
Directly or indirectly, a "business-view" of IT always asks the basic question, "what do we have and how can I use it?" This perspective connects IT capacity with business capacity, implicitly relying on provision being managed to the requirements of the business.
Given the dazzling diversity of options and sources in all things IT, a framework of "business requirements" will put pressure on the provider to work not just as a supplier but as an agent. In that case, the availability of "appropriate" and "manageable" IT is assumed by the business but realized by the provider. The business attributes value firstly to the provider's process for satisfying business requirements -- and relies on that process.
Successful realization of the right IT for business is essentially the same problem of "bringing the right product to market"... Timing, cost, quality and availability are all success factors in the value of production and provision. Among the worst case scenarios are to bring the right thing at the wrong time or the wrong thing to the target location -- emphasizing why the definition of demand is a dominant issue.
The basic challenge for the provider is to manage value end-to-end from production through provision. Using a simple working definition, practical "value" is the effective difference made towards intentions. In that light, we can easily see that "value" is generated in different ways under different circumstances while across all of that variety it also maintains a common focus on the intention of meeting the demand.
Functioning like a business, the provider has four key stress-points along the course to fulfilling demand. At each stress-point, the balance amongst the success factors cited above can be manipulated to some degree. As seen in the illustration below, each point (bottom left to top right) can significantly support an adjacent point in the chain, so improvements at each point can optimize the overall throughput of value to the final provision. The process alignment cultivates value.
This example highlights the management related to minimizing the risks to the stability (reliability) of the IT environment, as seen from a business point of view. This view features the concern for the value of "what we have" and "how we can use it" -- each as supported through managing capacity and controls.
Posted by Malcolm Ryder at 7:47 AM | Comments (0) | TrackBack
My Enterprise, Right or Wrong
What's the difference between motivation and hype?
In both cases, the "supplier" could get the same showstopper response from the target audience: "Sorry pal,I'm not buyin' it!" -- so it's understandable that, as hopeful leaders, we might be willing to take whichever one we can get away with.
Telling the Oracle/Siebel story is a mini-industry all by itself. But what's more interesting, in comparison, is the Siebel/Siebel story -- the inner Siebel versus the outer Siebel; the issue of understanding Siebel's performance from the standpoint of what employees did and why. Wasn't Siebel run by some of the top managers in the industry? Wasn't it's performance rigorously "managed" in terms of both opportunity and execution? If so, then setting aside the profitability of what it made, what did Siebel actually "successfully make" with its strategy? Did the employees know that was what they were doing?
I.
You remember the story about the hen and the pig who got invited to breakfast by the farmer's wife? So starved for attention was the hen, that she overlooked the menu, exclaiming to the pig "this is wonderful! We're finally getting noticed around here!" But the pig knew that the house favorite was ham and eggs. Replied the pig, "Well for you, this is just going to take a contribution; but for me, it's going to take a commitment!"
And there you have it: you can always play along with the hype; but motivation takes something a bit more.
This all crossed my mind when the dinner conversations swirled around "industry leader" Siebel getting bought by "industry leader" Oracle. For one thing, it seemed too easy to say that it happened because of Siebel's "poor performance". So much for leadership. But on that count, what should we be thinking about Siebel? Did it have:
- a bad strategy?
- bad execution of a good strategy?
- good execution of a good strategy at a bad time?
- or what?
What do the Siebel employees think happened?
II.
For another thing, maybe Oracle and Siebel were not really "in the same business". How the heck can that be? And if so, what was the buyout for?
Well, in business, there are lucrative problems to solve, and there are less-lucrative ones. Our view of competition always casts players in the same game tackling the same problem. For example, some trade journalism immediately discussed the apparent folly of Oracle buying into "traditional CRM" when evidence exists that it's a losing proposition. But could this criticism be missing the point? Even new-look CRM users will have to crunch "CRM data" more and more, and guess where Oracle plans for them to manage that data... (Hint: not on DB2.)
Maybe the market is just speaking up. Maybe it's saying, "you know what? Vendor competition is not making things better for us! Implementations are so complicated, by the time we get through them we can't tell the difference between you guys anyway. Maybe our smartest move is to just be sure that a great alternative exists versus a great standard. Let's have kick-ass hunters, and kick-ass farmers, and not second-raters of either, you know? Let's have a great data-based player and a great process-based player, and we'll decide which one to use."
Does Oracle meanwhile have the capacity to carry legacy processes while pushing into the new? Uhh, yes. Does it have the expertise to create a single serious alternative to SAP and Salesforce.com? Uhh, yes. So maybe we're simply looking at a play for solving a longterm problem instead of a shortterm one.
III.
But as said at the start of this, the more interesting story is the one about understanding Siebel's performance from the standpoint of what employees did and why. Wasn't Siebel run by some of the top managers in the industry? Wasn't it's performance rigorously "managed" in terms of both opportunity and execution? If so, then what did Siebel actually "successfully make" with its strategy? Did the employees know that was what they were doing? Did Oracle? Did Siebel customers?
We're a lot more accustomed to hearing about "exit strategies" in connection with small startups. At one startup I was responsible for increasing the value of the existing customer base beyond the point where the technology architecture offered a chance to increase -- on time -- the competitive value of the product for new customer acquisitions. Down the stretch, we made great customers wanted by the company that acquired us. In such a case, having the executives on the same page across the board (sales, product, alliances, finance, etc.) has to happen, but what's in it for them?
Of course, in larger companies, a huge percentage of employees will have no more clues about an exit than they do about a layoff. During the lead-in period, with marketing still promoting the industry leader hype, what is happening to convert the hype into motivation, and does the motivation cause the organization to internally align around the "wrong" priorities? Or is it simply that we need to learn again to embrace the importance of being able to cut losses early enough to rebuild on time?
If you watch pro sports teams, you often get to see some team's management reach a point in the season when it actually becomes a lot more concerned about being viable next year than it is about winning more games this year. While each remaining game still requires a best effort in the game, the team that is sent in to play the game might not be the best currently possible team. The trade-off of now for later has already been determined by a strategy, and the resulting performance just is what it is from the remaining best effort. This really shines a light on the difference between the final responsibility of strategy versus what we should expect from performance management.
Posted by Malcolm Ryder at 6:46 AM | Comments (0) | TrackBack
September 18, 2005
IT Value versus Business Value
Many of the problems in understanding "IT's value to the business" stem from the desire to jump from point A to point D without going through points B and C.
To trace the proper connections, some basic working definitions are needed. Here, "performance" refers to the relative level of achievement through execution, while "value" refers to the importance of the difference made by the performance.
From that, the points "A through D" in question are:
A - IT Performance
B - IT Value
C - Business Performance
D - Business Value
The usual assumptions are that "IT value" should be measured in terms of business performance, consistently associating the utilization of IT with the business outcomes in a causal relationship. But since IT cannot be used effectively by the business unless IT is managed, the first criterion of IT's potential benefit is whether selected IT resources are appropriate to their intended usage. IT specifications make it clear that "IT performance" must establish the "rightness" of the employed IT for the responsibility planned for it.
Next comes the manageability of the selected IT resources, which determines the day-to-day "value" (i.e., the effective difference to intentions) of the IT.
But successfully bringing the tool to enable the business task does not mean that the task will necessarily be executed well. The harsh reality is that many tasks are now originally formulated on expectations that are impossible to support without IT -- yet the tasks have other dependencies as well, and IT will not "cause" the task to succeed. Meanwhile, utilization of IT per se may be suboptimal, most likely due to complexity and competition in its deployment.
Respecting IT's power to inhibit planned execution, business-oriented management of IT can take a highly proactive stance on mitigation as a support strategy for business capability. The goal is to actively cultivate an operating environment with high compatibility to business performance objectives. For IT leverage, these compatibilities most notably include IT resource management (ITRM), business process management (BPM), change management (CHG) and network/systems management (NSM). In the picture below, we see how business-level concerns with managing the operations environment surround yet are joined by the IT management areas.
In these areas, minimizing inhibitors to leveraging IT resources effectively fosters greater ability to concentrate on driving productivity towards planned and actual impacts that distinguish the business's value.
Posted by Malcolm Ryder at 10:47 PM | Comments (0) | TrackBack
IT Economic Impact Management
ROI continues to be interpreted in a variety of ways. The main reason for the differences is the variety in the definition of stakeholders and of beneficiaries. Users and providers are both stakeholders, but because IT is not accessible except through implementation, users must actually spend on the current and future effectiveness of both the IT deployment and the IT use. Deployment and use usually involve assumptions and concerns about how scale and scope can be exploited, and spending will take place on developing and defending those aspects. The key issue is whether the spending is both smart and well managed -- and the challenge is the complexity that characterizes utilization of most implementations in distributed, heterogeneous operations environments.
What becomes increasingly important is to understand where and how dollar inputs affect the states and events that have direct consequences of economic significance. The table below identifies four major areas (columns) of leverage by which economic impact can be optimized. Each area can be addressed individually; but the combined spending improvements of multiple areas allow more effective overall throughput of investments towards beneficial conditions having economic importance. While the reality is that high benefits can accompany high risks, most organizations want agility and continuity from an ability to minimize risks that divert attention and resources from pursuing benefits. In that regard, the economic throughput of spending-to-benefits can be seen as a combination of lower erosion and misdirection of investments during the lifespan of the dollar commitments aimed at fueling benefits.
Posted by Malcolm Ryder at 7:18 PM | Comments (0) | TrackBack
Aligning Execution and Performance, with Process
Recently the difference between "outputs" and "outcomes" has been a major topic in maturing the management of performance. It is becoming clearer that performance pertains to outcomes while execution pertains to outputs. But if performance depends on execution, then the key question is, how do outputs drive outcomes?
When we say "performance", what differs it from our idea of execution is our intent to talk about how close the impact of execution came to what we wanted and/or expected.
When we say "execution", we're trying to point at the way that things got done on the way to that impact.
But noting the difference, we should also add that explaining the output doesn't explain why it has the impact that it does. We should also ask what makes the impact a probable companion of the output. What we'll find is that the role of a process is to make that probability as high as necessary.
I.
Our most typical perspective on performance assumes that outcomes have prerequisite underlying outputs -- and thus that missing, defective, or incorrect outputs "account for" poor performance.
Solving those problems of omissions, defects and errors takes us to investigating whether the means of execution are properly coordinated. But beyond that, we also need to know whether the conducted execution was aimed in the right direction.
Consequently, solving performance problems, there are two major areas of solution investigation -- both falling under the heading of alignment:
1. Quality: of actual procedural integrations
2. Effectiveness: of actual influence on conditions
II.
Take the "quality" area first. Following the typical advice, procedure investigations would look into the connections between people, processes and technology. In one way, this is intuitively correct thinking; an organization can almost always be described in terms of the way it designs, selects and deploys those three fundamental "resources" for execution. But in more than one way this is a fairly awkward approach unlikely to lead to proper solutions.
One problem is that the three items -- people, process and technology -- are not defined on the same logical "plane". If we were instead to normalize the way they are managed, we would have at least a two-tier set of items with the lower tier being people-events-tools and the upper tier being workgroup-process-system.
The second problem is that execution requires not only "resources" in the sense of items that can be cataloged as assets and "qualified" for duty; rather, execution requires a configuration of resources, which creates the functional environment for execution called infrastructure.
Simply described, infrastructure includes facilities and services for operations. What we've been learning more and more is that infrastructure is an idea that must both shape and accomodate the dynamics of the operating environment, and thus become less exclusively a set of fixed objects and more inclusively a set of controls that direct access and navigation to and amongst facilities and services.
The overview of necessary connections within the infrastructure means that we look at the following configuration and control-related issues:
- people-to-people connections: including workflow and communications
- people-to-systems connections: including applications
- system-to-system connections: including platforms
What this does is to indicate how procedural alignment (and its quality) must be composed for execution, meanwhile making it much more explicitly clear that two organizations with the same "resources" can get drastically different "results" (outputs) from their interconnection and utilization.
III.
Next take the "effectiveness" area. The influence of outputs on prevailing conditions largely depends on how the outputs are actually used. What this means is that it is most logical to understand execution as "production" and then understand the value of that production in terms of how management "markets and manages" the products. Since the value of the products comes mainly from their ability to satisfy important demands, the main perspective of practical use for solving the influence-oriented alignment problem is one of demand management.
What we've been learning about demand is that it must be seen in two ways -- as defined need, and also as defined requirements -- thus the fulfillment of demand is always subject to revision in two directions. The usual situation, though, is that a given party with one need might send that same need to two different parties, and find that each party will differently interpret the need into requirements.
Simply described, demand management by the receiving party defines or discovers demand, assesses it, prioritizes it, fulfills it, and tracks it. In support of that, it includes all the following mechanisms, each of which has an output:
- requests
- analysis
- policies
- routing
- assigning
- monitoring
With the key issue being how those mechanisms are all required to address the particular need, what this does is to indicate how directional alignment (and its effectiveness) must be composed for execution. Meanwhile, those mechanisms all rely on the infrastructure.
As a way of defining the mode of influence that outputs have on outcomes, a process states that "if the need is... then our response will be..." and it organizes the response according to requirements. Meanwhile, by putting that stake in the ground, the process challenges circumstances to prove that other requirements might be necessary or better than these in meeting the need.
IV.
By finding that resources and outputs per se do not determine outcomes, we find that "production" procedures and "product" direction must be managed both separately and together, because they can change independently but must be related for meeting demand. In focusing on their underlying dependencies for the sake of making improvements, we recognize "infrastructure" and "process" as areas in which management creates alignment between execution and performance.
Posted by Malcolm Ryder at 8:00 AM | Comments (0) | TrackBack
September 16, 2005
Justifying Performance - Ambition versus Reality
We often use the term "justified" when what we really mean is "worthy of approval." In casual use, this wouldn't pose any special problem. But when that use goes beyond being casual and gets carelessly built into management systems, the misalignment of Operations and Strategy has exactly the environment it needs. How can this be?
I.
Taken literally, the term "justify" points directly at the idea of alignment. Our issue is to properly identify what is being aligned with what, and what should be.
Much of what we do seeks approval under the heading of "operationalizing strategy". We want to see Operations as being where Strategy is executed, and we think of "performance" as the quality of Operations' execution.
But Operations don't simply "run"... they are driven by management discretion. So what does that discretion really defer to?
Too often we default to the idea that the discretion is justified "by" strategy, when what we really need to know is if it is justified "with" Strategy... Why? Because it could be reasonably justified -- that is, aligned -- with something else, divergent from strategy.
For example: one of the key challenges in managing performance is to control the investment and deployment of Operations' resources by committing to a "performance logic". But a single organization can have more than one such logic -- such as immediate competitive advantage versus capacity conservation; the tortoise and the hare.
Meanwhile, two other different kinds of logic are authority and responsibility. Although strategy has the blessing of carrying very high levels of authority, it must compete with the way responsibilities are distributed, and even with the sources of responsibility -- sources that are often not the strategy itself.
II.
Strategy authorizes action, but it is responsibility that allows it.
Obviously, communicating the strategy gives Operations managers a much better shot at keeping their priorities aligned with the strategy.
But in reality, when managers are caught between what they "should do" and what they "must do", their problem is to drive execution and its supporting resources in a way that matches the concerns that the organization's executives really care about, because -- beyond all lip service otherwise -- those are the terms that will be used to argue that actions should be approved. That is, those concerns will be the virtual "performance criteria"...
So the question is, are the active performance criteria developed directly from the strategy, or not?
In action, procedural effort "reality-checks" the viability and feasibility of the strategy -- assessing whether it is ambitious beyond practical reason.
And if procedural "best effort" doesn't hit strategic targets, the question eventually becomes whether to change procedures or change the strategy.
With either change, the point would be to improve the likelihood of meeting objectives.
And in both cases, starting the resolution of any shortfall in meeting objectives will require reality-checking the current operative assumptions -- such as the practicalities on the Operations side, and the probabilities on the Strategy side.
III.
Assumptions come from a certain view of conditions -- a view that is available at the time the assumption is made. Because of that, they have two big opportunities to change.
For one, later evidence of changed conditions can very well call for revisions to earlier assumptions. Therefore, monitoring those conditions is the basic prerequisite of validating the assumptions.
But two, using two different viewpoints on the same conditions may also bring changes to the surface immediately, in the form of differences from the one take to the other. The simultaneous views or scenarios may compete for primacy and argue which assumptions drawn from them, respectively, are more "valid".
Validating assumptions isn't much help unless there is also a willingness to change them. Managers often hang on tightly to current directions even if the assumptions that originally "justified" them are no longer valid. Why? Although the reasons for that resistance might specifically include political or financial ones, we can count on one general reason being that the expected performance evaluation criteria are not designed to address the strategy's assumptions. In this circumstance, occasions can arise where sticking with the strategy in the face of other risks might not be a compelling idea, or changing a previously approved procedure in order to shift with a strategy might also not be a compelling idea.
The lesson that we take from this is that "strategic" operations, by definition, are not self-justifying. In action, neither are they automatically approved, nor do adjustments to them always follow the same path of guidance.
IV.
A key observation to make here is that we must avoid the peculiar notion that Strategy is not doing anything until Operations gets busy. Strategy is, in effect, a set of evaluation criteria, and in that way we should say that strategy is "applied" moreso than "executed". Meanwhile, Operations is not just activity but instead is the supervising management decisions that define and guide activity.
Therefore, in order to align Operations with Strategy, we need the logical impact of decisions to be consistent with the logic for generating strategic value.
One of the most important things to remember is that the conditions behind the operative assumptions in question are not the effects created by Operations, but instead are the circumstances within which Operations are supposed to work. Operations and Strategy each provide a view on those conditions.
While Strategy's view pertains to value, Operations' view pertains to productivity. Their common ground is "objectives".
Operations' commitments to objectives take their approval from the agreed-upon validity of the assumptions. If this seems on the surface to not be true, just consider what happens when those commitments are tabled or ended: usually it is because they cannot be prioritized highly enough against alternatives -- and that prioritization is defended based on the assumptions.
Meanwhile, assumptions are considered to be important because of the strategy, but a re-examination of their underlying conditions might still invalidate them.
So when monitored conditions present a view of reality that conflicts with the picture subscribed to by the strategy, the importance of the strategic view is at stake, which puts the related commitments of the Operations at stake and even at risk. To protect or restore the commitment, the apparent conflict must be resolved, and the resolution must be communicated as broadly and as quickly as possible.
On that point, see this from the GEAC white paper Strategy Management in the Public Sector:
"High-performing organizations record and monitor assumptions. Organizations usually make a range of business assumptions when they set their high-level targets. These assumptions are monitored. If the business reality is different than the assumptions, the organization
reconsiders the associated targets."
I would add here that reconsidering the targets may not necessarily change them, but it may lead to changes in the way that they are pursued.
Posted by Malcolm Ryder at 11:07 AM | Comments (0) | TrackBack
September 15, 2005
Assessments versus Measurement
In the growing body of literatures regarding performance improvement, the usual recommended starting line is the advice that "you can't manage what you can't measure."
But this allows a troublesome add-on thought, which is that your measurements are going to drive your management mainly in the fashion of "garbage in, garbage out"... The quality of input data is of course a risk, but what about whether the correct kind of data is being absorbed in the first place? Great data of the wrong type will lead nowhere fast, or to the wrong place too soon.
For that reason, picking the right measurements would need to be the logical starting point -- and updated thinking emphasizes that to do that there must be a model or a logic of what matters, not just of what "counts".
What's the difference between what matters and what counts? Observations probably count when they are able to show that they are usually associated with the subject. But showing how their association plays into the importance of the subject at hand is how they mean something. Getting from what counts to what matters means getting from findings to clues to evidence.
I.
As the initial concern of a management process, the notion of "measurement" most top of mind is usually metrics . These metrics are really particular ideas variously used like sculpting tools and fishing tools depending on the circumstances.
But the importance of a higher-level guiding model displaces measurement from that initial position. Metrics gets bumped even a little further away from the starting line by an additional issue as well -- the need to evaluate .
What is the difference between evaluation and measurement?
Typically, measurement determines a state, but evaluation determines the importance of the state. We might determine that it is 28 degrees outside, but having observed the time at which it was true, what does it mean to us? Are we sick? Is it July? Does the temperature matter? How?
But think of it another way as well -- as the difference between a subject and a topic. The subject is what is being talked about; and a topic is a way to talk about an aspect of the subject. Evaluation considers the subject; measurement considers a topic.
II.
Overall, evaluation emphasizes that you not only have to pick the right topics (measurements) for your subject, but you also have to pick the right subject -- which really means to not lose sight of it...
Our friends at the McKinsey Quarterly interviewed John S. Varley, the CEO of Barclay's Bank, who as the new guy in charge had plenty to say to his organization about the difference between what their financial topics appeared to mean versus what they really meant. The short version of the story is that Barclays had fiercely and successfully pursued enviably upward financial results, but largely at the cost of running the company down.
Noting that the organization was managerially unconscious of its "go for broke" mentality, Varley measured the financial performance as positive but he assessed the performance as negative. He saw that the way the big numbers were being hit was actually not sustainable -- in fact, was unhealthy -- for the company.
III.
Assessment takes the broad view of evaluation. It brings perspective to measurements by not allowing them as a topic to overwhelm the subject.
One of the greatest examples of this perspective is Muhammed Ali's famous "Rope-A-Dope" strategy against George Foreman in the 1974 Kinshasa Zaire Rumble in the Jungle. Scorekeeping might have shown Foreman obviously winning round after round on the punch counts, but as the CNN/SI writers put it, "by the eighth round, the 25-year-old champion was running on empty. Ali took advantage to knock out his exhausted opponent..." Ali's bigger picture of the fight, which he'd had at least since the second round, made him the winner.
Another interesting example of the bigger picture is in the Voter Referendum publications in California. Before voting takes place, each issue on the ballot is discussed in printed form with the following points of view:
- arguments for the issue
- rebuttals to the arguments for
- arguments against the issue
- rebuttals to the argument against
For many people, it's a real eye opener to see four different ways to consider the issue. Each point of view is a topic, and each topic is typically fairly persuasive on its own. Taking any one of them, a person might "measure" the ballot issue positively or negatively. But to assess the overall value of the ballot issue (the subject), the four points of view are compared against each other, and so a decision can be made "on balance".
In other words, that assessment model is the key to understanding the real importance of any of the subject's topics.
IV.
When we say that we can't manage what we can't measure, the appropriate response is not simply to start measuring things; the amazing ease of taking things out of context shows that measurement does not equal management.
Instead, by bringing a model to the situation -- one that can define and hold a coherent description of what matters at the subject level -- we get to better observations and decisions using measurements.
It's more fair to say that we can't manage what we can't model -- because without the model, we don't know what is the meaning of the measures and thus don't get a meaningful picture of what we're trying to manage.
All that said, why is it that most times the advice to companies is still to start with measurement?
V.
For one thing, all companies have measures. It's the common denominator. It seems to make sense to "make better use of what you already have..." Often the company doesn't really know another way to talk about its management.
Second, it's a reflection of the need to first actually confirm that a usable picture is obtainable. The real prod there is to investigate how the picture is being taken now. Generally, it's been found that omissions, confusion and inconsistency is significant there, preventing what might be considered a reasonable level of visibility, or producing what might be considered a picture with no apparent composition.
But an even deeper concern of that advice is adherence to the idea that "management" is mainly about efficient production -- one of the top target outcomes of measurement efforts. This is the Frederick Taylor school of scientific management. But the most important difference between 1911 when this school opened, and 2005 well after "hypercompetition" set in, is that the pace of change today is orders-of-magnitude greater and has changed the priorities for measurement -- from accounting for doing the work right, to accounting for doing the right work.
Especially in our era, ineffective efficiency is waste. And that's why deciding what to measure is more important than the measurement itself.
Punchline: in order to manage better, start with assessment. Organizations will find that the key representative concept behind an assessment is an objective.
Posted by Malcolm Ryder at 12:07 PM | Comments (0) | TrackBack
September 14, 2005
The Business Value of IT Operations
It's safe to assume that every IT organization leader in every mid-to-large sized company is being pointed by the company executives at the need to demonstrate IT's "business value". To ultimately survive this challenge, we have to avoid proving the wrong thing for the right reason, and avoid proving the right thing for the wrong reason...
I.
Debates seem basically unavoidable when it comes to deciding what "business value" means. But until the meaning is defined, it's difficult to decide on what should really be included for demonstration. Not surprisingly, the things that distinguish "business" audiences -- their respective roles, objectives and priorities -- virtually guarantee that there will be multiple perspectives on the idea of "value" -- reflecting role-sensitivity. Meeting the demonstration requirements for all of these different perspectives is a gigantic burden on IT managers.
Even when all the bases get covered, too often the results seem to not correlate meaningfully with the business outcomes that the executives themselves are measured by. From 50,000 feet high, Business changes while IT doesn't, or IT changes but Business doesn't... and it seems that the two things are independent -- so a lack of confidence in "demonstrated value" persists.
II.
At the core of that problem is the possibility that the wrong kind of relationship is being hunted down, for no good reason other than that it would be exciting if it proved to be true. Namely, we want IT to "cause" better business performance, because IT is tangible so we hope thereby to mechanize our success.
At some point, though, and let's take now as a good one, it becomes smarter to look for a kind of relationship that shows more consistency.
This can start with leaving behind the idea of "causal" (or systematic) and replacing it with the idea of "systemic".
An important way to address the issue of business value is to ask what business does that is done "better" due to I.T. utilization. This question, which is a particular point of view, looks at I.T. as an enabling resource for business capability. The systemic perspective looks at the influence of the resource on the whole "ability" -- which is represented by the business task.
III.
Capability enablement is achieved through operations that allow the business to leverage the resource, and that leverage practically represents the resource's influence.
To institute this, business coordinates management of those operations as a logical organizational unit within the overall management of business operations.
At that point, a big part of the complication in value assessments is that the "logic" of the organizational unit is not linear. Instead it is multidimensional due to the variety of ways that the unit should establish the leverage business seeks. This is about the variety of responsibilities invested in the role of the operations.
In the case of IT operations, we derive the dimensions from basic expectations, in this way:
- First, business enablement is not the same thing as business execution. Knowing a language is not the same as public speaking. Being trained is not the same as performing.
- Second, managing enablement is a scope of responsibility requiring attention to the form, function, purpose and acceptance of the means of enablement offered to the business by operations.
- Finally, IT operations are the provider, not the client, wherein the operations value to the business is established.
What are the key dimensions of the provider role, as seen from the business point of view?
The model below shows the systemic relationship of the four business perspectives -- supply, production, delivery, provision -- that IT operations is accountable for in its provider role of manager of IT enablement of the business.
As for the value of the provided enablement itself, effectiveness is the essential concept behind assessments.
IV.
Business's ability to use IT effectively is one of the major strategic objectives of IT operations; but effective utilization must have an objectively sensible meaning. If there is real meaning to the idea of "business value", there is no point in holding IT accountable for value outside of the context of the business's management of its tasks. The cost, speed, efficiency, control and impact of the task are representative aspects of the "whole" ability supported by the resource of IT.
The business must find that its dependency on the provided enabler was sufficient for the necessary performance level of the business task. But there is a logical limit to how much the enabler's contribution can be held responsible for the target outcome of the business task. The success factors of the business task include more than the IT component, and the idea of the task's "success" includes more than just the completion or output of the task.
Considering those issues together gives the business fair warning on how to envision IT's involvement in the answer to the question "how predictably and frequently can we do really well what we need to do?" IT does not decide what the business needs to do. But the more IT utilization can be attributed to a positive answer, the more valuable IT is to the business.
Posted by Malcolm Ryder at 9:36 AM | Comments (0) | TrackBack
September 10, 2005
Competitive Advantage
As a former athlete, former coach, and older guy occasionally playing against much younger guys, I sometimes get really sick of hearing all the rap about a "competitive advantage". It's too often brought up as something you take into the game instead of something you make during the game.
So much of the time it has the same problem that comes with the chatter about saving costs. You remember the ridiculous business blared across TV advertising of discount sales in the 80's -- "The more you spend, the more you save!" This makes sense only if you were actually going to spend the money on that stuff anyway.
The point here is, what are you willing to spend to get the advantage?
First of all, heads up: that "advantage" that you're most likely to get is probably an advantage only compared to whatever else you were already going to do. The first order of business is to make your next self better than your current one.
But how hard is it to get a competitive advantage versus a top opponent? If you already have one, it's likely because they're not ready for you. If you don't already have one, it's WAY hard. It makes sense to think in terms of maximizing what makes you different from them, and then playing where your difference counts the most. But either way, the difference will be an effect of an ability. Unless you actually create the effect, there's no real difference and thus no real advantage.
Maybe it takes an older guy to spell it out. Here's my favorite competitor, Andre Agassi, talking about playing against Roger Federer (as compared to Pete Sampras) and bringing it to the point:
"There's no weakness to speak of," Agassi said. "You play a bad match against Pete, you lose 6-4, 7-5. You play a good match against Pete, you lose 6-4, 7-5. You play a good match against Federer, you lose 6-4, 7-5. You play a bad match against Federer, you lose 1 and 1."
And Andre has to play Federer, a genius, on Sunday. Given Andre's outlook, he obviously needs a competitive advantage.
Realistically, he needs to be better than he was today or yesterday, taking out Ginepri and Blake. But he just strung a historically epic match of will and technique together with a slugfest. How on earth could he be better?
We can leave that open to speculation, but while Andre's objective is of course to actually beat Federer, he is all too aware that this could be the last time he plays in a US Open Final, and you can bet that he totally intends to not go down 1 and 1. He's looking first for what he minimally needs to reach 4 and 5, AND he's hoping that Federer makes some mistakes.
If he can get those two things at the same time, he could win.
But what is the situation in which having both of those things is likely?
Again, we can speculate: if things go into the fifth and fatiguing set, or if Federer lets the heavily partisan crowd (favoring Andre) get to him, or some such thing, then being good enough to take 4 and 5 games can be hugely helpful to Andre, while making a few mistakes could be hugely detrimental to Federer.
Whatever it is that would likely do the trick, we can summarize its ideal magic like this: Andre needs something to happen that both makes his own good stuff more valuable and makes Federer's bad stuff even more harmful to Federer. If that condition arises, then meanwhile Andre's own efforts to make Federer's good stuff less valuable (by preventing it!)can become decisive, as long as Andre's bad stuff is avoided.
The punchline: Andre knows that what he needs to do is put himself in a position where circumstances can help him enough to win.
Going into the match, Agassi said he plans to do it like this: "You hit it in that corner and that corner and that corner and that corner, over and over again, and you beat him," is how Agassi described the ideal strategy. "But you've got to [actually] do it..."
I'm not saying that execution is the same as advantage. But obviously, getting the right thing done gives you a shot. Staying focussed on the competitive opportunity is what we should be telling people. Enough about advantage. First things first; it's tough enough to manage opportunity.
Posted by Malcolm Ryder at 8:22 PM | Comments (0) | TrackBack
September 9, 2005
Roles, Jobs and Self-Organization
Organizations increasingly seek agility as a target characteristic of their capabilities.
The value of this characteristic is usually measured at the level of change in external requirements on operations; but meanwhile, agility is really dependent on the ability to re-align the underlying internal functions on demand.
This is borne out by a view of operations over time.
For example, some external requirements do not mean that the type or strength of underlying functions must be changed, but instead merely their deployment; while others call for functions that are not yet executable in the current operations.
Re-organizing implementation might be approached through various steps that add, move, modify or remove functions, and more than one pattern of implementation may satisfy the requirements.
But typically, as the number of functions and the frequency of changes increases, it becomes increasingly difficult to effectively supervise the re-organization of their implementation.
And within the class of patterns that prove to be viable, the first concern is feasibility. Some patterns of implementation are preferable to others due to timing, durability, efficiency, cost, or other matters.
The supervisory perspective becomes the source of rules reflecting any policies and objectives that prioritize implementation preferences. But even assuming that funtional agents can keep up with the rules, can the rules keep up with requirements?
Because change and complexity run fiercely both through and around organizations, an alternative to elaborating rules endlessly is probably more important now than ever before. Organizational performance will depend on whether functional agents meet demand, moreso than whether they meet rules.
The two main ways of looking at functional agents are "jobs" and "roles". This determination can be applied -- as is the tradition to point out -- to technology, processes, or people alike.
We know that jobs are classically defined in a way that anticipates their consulting and following rules. But roles are different. Whereas a job "packages" a set of responsibilities into an assignment, a role distinguishes a contribution and benefit of involvement, without specifying the responsibilities in advance.
Logically, many different jobs can address a role, and in fact it makes sense to see a job as a particular implementation of a role. But while it's important for assignees to know their job, the dynamics of the organization are not revealed at the job level. Instead, describing the interaction of roles is a basic way of identifying how an organization works.
This role-perspective offers a profound potential benefit to agility: when awareness of roles is high, members of the organization can more readily recognize when alternatives at a functional level might still work. This allows them to change within and across the roles -- a behavior that can be called "self-organizing".
One of the most evident drivers of role-behavior is the "self-interest" or stake in the dynamics. Self-organization can be seen as a case of the participants seeking to optimize the investment of their involvement in the organization. Whether this is a survival tactic or a value-enhancement tactic is not irrelevant, but the two possibilities reflect the same essential behavior.
Below, the schematic picture shows a role model in a way that identifies the terms important to the flexibility of the role. The main importance of the terms is that they indicate where the role may coordinate with others (for example, by sharing or complementing) and with other managerial aspects (e.g. as compliance or protection) of the organization.
- Because the many elements of a role are independently variable, a role is inherently flexible, but its flexibility is constrained primarily by management standards and expectations.
- At the same time, adoption of a role by a member of the organization can be spontaneous if the role appears to offer a better "stake" in the organization.
Posted by Malcolm Ryder at 7:21 AM | Comments (0) | TrackBack
September 4, 2005
Culture as Infrastructure for Strategy
Companies often refer to having and using a value system as the regular guiding influence of their culture on their operations.
We know that value systems are backgrounds for approvals, and it's easy to imagine a collection of associated approval processes representing the "system" of the values. In that case, regardless of the particular values targeted, the first purpose of the processes must be to manage the dynamics of approvals, dynamics that exist whether processes do or not. But how do processes get to know about those dynamics and thus recognize the inputs to use?
To identify and communicate about the dynamics, thus initially making them manageable, a value framework should already be in hand. But what does this framework look like?
I.
Creating the framework means taking a broad view of "approvals" -- we need to think in terms of what is accepted regarding the organization's actions and conditions. Naturally, this might involve a range of things like targets, standards and other definitions of desired states. In fact, determining those definitions is more important than the aspect of processes, because definitions must precede processes.
Nonetheless, the current surge of interest in performance management scorecards has everyone looking at a type of operational framework.
The good news is that performance is being talked about in terms of strategy being the value-definer for actions (operations). Seen by organizations as a driver of performance, strategy is wanted for its ability to define the difference that creates advantage -- the most high-level desired state.
But the bad news is that the actual results of actions -- which trigger followup decisions -- are often still not taken in a primarily strategic context but instead in a different (and strategically indifferent) way of defining value, such as cost control, timing, or compliance. The followup decisions -- especially about optimizing processes -- thus may not be aligned with the strategy although they are still reinforcing accepted notions of value.
Typically it's said that when strategy fails it is because of its execution, not because of its design. Organizations have plenty of hustle and flow, but evidently it's not enough. This makes us more deeply consider how it is that the execution would "make the difference" that strategy prescribes. What is it about the strategy and about the execution that makes their connection successful?
II.
This thought inspires us to consider the "quality" of the strategy in a certain way -- in terms of its effectiveness, its fit to its purpose, or in other words, its usability.
Since strategies don't just execute themselves, we have to examine the capabilities of the organization that is responsible for the execution -- both when we're planning before-the-fact and evaluating after-the-fact.
We can't take this notion of "capabilities" for granted: the most distinctive aspect of the word's meaning is "potential". What if the organization is not yet ready, or willing, or able?
Capability - A talent or ability that has potential for development or use... The capacity to be used, treated, or developed for a specific purpose. -- American Heritage Dictionary
Embracing this definition highlights an issue of compatibility between:
- the mechanism used to develop the ability -- namely, management;
and,
- the "raw material" to be shaped -- namely, the organization.
As a matter of strategy, managers direct the decisions and activity of their organizations according to objectives and policies. But even without a strategy, they manage that way as a matter of "best practices" in accountability. As a result, they not only exert a style but also formalize the operating environment in a way that we usually refer to as its "culture". The question is whether this culture results in appropriate organizational capability.
III.
Actual practice can easily fall short. Management style is usually expected to bringing energy, integrity and focus to execution. The natural focus is on maintaining a real-time match of requirements and abilities. And accountability for "performance" keeps the heat on management constantly. Unfortunately, accountability's concerns with "management style" can be counter-productive. Consider virtually any "Top Ten Management Issues" list from the last few years: too often it places heavy emphasis on the individual manager's activity inputs (awareness, decisions and intents) and hammers away on improvement there -- while comparatively neglecting the overall environmental outcomes also created (such as degrees of coordination, capacity, and complexity).
The complicated outcomes collectively called culture are so hard to grasp as a "whole" that we usually have to think of them the way we do a "climate". Climates require adaptation efforts, not control efforts. Through adaptation, some things are more likely to succeed in certain climates (or cultures) than in others. Here, the issue is the great extent to which management style (not the strategy) creates the climate -- through the way it handles objectives and policies.
IV.
Management intends to construct "effective" organizations. To count as a success, management style needs to make an organization that is compatible with the strategy but is also compatible with the climate that the management style itself creates.
We need to be able to discuss management's responsibility for adaptations -- for alignment -- as a counterpart to accountability for performance. Strategic compatibility -- a.k.a., alignment -- means that the culture must not inhibit the organization's approach to meeting objectives.
Pragmatically speaking, the "culture" is a description of how the management style has typically reconciled the opportunities to act and the approval of the actions.
Describing this reconciliation makes us consider both the nature of the organization's opportunities (in particular their sponsors, types, and locations) and the reasons for approving them (impact, importance, urgency). Here, the problem we encounter is that organizations have predispositions that are institutionalized largely through their managers, -- which creates potentialy high resistance to change. To illustrate that, the table below is a device for "mapping" the incumbent pragmatic culture, as typically under the control of managers.
Three aspects of approval make up the formula for describing, respectively, the sponsor, type and location of an opportunity. Each aspect represents a point of consideration and measurement, which may involve a precedent, a rule, a belief, a status, or some other quality that might function as a decisive criterion. Against the items in this mapping, both objectives and policies consider any potential change by asking the question "Why?" The terms shown within the table make it easy to see the many points at which existing objectives and policy could either frustrate or compete with new, different ones being introduced. Getting and sustaining "consensus" support across enough (much less all) of these points of precedent is never guaranteed. Where differences remain unresolved between the current and proposed circumstances, going ahead with the proposition carries risk. Therefore, to begin realizing the opportunity, someone must authorize and support the risk.
But this still leaves a gap to execution unless the organization is effectively mobilized.
V.
And to mobilize further across the gap to organizational effectiveness, management wants to deliberately rely on the culture as an "infrastructure".
Again, strategic compatibility -- a.k.a., alignment -- means that the culture must not inhibit the organization's approach to meeting objectives. That is, alignment needs management's combination of (reconciled) objectives and policies to provide a stable interface that the organization's members can use to consistently identify, anticipate and leverage opportunities and approvals for strategic action.
Strategy management -- through which execution is directed and linked to the difference that creates advantage -- faces the big question: Where does the consistency and stability come from?
"Architecture" is where we normally look to find a disciplined approach to building that compatibility. An architecture provides an integrated set of design and construction principles for developing a structure. Its principles guide the discovery and qualification of components needed to build a structure, and furthermore they guide support for the actual building effort. Those activities are commonly formulated into a production method.
When applied to making an environment conducive for (strategic) performance, the architecture's goal is to "produce" an infrastructure from that environment, which the organization will use as its interface for execution.
That's the hypothesis. Can the culture really be leveraged as a practical infrastructure, describing and guiding processes and agreements needed for desirable performance outcomes from the organization? If this is to happen, first the development of the interface must be managed.
VI.
An architecture in practical use is very often noted for, or even characterized by, both a style and method of construction that it generates. A challenge for managers is to use the architecture to find effective construction styles and methods, instead of imposing styles and methods exotically or incongruously on the organization.
One of the simplest forms of architecture is a framework, something that provides a neutral reference and gets its value from being that way. Arguably, a framework is most often used to guide a construction methodology, by providing all production participants with a common way to coordinate their different perspectives.
To provide guidance, a framework offers dimensions. A dimension is a perspective on the various different properties of something -- in this case on the various properties of that environment envisioned for executing the strategy. The purpose of the framework is to describe key dimensions in relation to each other -- which effectively evokes, classifies and arranges success factors for the properties, giving them higher recognition and attention.
That said, a dimension might be hypothetical (a "what-if"), or it might be discovered by trial and error. Accordingly, some of the framework might consist of theoretical factors; and some of it might feature empirically validated ones.
In the case of an organization's strategic alignment, the framework's job is to bring explicit consistency first to reconciling objectives withpolicies, and thereafter the various reconciliations with each other. In practice, a methodology exercizes this consistency, producing regularity (dynamic structure) in operations.
Managers work from that situation to develop the execution potential of the organization in that environment. Successful outcomes encourage repetition and reinforcement of their related management events; and the overall "learning" informs further progressive development.
VII.
The interpretation of the culture into an infrastructure provides the logical foundation needed for building execution that can focus on the differences that create advantage. Focused on making the difference, opportunities must be important, and approvals must be rational -- but they both must leverage the culture for sustained support.
That scenario depends on management's ability to associate opportunities and approvals with perspectives that coordinate the organization with the operational environment.
Guiding the construction of those associations, a framework offers dimensions for describing the terms of reconciliation that combine objectives and policies with each other. But the framework dimensions must account for the dynamics of the construction.
These realities of mandates and tolerances -- which come from various pressures including financial, political and intellectual ones -- complicate the (procedural) determination of just how "important" or "rational" things are.
The diagram above illustrates reconciliation -- showing the true direction of influences when the incumbent organization will be the resource for the execution of a strategy.
For strategic alignment, the picture raises the question of whether the objectives and policies initially in hand must be compromised or not on the way to execution. Although we intend to derive requirements from objectives and then execute on requirements, we can't get that done until incumbent policies and abilities have had their say.
VIII.
This multi-variable equation may go through many iterations of "if...then" before being resolved -- whereupon finally the resolution can be executed; but the question is whether the resolution is adequate to the task of realizing the strategy. Is the execution, as based on the resolution, capable of solving the right problem?
In that light, it's clear that the organizational ability finally offered to the strategy must be developed for the strategy in the intermediary stage.
In handling risks and priorities, a progressive development effort in "strategic capability" should incorporate four coordination practices:
- business analysis,
- change management,
- resource optimization, and
- assessment.
These each provide a perspective that is part of "framing the culture". Each of these steps brings the incumbent organization closer to alignment with the needs of the strategy, but all four of them must be directed at the particular strategy instead of merely at the desire to come up with something approved to do.
Meanwhile, each step also tries to coordinate the organization with the operational properties of the environment:
- rules,
- knowledge,
- events, and
- communication.
As part of the framework, the properties will complete the stable reference picture of the "cultural" dynamics.
Management can use the framework to research and specify expectations, preferences, responsibilities and roles that directly address the elements of the strategy. This provides an opportunity to formally communicate the value system that the strategy needs for getting organizational alignment.
Posted by Malcolm Ryder at 8:38 AM | Comments (0)
September 3, 2005
Optimization - the Effectiveness of Efficiency
optimize
v 1: make optimal; get the most out of; use best; "optimize your resources" [syn: optimise] 2: modify to achieve maximum efficiency in storage capacity or time or cost; "optimize a computer program" [syn: optimise] 3: act as an optimist and take a sunny view of the world [syn: optimise] -- Source: WordNet ® 2.0, © 2003 Princeton University
"Doing More With Less" actually has some competition these days (!), in the call for Optimization.
I toyed with the idea of demonstrating this by citing the number of search engine hits for "optimization", but of course the results of the search would be highly dependent on how many sites have been optimized for search engines -- probably the reason (or at least, a great reason) why the idea of doing optimization has become so widely propagated.
Leaving out the number of site hits, it still seems that almost anything can be "optimized", if you can believe everything you read. The problem is that the point of it usually appears to be to maximize something - so what's the big deal about using the word "optimize" ?
I.
Getting the most out of something really is the main idea of optimization. But while we naturally crave the "most" part of the offer, the lion's share of the practical attention to optimization goes to the "getting" part.
To the point and in summary, in optimization the usual assumption is that something we own or use has a less-than-maximum effectiveness because of some underlying inefficiency.
It helps to know that the final point of optimization is always really about "effectiveness" -- it means that the starting point of optimization efforts is always a determination of what effect the owned or used item is supposed to have. After all, as they say, if you don't know where you're going, then it doesn't matter how you get there...
Then, looking into the dependencies and causes for generating that effect, we'll see opportunities to solve problems, make enhancements, or innovate -- in order to increase the item's effectiveness that we need.
But that is why a problem arises with the popular conception that optimization is synonymous with "efficiency". There might not be a problem if the efficiency issue was always driven by an explicit objective defined by effectiveness. But, unfortunately, by analogy, while a square is always a rectangle a rectangle is not always a square. That is, optimization can be an outcome of efficiency, but "efficiency" does not always produce optimization. The problem arises in the ideas about efficiency and especially in myopia about optimization needing efficiency.
For example, getting further into that point, how would we understand activities like corrections, enhancements and innovations to be "efficiency" techniques?
The answer of course must be that "it depends on what is being changed." This realization breaks the myopia and helps solve the problem.
II.
If being effective means "having an intended or expected effect" while being efficient means "being effective without wasting time or effort or expense" then we know we're looking at whether the underlying mechanism of the intended effect is functioning in a way that includes unnecessary waste.
The challenge is to define the waste, confirm that it is unnecessary to the intended effect, and validate that the technique for its removal is not just going to replace one kind of problem with another kind that is equally undesirable.
But let's get a gut-level grip on this matter of what to change. Suppose that you are on a solo hiking trip, not anyplace too obscure or remote, but you get a bit lost or significantly delayed. You pull out your cell phone, but the transmission connection in the area is very marginal and very unreliable. On the one hand, during this attempted use of the phone, all parts of the communication system might be working exactly as intended, perfectly. We generally know that the parts are not malfunctioning. There may be no "efficiencies" to add to the components. But on the other hand, the combination of these components -- that is, the underlying mechanism for connection -- is not up to the task of producing the intended effect. In what sense(s) is the combination "inefficient"? What is being wasted?
This points up some fundamental considerations of "optimization"...
For one thing, when effectiveness is lacking, a major possibility is that the design of the underlying mechanism might be inappropriate, not inefficient. We wouldn't normally use a shopping cart to move a baby grand piano. Bulking up the shopping cart would be solving the wrong problem.
However, inappropriateness can be expressed as "an inefficient relationship" because, due to the intended effect, the tasks that are imposed on the underlying mechanism have performance requirements attached to them that the mechanism only inconsistently meets. These inconsistent support results mean that the opportunity is being wasted compared to what would be obtained from consistent support.
For another thing, it often goes overlooked that the situations we care about optimizing are ones that extend over time -- typically because some kind of action is recurring in order to produce what we want. Over a stretch of time, the recurring action may encounter significant differences in the surrounding circumstances from one point to another. The challenge is for the action to succeed at each point despite the differences in conditions. In fact, it's reasonable to expect that if the action itself doesn't change then its level of success may vary significantly from one point to the next.
If the conditions that are expected during the time period include significant variation, then getting the most out of the action must first be measured not on a point by point basis but on an overall basis for the period. A major characteristic of an optimized mechanism is that because it can make intelligent trade-offs it can persist over time within tolerances: it won't exhaust itself at every single moment if the price of doing that is inability to handle the long run. Resilience and agility is actually a hallmark of a mechanism geared for effectiveness.
III.
The focus on opportunity waste as opposed to production waste is what basically distinguishes optimization projects from mere efficiency projects. Eliminating waste must first be understood at the level of the opportunity, because that understanding will indicate what aspect (if any) of production should be changed and (with the benefit of relevant knowledge) how it should be changed.
At the underlying production level of waste, we deal essentially with the problem of the production mechanism's suitability to task -- both at the overall mechanism level and at the component level. Changes to the mechanism can be technical, logical, or whatever -- but the reason we deal with it is because of the appropriateness of the mechanism to the intended effect. If we live on a cowboy ranch and we have only a minivan, regardless of the condition of the minivan we're not so much concerned with changing the van as we are with getting a jeep.
But once we have a jeep, the issue becomes, "is the jeep good enough?"
While optimization is inextricably tied to issues of efficiency, the "elephant in the room" in discussions of optimization is "quality"...
Raising the effectiveness of a resource, within the tolerances of its assigned circumstances and intent, is actually about Quality. If efficiency is a path to higher quality, then efficiency should be leveraged but with a priority that also recognizes other paths.
But when we hit the limits of efficiency, if we also hit related but unintended consequences -- such as brittle processes, siloed operations, funding shortages, and rigidity against future change -- the net is not more effectiveness. We'll have wound up with something that is very very good at doing something we don't need or causing something that we don't want.
IV.
Optimization efforts should never be considered strictly in the context of efficiency -- because the necessary outcome of changes is always fitness-to-purpose, or quality, and only sometimes fit-to-capacity. We only ever put five players on the basketball court at one time -- but the key to winning (being effective) with those five is not the player-by-player tuneup but instead the organization of all five players in the tasks of the game.
The essence of optimization calls for a broader perspective that most highly prioritizes relevance to objectives -- followed by a range of options for changing the design of the support including corrections, enhancements and innovations. Efficiency, then, should be understood in terms of how to best execute the changes that improve the design.
Posted by Malcolm Ryder at 6:05 AM | Comments (0) | TrackBack
September 2, 2005
Demystifying ITIL
Making ITIL useful and sustainable in practice means stepping back far enough to see what it is on the whole, and then making the right decision about how to approach it closer so that the effort is not wasted on solving the wrong problem.
ITIL is a highly detailed, highly annotated model of an organization that produces and provides information technology "services" as products.
The details largely cover issues regarding the design of management processes involved in providing services of accountable quality. The annotations largely cover issues regarding:
- the value of the services to the business user.
- the value of the services producer/providerto the business client.
Existing organizations can study and interpret the model in three main ways:
- test examples of how to institute operations
- identify success factors in functional accountability within operations
- identify potential omissions and enhancements, at the functional (i.e., capability) level, in the existing service production/provision system
Because an organization's institutions, accountability methods, and systems are all at stake vis-a-vis ITIL, the organizational model presented by ITIL is always potentially very risky to emulate.
In order to emulate the model, organizational changes are implemented according to the influences of one or more of the three ways that the model is studied and interpreted.
Investments in the changes will likely need to be strategically justified in terms of operational mission, and/or tactically justified in terms of opportunity costs.
The interpretation effort, an early link in the whole chain of ITIL-engagement events, is a typically weak link. Interpretation must be motivated, and the motivation must be shared by the operations managers and the change managers -- or at the least, synchronized .
Together, operations managers and change managers are the defacto organization. (This is keeping in mind that management is more about roles than about job titles.)
Existing organizations that do not want to re-organize can use ITIL as a comparative model.
Existing organizations that are willing to re-organize can use ITIL as a conceptual demonstration of organizational principles, helpful for guidance.
Despite such a practical and simple difference in the purposefulness, approaches to ITIL are often very confused because of the way that ITIL is usually promoted outside of managed communities of practice.
Even from comprehensive introductory coverage like that of the September 1, 2005 issue of CIO Magazine, gaining an authoritative point of view on ITIL is a real challenge due to the range of descriptions applied to each important facet of concern. In this article alone, it appeared that from one authority to another, ITIL aspects could be this, could be that, or could be somewhere in-between:
- A knowledge collection or a framework...
- Organizations or departments...
- Practices or methodologies...
- Management standards or customizable...
- Management functions or processes...
- and management of processes or governance.
The problem is not that these oppositions are mutually exclusive; in fact, they are usually interrelated. But all the terms are somewhat loaded; and the variations make it difficult to coordinate key players around the same high-priority starting point and value proposition -- which is what necessitates an approach that continually markets cross-functional capability maturity.
Does this make a capability maturity model the common denominator of ITIL adoption across all companies? No: the common denominator is strategic urgency, underwriting organizational change management at the executive level. A more complex issue is how to maintain the urgency, and a capability maturity model is instrumental to doing that.
Posted by Malcolm Ryder at 1:15 PM | Comments (0) | TrackBack
September 1, 2005
IT Operations Intelligence - The Business Logic of the CMDB
Without question, business is overwhelmingly predicated on the ability to service needs through leveraging IT resources.
The ever increasing frequency in the variation of business needs means that there must be an increasingly intelligent mechanism for determining the current appropriateness of the available resource for the need, on demand.
I.
Technical advances have made it economical to store and communicate increasingly vast amounts of descriptive data about resources. It is now feasible to at least federate myriad descriptions into a single logical reference database.
But a key issue is how to actually increase the effective intelligence of the usage mechanism, which means increasing its ability to determine the relevance of the data in qualifying the resource for active assignment. Meanwhile, an accompanying problem is of course to ensure and confirm the availability of appropriate resources.
The sensible thing to do about those issues is to use the information to develop profiles of resources that allow quick identification and anticipation of productive associations with existing and predicted business needs.
But with the pace of change and the proliferation of business process variations, that would be a logically improbable achievement unless there was some framework of business demand that could help to define and anticipate the most likely requirements that resources need to meet -- thereby bringing order to the task of vetting the ocean of descriptive data by relevancy.
II.
For example, a business process makes functional requests that require the support of appropriate resources; this offers a step towards making a framework (or frame of reference). The functional requests establish what is appropriate by specifying resource characteristics that are known or predicted success factors. In reality, that specification may just as likely be discovered through trial and error (i.e., testing) as it is proactively designed. Still, in either case, any given resource can (at least hypothetically) be certified for its compatibility to the functions of a business process.
Then, by cross referencing multiple business processes, it will eventually become evident that a given type of resource applies to the range of constructive assignments. Patterns of both common and exceptional functional dependencies on the given resource-type emerge in more or less architectural perspective. Particular instances of a type of resource can then be audited and rated within their type or class.
Conversely, preventing and remedying destructive (or counterproductive) resource assignments means determining in timely fashion that an existing or probable mismatch of resource characteristics is imminent versus the expected demand.
Related to that, another challenge is that a resource, as a discrete unit, may not have all of the characteristics necessary to meet the requirements. In this case, its relationship with other complementary resources may allow it to offer a virtually complete profile for the specifications of the business need. Here, an accompanying problem can be that existing inter-resource relationships may actually reduce the effective availability of a discrete resource for duty, by too strongly capturing the resource within a virtual profile that is inappropriate for the current demand.
III.
Creating the composite of a resource's functional assignments and inter-resource relationships, the characteristics making up the functional profile of the resource are its configuration.
In this light, a defined configuration's lifecycle, from inception to retirement, is consequential only to the degree that at any time it's current phase is associated with business demand.
That association -- seen in terms of whether the resource is both appropriate and available -- translates into quality and capacity management issues mainly significant for addressing the performance of the business processes being served.
But the configuration itself -- seen in terms of the patterns of its utilization -- translates into access and impact management issues addressing the measurable value of creating, deploying, modifying or retiring the configuration in the face of feasible alternatives.
IV.
We can support management decisioning through storing descriptions in a configuration management database (CMDB) and analytically processing them.
As the nexus of business process management and asset value management, configuration management uses and controls the view of resources that evolves in those two dimensions -- emerging as an explanation of how to translate the IT architecture from an investment to a benefit.
Just as strategic product management connects market requirements to engineering, configuration management strategically connects business process requirements to asset management. The connection can be expressed as responsibilities that formalize the major intersections or "coordinates" of the two dimensions.
As seen in the following framework of such responsibilities, the dimensions are:
- the utilization performance spectrum (as in market or business process) ranging from enabling to strategic -- i.e. from a willingness to exploit the resource, to a need to optimize it;
- the production value spectrum (as in product or asset) ranging from planned to actual -- i.e., from initial discovery of an appropriate asset to proactive release of the asset (into production).
(click here for enlargement.)
While the framework does not intend to presribe any overall method for managing resource information, it does provide a context that presents resource description data as business intelligence. As an example of the implications of the framework, the illustration further observes that the intelligence can be approached from the general operational perspective of aligning resource versions with business practices that operations logically direct through usage accounts and usage models -- providing effective management of services.
Note: in this framework, the idea of "discovery" is important to the purpose of communicating that whether assets are built, borrowed or bought, the key business production issue is for the business process to find an appropriate available asset for use as a resource.
Posted by Malcolm Ryder at 8:58 PM | Comments (0) | TrackBack
Coping with Katrina
Hurricane Katrina has erased my wife's native home and the current homes of most of her family, my many in-laws. We have spent three days finding family members by phone and internet, awed by the miracle of having the capability to personally attack that urgency, and profoundly sensitive to the fortune of finding all our loved ones alive, but without their homeland.
Even as relatives arrive by plane to stay with us and we struggle to begin the process of building their next chapter of life, the television relentlessly shows more lives still ending 24x7.
As the castrophe so far is just the tip of the iceberg, the trigger for multiple disasters, we are about to go through months of debate about both what should have been done and what should now be done.
This debate must not be misguided. As usually conducted, the outcome is predictable: unresolved. Worse, sometimes rightly and sometimes wrongly, frustrated heroes will blame victims and failed heroes will be blamed by self-appointed stakeholders, while the owners of different successes will argue over whose success is more meaningful. What a waste. We need better than that.
The hurricane has passed and most of us who have paid attention were relatively untouched. But few of us have lived through the cycle of loss and skepticism, frustration and cynicism, and finally despair and anger that is now the heart of this catastrophe and the most important of its several concurrent disasters.
Notably, as a society on the world stage, we are acknowledged geniuses at "gain", but often seen to be idiots at "loss". Nonetheless manifesting our genius, our culture of strength will for several months and longer appear regularly in the media, shown tested by our belief in compassion.
The news will indeed cover all successes of "The Recovery"... We'll be directed to our national pride, and driven by it. We'll hear a lot about Relief inspirations -- energy drawn from 9/11's spirit of self-respect and the Tsunami's spirit of selfless community. But inspiration is not enough.
What is the connection we now need to pull up above the essential ignorance? It is not will power. Finding lost people is not "heroic"; it is a moral imperative. Rebuilding quality of lives is not "prevailing"; it is the distinguishing feature of a society. And compassion will not be enough. In fact, because it will be exercized on a personally discretionary basis, prioritized pragmatically and emotionally, it will be readily and inevitably politicized. We'll also have a tendency to try to do things that we thought worked before, and we'll need to "take what we can get". But meanwhile, what this is really all about now is understanding abandonment because without that, we'll have outlasted the catastrophe but not ended the disaster.
The ability to understand not *what* gets left behind but *who* gets left behind, not *what* people recover but *who* gets to be a have-not -- and why: this understanding is a kind of certainty that too many victims of Katrina already believe they intuitively have. For them, the ongoing disaster is not about how rescues fail, it's about why rescues for them fail. Until proven otherwise, the catastrophe proves something that they already knew.
The rope non-victims climb up to acknowledging this is the same length as the rope needed to reach down to the abandoned. As each of us takes steps to deal with Katrina in some way, whether through personal or group effort, private or corporate, friends or legislators, note that the importance you attach to your steps is measurable by whether it helps the rope to get shorter.
Posted by Malcolm Ryder at 11:58 AM | Comments (0) | TrackBack
The Cost of Value
Walk into a meeting, say the word "value", and tally up the other words that people thought you meant.
If your results look like this:
- profit
- performance
- ROI
- economy (as in economical)
- impact
then you already know why the next thing you say about value might easily split the audience into different groups. This split readily occurs based on how much their concerns are:
- goal-oriented
- process oriented
- resource oriented
The interesting thing to note here, though, is that each group at the meeting actually blends together some level of sensitivity to each of those three concerns, and it's the blend that makes the difference in how they understand you when you say "value".
I.
As articulated by the picture below, the blending shows up in the form of three main questions or "attitudes" that people bring to discussions of value. Essentially, what happens is that new ideas that claim to have value are considered in light of what related changes to current affairs are thought to be requested. The three questions are mental placeholders for the assessment of the current affairs:
1. What should we be doing? This looks at the list of current obligations and questions things in terms of priorities.
2. How are we doing? This looks at the way things get done and questions whether those ways -- capabilities -- are effective enough (successful and appropriate).
3. What could we be doing? This looks at whether the assumptions that have driven current choices for engineering benefits are still more logical and exclusively relevant than other credible assumptions that would also represent opportunity.
From the picture, we can also understand how discussions can quickly focus on certain "levers" such as:
- how costly is a resource?
- how risky is a process?
- how beneficial is a goal?
These levers typically show up as hot-buttons -- "justifications", "success factors", and/or "criteria" -- in the consideration of a proposal. Our picture also shows that each lever (such as "cost") easily gets a shared audience (in the case of cost, both the "commitments" and the "progress" crowd). It is not always the case, though, that the audience identifies its shared concerns as readily as its differences.
II.
Addressing multiple stakeholders with a single proposition means investigating shared concerns as much as possible; having a logical approach to doing that should make the problem easier to solve.
But if we go back to the list of those synonyms provoked by saying the word "value", things initially seem to be all over the map.
To sort this out, we can use simple working definitions of each synonym, and use the definitions to map the synonyms to our picture.
- performance: a measured level of achievement towards a target outcome
- impact: the measured difference between the quality of the current state and the quality of the proposed future state
- profit: a net gain in assets beyond the total allocated cost of effort.
- ROI: the difference in resulting assets between the proposed consumption of a resource and the current consumption of that resource.
- economy (as in economical): the efficiency of converting a given level of assets into a given level of resources.
As we now see, some of the terms -- profit, ROI and economy -- are actually types of the other terms -- performance and impact.
Furthermore, performance and impact both refer to the change that has occurred between the current circumstances and the projected or forecast circumstances. They are generally similar. But we can see that performance is really a context-specific description of impact.
In the typical Archestra terminology, "value" is identified as "the importance of the difference". The point is to determine whether the proposed value will test "positive" for being not just "different" but "better" than what is already in hand. The different audience perspectives explore the idea of "important" or "better" in respectively different ways:
What type of "resource" is consumed or created?
- does it increase conformity to obligations?
- does it decrease obligations that are liabilities?
What is the significance of having the new kind of resource versus the old, OR of having the new mode of resource consumption versus the old?
- is it more manageable for the current efforts needing resources?
- does it enable a new or alternative effort
How does that significance logically support the desired future state?
- does it make the path to the future state easier or safer?
- does it provide a path where previously there was not one or where in the future there will need to be an alternative?
III.
Now it is more apparent that the range of issues under the topic of "value" covers a lot of ground that is not crossed by counting money.
But because so much of business is predicated on having the assets necessary to fuel future effort, the overall sense of value typically "rolls up" to an estimation of the change of assets. In fact, it is usually the case that the shareholders of a business will tolerate a wide range of goals and even frequent change of goals as long as the change of assets is "profitable". Perhaps unscientifically, both economy and ROI are assumed to always be underpinnings of profit unless proved otherwise. This finance perspective is in high contrast to the main issue for stakeholders, which is that the way the business does things should be consistent with protecting the operational effectiveness towards the goal.*
Consequently, it seems that shareholders are much more tolerant of change than are stakeholders.
The generalized implication is that when "value" is proposed in terms of effectiveness, stakeholders perk up to catch clues about capability; when "value" is proposed in terms of "advantage", shareholders perk up to catch clues about opportunity.
Although distinct, the points-of-view are not mutually exclusive. In fact, as our earlier picture shows, the factor in common across those two groups is "risk". Although everyone knows that it takes money to get anything done, when the subject is "value" the sense of a related cost is not so much about dollars as it is about the tolerance of uncertainty.
In short, the "cost" of value is risk.
* See an outstanding discussion on stakeholder versus shareholder orientation, in an article about "social enterprises" called
How Organizations Create Social Value, by Manda Salls.
Posted by Malcolm Ryder at 6:27 AM | Comments (0) | TrackBack