« December 2005 | Main | February 2006 »
January 31, 2006
Strategy doesn't win; Value-delivery wins
Scenario planning, which is really deep thinking about the future, is vital to good strategy.
Now, we don't want to blame the victim, but if you're Ford Motor Company or GM, getting crushed by Toyota in their home field has to be categorized as "foreseeable" (sp?), and Ford (as well as GM) simply fantasized dodging the hammer. Toyota is extremely effective, and Ford and GM are extremely ineffective.
Given how much money Ford and GM spend marketing their "strategy" on TV, this makes their management look pretty dumb. They've spent 20 years obsessing about "competitiveness", and are close to losing the home market (if not the whole company) because they didn't get the value right. They chronically solve the wrong problem.
Failed strategies at Ford or GM are now case study stuff for aficionados of the History of the Future. We don't doubt that the two companies were furiously busy going after things the way they figured made sense -- but now we have to wonder why they thought things made sense the way they pursued them.
Granted, the management "formula" that predicts effectiveness is, as always, somewhat illusory if not fantastical. As scholars and analysts always tell us, it's not worth much if people don't want to use it. If the people who came up with the formula are the ones who don't want to use it, that pretty much explains why the formula, despite its logic, finally doesn't make sense. The people not at the top who are trying to use it won't get much out of it.
Despite lipservice to the consultant's mantra, companies are rarely flexible, adaptive, responsive, and innovative at the same time. These four things don't matter if they are not integrated with each other -- and profit schemes and politics typically short-circuit the extended discipline required to integrate them.
For that integration, very few organizations have the necessary risk tolerance built into their profit schemes and politics. As a result, they don't really develop their business architecture and business infrastructure properly. Thus, Culture trumps Planning. (Presumably, both governance and "best practices" are going to help solve this conflict -- but not if executives are still told that they don't have to make "long-term value" Priority #1.)
The company's management formula for "effectiveness" has to string these three tricks together:
1. At a really high level, a company should understand whether it's current top need is to be in recovery mode, health maintenance mode, or growth mode. (Confusion about how to determine the top need is the ill-effect of the shortcuts I mentioned above. Any doubt? Consider the life-span and life-cycle of a CEO's tenure.) This shouldn't be fantasized; it should be based on what the environment is like.
2. Then, it needs to align to the mode. It needs to figure out things such as whether the necessary responsiveness for that mode requires innovation, and whether the necessary flexibility requires adaptation.
3. Finally, it has to figure out where to get the capability to do what is necessary to meet the requirement.
Absolutely nothing will affect that alignment as much as the decision about who the company is primarily working for. That decision provides the world-view that the company needs, and the company must then work on its "fitness" in that world, so it can compete there.
For example: if the company is working primarily to funnel money to investors, then it behaves one way.
If instead it works primarily to funnel capabilities to customers, then it behaves another way.
It might actually work primarily to funnel benefits to its community, which makes it behave yet another way.
Punchline: If it doesn't know what it is primarily trying to do, then
- it doesn't have a logical framework within which to do deep thinking about the future, and...
- it probably spends a huge amount of time trying to solve the wrong problem.
Posted by Malcolm Ryder at 5:14 PM | Comments (0) | TrackBack
The History of the Future
Picture from 1954 Popular Mechanics Magazine
This picture is before you knew what a computer was or probably before some of you were born!
Be sure to read the caption below the picture.

Posted by Malcolm Ryder at 7:12 AM | Comments (0) | TrackBack
January 29, 2006
Business Intelligence versus Business Knowledge: Who Cares?
How often is it said that "information is the lifeblood of the business!"...?
No one dwells on whether it is a true statement or not. Everyone dwells on how to process information so that the business is neither toxic nor anemic.
It's a telling fact that the initial assumption is always the same: information must be processed. It simply means that either the info isn't "good enough" when it first arrives, or that there is no point in having it unless it is going to immediately be transformed somehow into something else (namely, a decision or a directive).
Ironically, it is processing itself that makes using information so complicated. The evidence? Pick, from the following, only the one item that most clearly represents the primary reason why your company can keep its operations attuned to the business goals:
- Performance Management
- Business Intelligence
- Knowledge Management
- Content Management
- On Line Analytic Processing
- Database Management
Now, explain your choice by explaining how you ruled out the others.
That should be enough to make a couple of aspirin and the following picture worthwhile.

The key points of the picture, both explicit and implicit, are variously familiar or unsuspected.
One aspect reminds us about Garbage In/Garbage Out:
- Data and Knowledge are both "inputs" that can be taken prima facie and virtually from anywhere.
- Intelligence and Insight are business goals of information processing
Here's another interesting aspect to chew on. From the point of view of a business process:
- Supplied information (left side: data, intelligence) is not the same as Applied information (right side: knowledge, insight)
- Intelligence is not directly "parallel" to Knowledge and cannot substitute for it. Being intelligent is not the same as being knowledgeable.
- Likewise, although "information may be power", having Data in no way assures an advantageous (Insightful) use of it.
And additional annotation offers this:
- The most obvious connection between data and intelligence is Cognition
- The most obvious connection between intelligence and knowledge is Learning
- The most obvious connection between knowledge and insight is Experience

In those relationships, we can see another situation in which, as with so many aspects of goal-seeking, the difference between a cause and a prerequisite can be quite profound. On the one hand, getting one of these areas up to snuff won't make the other areas happen. On the other hand, working on one of these things without regard to the others is probably not very "smart".
To ultimately gain maximum advantage through information, we'll need our firm to become an intelligent enterprise that is also a learning organization constantly testing and improving its perspective.
Posted by Malcolm Ryder at 2:43 PM | Comments (0)
January 27, 2006
So What's Your Problem?
"I never walk into a room I don't know how to walk back out of." -- Robert DeNiro, RONIN
When is a "solution" not a solution? When it doesn't end the problem.
But why bother with a solution if "the right" problem hasn't been decided?
We say "decided", here, because problems are so often an onion that must be peeled, and somewhere amongst the layers we have to choose the place where we'll start "solving"... and choose a satisfactory place to stop.
I.
For example, when we get specific about our work on a "solution", do we know whether we're addressing the symptom, the problem or the cause? What is necessary, and what is sufficient?
Symptoms (sometimes called incidents) are signs that a problem exists, while a problem itself is an undesired disruption of, or diversion from, the state that we are relying on. The cause of the problem, sometimes called the "heart" or "root", is a detrimental change of the conditions that normally generate that state on which we rely. Often we don't get to stop there, since we might need to know why the base conditions changed.
The water on the basement floor is from the freezer: the ice block melted because the freezer went off because the power went out because the tree-pruners hit the power line while we were away...
Diagnostically, the habit is to focus heavily on these layers. We try to see the connecting thread from one layer to the other, and try to decide how much we ought to do to correct things. Is the requirement to hide symptoms, to restore or replace our reliance, or to reengineer the base conditions?
Sorting out those issues is the usual routine. Meanwhile, we frequently risk a huge amount of time solving the wrong problem.
II.
This is partly because a given symptom can sprout from many different problems, and to isolate the problem that really exists, we have to search for a variety of other symptoms that combine into the problem's "fingerprint". Those other symptoms may not yet appear, though -- so we also rely a lot on histories that say "if this particular symptom appears in certain situations, it is likely to be that particular problem."
Most of that is old hat for problem-solvers. But then there is the matter of having more than one way to solve the problem. Deconstructing the problem to fix it can lead to a revised idea of how serious the problem is or even of what is the real problem. This is because some problems are caused by other problems.
When problems are "chaining", it's naturally somewhat urgent to determine which problem will be the point where the first effort gives the most overall relief. But relief is not necessarily the solution.
More importantly, within any targeted problem, the challenge is to understand it correctly, so that remedial action will not change anything else that does not need to be changed. The law of unintended consequences can be harshly unforgiving.
Of crucial importance is to not have the solution to one problem be the cause of another problem.

As iluminated in the above table, isolating the correct solution-approach means we have to understand what intrinsic type of problem exists. Symptoms comes from this type, and the type comes from any of the ways that the basic conditions were disturbed before or after their creation. These disturbances come in three main flavors: complexity, difficulty and risk.
As revealed here, solving the problem thus becomes potentially very complicated. Our diagnoses can reveal a number of different and simultaneous causative issues creating conditions that spawn more than one type of problem. What's worse, we encounter phenomena such as one type of problem causing another type of problem. For example, errors can cause omissions, which in turn can cause defects.
III.
As we design the solution -- whether it is a simple one or a compound one -- we then face a parallel set of challenges in the solution effort: our effort itself has to overcome complexity, difficulty and risk.
Specifically, in designing, we have to deal with issues about our concept and execution including:
- choice of what to address (complexity);
- suitability to task (difficulty); and...
- opportunity costs (risk).
The short answer to those challenges is, of course, to get an expert. Getting an expert makes sense if:
- the assessment of the problem is either still-to-be-done or is accurately complete but highly specialized
- the assessment needs to be translated into differing vocabularies e.g. cross-functional or cross-departmental
- negotiating over competing solution priorities must be done
- suspected technical requirements exceed already in-hand resources.
The purpose of the expertise is to decide what solution approach will be used for a defined problem to get an explicit expectation met regarding an identified point in the future. This means realizing that final requirements may only partially satisfy needs; and that we might have to play the "choose your pain" game. But what makes any effort worthwhile is to spend it on solving the right problem.
So what are the chances, finally, that we'll get to the solution that we want?
In a mid-size organization, roles and responsibilities are likely already diversified enough so that nothing can be taken for granted about co-operation. Solutions that are delivered are not just the ones that seemed to be called for, but instead are the ones that are allowed. Closing the gap between the ideal solution and the allowed one may take strategy, but it invariably takes visibility of what's at stake for each key influencer of the solution development and solution adoption.
Thus an assessment of the delivery prospects for the solution is a critically important dimension of its design. The table below provides a procedural framework for delivery assessment (called "CLEAR", copyrighted, trademark pending) that presents the key touchpoints for information, permission and support of the proposed and evolving solution design.

In CLEAR, matching resolve with approval is the goal. The activity involves acknowledging, publishing and reconciling the fact that a variety of independent elements must cooperatively and compatibly generate the solution if it is to be successfully provided and used.
Posted by Malcolm Ryder at 6:47 AM | Comments (0) | TrackBack
January 25, 2006
Selling the Change
You can lead a horse to water, but you can't make him drink.
The consulting industry that has built up around this challenge offers years of multidisciplinary research in its solution recommendations.
But in the center of the vast collective scope of the recommendation, a repeatedly confirmed synopsis appears, looking more or less like this:
- People have an innate sense of risk and reward, and they are willing to change their personal balance of them for a good reason.
- Giving people a reason to change requires more than just promising them additional tangible compensation. People want opportunity. The best opportunity you can give someone is support for them to be who they want to be.
- Part of that comes from clarity about what will be expected of them in a successful change. People need to see requirements that they feel are relevant and achievable. They need to see the difference between what they have already been responsible for and what they will next be responsible for.
- But the strategy for fostering change is to excite people about becoming a certain way or contributing themselves to something they believe in.
The excitement comes from communication. But the communication effort is not just information delivery.
Change envisions a future state and ascribes some "reality" to it by presuming that, on certain already manageable terms, individuals will make it happen. Communications to promote change must therefore answer some basic questions in a way that fosters the alignment of personal and organizational agendas.
That alignment revolves around two major concerns:
- What accountability is associated with the particular change?
- Do we believe the change is intrinsically do-able and worthwhile?
Those considerations are not in rank order here. Because they are each so basic, both concerns pertain to any given change. (But it's true that organizations more often change the way they tackle an unchanged objective, and less often change the objective itself. For that reason are the two concerns mentioned in this order here.)
As illustrated in the following picture, the connection of business vision to personal opportunity results from a "discussion" of the two concerns, in each of which the connection is logically fortified by the way key questions are answered. Negotiation to the answers may be more the rule than the exception.

Click here for enlarged image.
The above provides an overview of the key factors. Covering all of them is important, But getting right to the heart of the matter: for people to power the change, communications (as outlined above) must establish trust, visibility, roles and boundaries -- so that people feel empowered to take ownership of their decision to commit.
Violating those terms is a sure-fire way to undermine the motivation to change. As seen below, normal instruments of daily management need to be adequately focused on satisfying those terms.

In some ways these views are incomplete and have big spaces in them -- but if this much of the scenario isn't true as shown, then there's no reason to expect to be able to get people to change...
Posted by Malcolm Ryder at 6:45 AM | Comments (0) | TrackBack
January 24, 2006
The Creative Differences of Licensing
Ed Foster's Gripelog struck a loud sour note regarding the surprising and sometimes crippling difficulty of handling software licenses when the machines that run the software change. The gist of it is that licensees discover little to no "ownership" privileges, suddenly. Fair to say that the level of outrage against aggravating vendor pratices is a good working exhibit of "contempt".
But the issue is controversial because there is more than one way to look at it.
"License" means "permission". Unclear licenses are bad; deception is unethical; but that said, as for the presumed right to use software, the whole issue is about the fact that the owner of the software *grants* all the rights.
None of the following is about blaming the victim. BUT... the law says that the owner can charge more for granting more rights, and the law does not prohibit us from negotiating.
So at some point we have to come to grips with the fact that when we use a business to satisfy our needs, the satisfaction will take place on business terms. We have to avoid getting confused about what is unsafe as opposed to what is highly inconvenient. The level of support that we want is our responsibility to declare before we buy.
That still doesn't rescue us from predatory businesses, but we don't think skipping down dark alleys is very smart, and the standard is really the same when it comes to licenses.The best time to be aggressive versus a business is before we buy. Prevention costs 10% (or less) of the cost of a cure.
Flexible product configuration is not always convenient; sometimes it's a desirable opportunity but that doesn't prevent it from being an unacceptable risk
Posted by Malcolm Ryder at 9:04 PM | Comments (0) | TrackBack
January 22, 2006
What's So Smart About BI?
BI for most companies means implementing analyses. Analyses can be inward-facing, outward-facing, diagnostic or predictive.
Those four characteristics blend like this:
- Inward and diagnostic: improve production efficiency
- Outward and diagnostic: improve relationships
- Inward and predictive: reorganize processes
- Outward and predictive: reengineer position
The best reason to use BI is to answer "Why?" for each of those four things. It also makes a difference which one gets answered first, which second, and so on, because all businesses do not have the same current constraint or advantage.
If the various answers to "Why?" do not align in the near future, the organization is FAR less likely to get beyond quality control and into actual growth.
Naturally, if sustained competitiveness is critically dependent on growth, then not getting growth from BI means not getting ROI from BI.
Posted by Malcolm Ryder at 7:45 PM | Comments (0)
No Place To Hide
Wiretaps, viruses, and instant global lies. We're definitely in the Age of Insecurity. The hugely shrunken world we live in is not really shrunken at all, but instead the opposite -- it's zoomed in. As we find life increasingly attached and vulnerable to the microscopics of reality, the world and its complexity get incalculably bigger instead of smaller.
Our instinct to see ourselves at the center of reality is thus amazingly if not bafflingly persistent.
For example, when our personal "security" is breached, we say our secrecy is pierced , our privacy is invaded , or our anonymity is lost ... Ironically, customer relationship management (CRM) is perhaps the most aggressive abuser of our notion that being the center of things is secure. How so? Just set your PC volume low and watch this 2 minute demo from Adcritic.com.
I.
On a daily basis, whether online or on foot, when we employ anonymity, privacy or secrecy, we like to speculate that the environment around our effort will cooperate with our intention.
Over time, willful naievete about that is merely childish and yet potentially dangerous.
On the other hand, careful research beforehand can give us a shot at reducing the speculation to a well-founded assumption by guiding us to better preparation for contingencies.
Yet unless told otherwise by someone we're willing to believe, we stubbornly go into situations with the idea that we have a "right" to maximum invisibility and can just ramp it up or down as we happen to like.
We hate to have our motives questioned "unnecessarily" -- we feel that we shouldn't have to justify or "earn" the desired degree of invisibility by revealing what we might do with it before we actually have it.
Of course the big catch to that is in whether we agree that our own degree of privilege should be no more than anyone else's in the same circumstances.
And for the most part, we don't. No one expects that to happen anywhere except in a frontier. We want different people, with their different agendas, to have different privileges.
Stuck with where we are, we should at least start the negotiations with being sure that we know what we're really asking for.

Then, we start applying that clarity to the task of making a policy.
II.
In policy, we run up against the issue of entitlement, which means clearing up the confusion about freedoms, liberties, and rights.
We normally like to use them all at our convenience, as justifications for what we want. We use them as if they were our tools in our personal toolbox. But in that attitude, there is some degree of illusion.
We can detect this with a little vocabulary change. That is, in the environment that we target, we instead find our potential actions unrestricted, restricted or approved without regard to what we want. This trio of circumstances stretches, respectively, not only from the least specified situation to the most specified, and from passive allowance to active promotion, but also from the most autonomy to the least:
- Freedom refers to the absence of any restrictions.
- Liberties refers to the tolerances for what we are "allowed" to do.
- Rights refers to the postive confirmation of what we are "permitted" to do.
How do those experiences relate to our anonymity, privacy and secrecy?
What bothers us the most is if a party other than ourselves, at their discretion instead of ours, makes a decision that limits our range. (When we make a policy, we are the "other" party to those that we feel should comply.)
We might therefore instead be wary of:
- a loss of freedom,
- a contraction of liberties, and
- a refusal of rights.
When we don't get what we want, there are two different things being challenged: our authorityand our autonomy.
It's unpleasant to have either of them in debate; but, it is useful to know that sometimes we can have less of one and more of the other without necessarily sacrificing a satisfactory outcome. The issue is to predictably get what we really need, without it being at the unfair expense of others.
To see that this is true, we create policies as a set of understandings that identify the important combinations of autonomy and authority by which we want ourselves and others to abide.

Policies associate privileges and responsibilities, in a way that foretells what kind of influence we will have in a given environment. While not always the case, it is reasonable to usually expect that accepting responsibilities is a way to merit privileges. For that to work, the responsibilities need to be spelled out in a way that clearly describes the particular environment.
Restoring a sense of order and safety is something we want to do by rule rather than by force; but for that to work we have to agree on the rules and they have to be followed.
III.
Using the above generic table, we can envision a specific circumstance or environment such as an apartment building, in which the landlord is an owner , the manager is an agent, and the tenant is a guest. Most notably: these roles are designated with responsibility to the environment, not to each other. But the roles can inherit benefits from the environment because everyone is doing their part correctly.
The result of creating a policy is that we formalize security.
Our issues with personal security -- in terms of having protected anonymity, privacy or secrecy -- are actually particular to the stakeholder role that we assume in the environment. Other parties in the environment want to know if our mode of actions -- anonymous, private or secret -- is still supporting the responsibility that they assume we have taken on with our role. In the end, we don't have a blanket protection of anonymity, privacy or secrecy; instead, we need a contract with other parties that appropriate protection will be provided if we declare our roles and follow the rules. Although this contract needs to be negotiated, once there the biggest concern is about whether either party, us or them, will violate the terms of the contract. Suspected violators lose protection.
In sum, this points out four risks to security.
(1) Lack of explicit policy (either by design, or effectively through neglect)
(2) Uncertainty about what roles have been accepted
(3) Intentional disregard for responsibility
but also
(4) Abuse of authority.
Plenty to think about, but not much new, even in the outrageously expanded world.
Posted by Malcolm Ryder at 7:12 AM | Comments (0) | TrackBack
January 21, 2006
Top Ten Things Everyone Should Know About ITIL
1. The celebrity and challenge of CMM (capability maturity models) redirects focus away from the true value of ITIL -- ITIL is about maturing the business competency of IT organizations.
2. The competency means organizing capability so that it has business value.
3. Management processes, collectively, are the link between IT capability and Business demand.
4. The management processes must be integrated in order to continuously coordinate the involved assets, events, requirements and demand.
5. The tangible deliverable of the integrated management processes is an IT infrastructure for Business.
6. The intangible deliverable of the integrated management processes is IT service assurance for Business.
7. All deliverables can be evaluated; specified deliverables can be measured.
8. Measurement is only one kind of information necessary for process integration to successfully support the business. Belief, preference and priority describe the business in a way that critically constrains success.
9. There is no such thing as ITIL "Compliance". Instead, there is compliance to requirements that are ITIL-compatible, but the requirements are defined by the business, not by ITIL.
10. ITIL is a framework of models for implementing management processes, not a rulebook of technical standards for managing implementations.
Posted by Malcolm Ryder at 4:03 PM | Comments (0)
January 15, 2006
Measuring process improvement
Events become notable and interesting to business primarily because of their outcomes.
While outcomes range across the spectrum of pursued to avoided, desirable to undesirable, or benefitsto damages, they generally all figure into operations by the same path. That is, the impact of the event is studied for whether that impact is (or can be) repeatable; whether the repetition is (or can be) intentional; and finally whether the intention is (or can be) manageable.
In that light, four areas of measurement are associated with all managed events, and the manageability is ultimately what distinguishes an operations event from an operations process.
1. The impact itself is compared against some standard of expectation or some qualifying definition.
2. The likelihood or frequency of the impact’s repetition is tracked against elapsed time and/or a range of different conditions.
3. The intent to repeat is proved against evidence of supporting commitments made.
4. The manageability of the intention is modeled in terms of responsibility and authority.
These four types of measurements – comparisons, trends, proofs and models – provide the terms for establishing both the bases of process development and the deltas of process improvement. Each type of measurement refers to some defining aspect of the operations environment, and that environment is therefore the context of the measurements.
Process improvement is usually thought of in terms of the difference between the earlier outcomes generated and the outcomes gained consequent to a modification of the process. But this is an erroneous attitude. Outcome improvements are of course highly important, but they are different from process improvements.
Instead, process improvements always assume that a target outcome is achievable, and the process improvements are concerned with how to engineer and assure the achievement.
Given the above, the difference between the initial circumstances of a process and the improved circumstances for the same process is the critical difference to be determined in a process improvement initiative. Effectively, the following is pursued by the initiative:
1 - establish definitions and standards
2 - establish continuous event monitoring from multiple perspectives
3 - establish commitments to prerequisites and/or causes underlying the dynamics of events deemed pertinent to goals
4 - establish models of proprietorship for the commitments
These factors make it more obvious that process improvement is essentially a matter of managing corresponding organizational changes. These changes include, for example, the strength, state and pace of an organization’s adoption of:
1 - taxonomies and vocabularies
2 - reporting and analyses
3 - approvals, allocations and priorities
4 - assignments and authorities
Given alignment of those changes, the organization acquires the capability to literally do things differently for the better, and the groundwork exists for shifting focus to production technique that will be evaluated as a quality factor in execution.
Improvements in technique are again a different matter from process improvement but they manifest the ability to reliably conduct the process on demand, and therefore point attention towards improved competency as opposed to improved capability.
Posted by Malcolm Ryder at 11:53 PM | Comments (0) | TrackBack
January 14, 2006
"Effectiveness" -- the essence of Operational Performance
As with so many "enterprise" issues, whether you're an executive or a manager, sorting out the messiness of your performance management options probably means first checking to see if you're sure they are solving the right problem.
Executives and Managers don't see things the same way. But they do look for the same thing: "high performance".
Sadly, too much of the time they don't know when they're seeing the same thing until it's after-the-fact, so it's difficult to coordinate their decisions along the way.
This obscurity of view can be resolved, but today the solutions themselves are often confused about what parts of the problem to solve -- because the stakeholders aren't sure themselves.
At the heart of the uncertainty is a lack of understanding, or agreement, about where one stakeholder's authority of (which establishes a scope of influence) should exploit another stakeholder's responsibility (a degree of accountability). "I have a right to protect my accountability, no matter what you order!"
Research departments of consulting firms discuss this difficult situation, such as in Booz Allen Hamilton's take regarding a need for determining "decision rights" -- but there is also a more basic cultural aspect to consider: what everyone refers to as "being on the same page". This unanimity is not just about naming a common goal, but instead about whether everyone understands, to some reliable level of generality, the logic of how to make things work. In action, the key complication here is the variety of practical and political predispositions found within the organization, despite decision-making rules. Predispositions generate expectations that give "reality" its appearance and thus present what looks like moments needing decisions. Different realities offer different moments...
A pretty good way to start resolving the confusion is therefore with a globally coherent picture of what the decisions ought to be made about.
I.
The underlying logic of what gets called "high performance" aims for advantageous on-demand results, which calls for alignment of three key elements:
- clarity of intent
- realtime responsiveness
- agile navigation of capacity
Linking those three things allows for "executing" (as it is usually called) with the right thing at the right time for the right reason. But what must also happen is to have all three things simultaneously.
Clarity about "reasons" is the most important challenge. Setting aside the specifics of any given business, two major classes of reasons usually steer the management of the execution.
- One class focuses on the worth of the designated objective. (This is about the kind of advantage that the achieved objective offers. )
- The other focuses on the value of the execution. (This is about the importance of the difference made by the execution.)
Often the difference between this pair is referred to as the "gap" between strategy and execution -- implying a causal but dysfunctional relationship that somehow has escaped management's influence. That clearly oversimplifies the matter, except by assuming that management has to be "fixed", which is not a simple matter. Popular cited examples of management's problems include this: so many definitions of strategy are presented that strategy becomes a moving target; meanwhile a culture of short-term gains increases skepticism about whether strategy is pragmatically important anyway.
Yet stepping away from that suspicion begins with a related observation: the direction [verb] provided to execution by management is precisely where the accountability for "performance" lies. Most decisions about execution are made under the pressure of accountability.
When we're worrying about management accountability, we'll call our real subject something other than "performance".
II.
In practice, the highest-level concerns of accountability are two expectations.
- One is that the designated objective should be logically critical to creating the conditions necessary for business functions to matter.
- The other is that execution should be logically critical to creating states at which the objective is achieved.
These "functional-conditions" and "objective-states" are thresholds. The chemistry of what occurs when the thresholds have finally been reached or crossed is described in the business model (of conditions) and the business plan (of objectives).
Given that, the essential significance of execution seen is its role as an enabler (of hitting the thresholds).
However, both executives and managers persistently but incorrectly treat execution as a cause. Correctly seen, execution dwells on necessity but it is production that dwells on the ability that gets the job done.
Nearly all parties acknowledge the reliance on programmed production. Production is a designed activity, the place for which is set as follows:
- execution, meaning the decision to act and the followup, should itself be "caused by" explicit intent to reach thresholds; and...
- the activity-design of the followup focuses exclusively on realizing the intent.
This clarification of the notion of "execution" versus "production" is complemented by similarly distinguishing the idea of operation (the chemistry beyond the threshold). All together, they describe the functional depths of the organization:
Operation refers to an intentional activity that distinguishes the purpose of the organization in a situation. Here, the key concerns are quality issues, about targeted "impacts and reach".
Execution refers to the explicit and controlled pursuit of meeting requirements for successful operations. Here the key quality issues are about "options and decisions".
Production refers to the mechanism used to realize and sustain execution from current circumstances. Here the key quality issues are about "cause and effect".
Executives and Managers must have a common (shared) way to see and understand the alignment of these three layers of organizational functionality. The key is to grasp the systemic nature of production's influence on execution, and likewise execution's on operations. Optimizing this systemic influence is the management goal called effectiveness.

When executives and managers agree about "effectiveness":
- They more rationally exercise the "throttles" that change the levels of throughput and output that they interpret as "performance".
- Their efforts, even independently of each other, are then truly more akin to driving, in which they both use the same logic of inputs for moving the vehicle in the right direction at the right speed at the right time. The specific point of any moment's maneuver may be quite different from another moment's, but the overall navigation weds all the real-time changes to the purpose of crossing the terrain.
- Most of all, the participants' recognition of when it is important to change an input is based on the same (shared) ideas about alignment.
The support of this alignment is two-fold: it must span attention to issues that are peculiar to each element, and to issues that determine the success of their linkage.
III.
In understanding and maintaining effectiveness, correctly addressing its specific elements involves using the right mindsets for staging and conducting their evaluations.
These mindsets -- which show up in their semantics -- prescribe the basic types of awareness needed to communicate whether a given element needs to be changed.
- Measurement uses the most granular set of standards, to specify the difference between fixed requirements and current reality. (Correct vs. Incorrect)
- Rating uses a less granular scale of difference to compare a current position against a range of possible positions. (Better vs. Worse)
- Confirmation uses a definition to test for the actual existence of something versus a plan (Yes vs. No)
But the full description of the mindsets includes sensitivity of another kind: an organizational effort meets its purpose with competency built on capabilities. This awareness overlays the layers of functionality from production up to operation.
The table below illustrates this overlay. For example, in representing the high-level top-down view from the perspective of purposein an organization's effort :
- Operations are best "measured", while...
- Execution is "rated" and ...
- Production is "confirmed"
This describes the immediate "surface" visibility needed for an evaluation in terms of purpose, and it de-emphasizes other background levels of elemental visibility unless the immediate visibility is unclear. This means that to understand efforts against purpose, "measurement" of execution is not automatically necessary, but we want it to be possible if execution's ratings are unclear.

IV.
Further support of alignment includes the design and maintenance of linkage mechanisms for the layers of functionality. Both static (preconfigured) and dynamic (ad hoc) linkage must be arranged.
Executives and Managers often try to do this symbolically, by defining and then "rolling up" or "cascading" measurements across the functional depths of the organizational effort. This typically involves translations from one depth to the other, and it has been historically maddening and insecure. The chosen problem has usually been to determine what the measurements at one depth mean "at another depth".
Sometimes in the hoped-for translation of measures, the semantics involved are "codified" by process designs that link (i.e., integrate) events at one depth to events at another. The hope is that the process design is valid, so that measuring just the integrity of the active process can provide a suitable proxy for a much larger set of discrete observations. This approach of "automating alignment" is not unimportant, but it confuses the "systematic" for the "systemic" -- that is, it risks that executives and managers will mistake the description of the process for a description of the current conditions. The problem with that, as has been historically borne out, is that improving process may not cause conditions to improve, even if it allows the conditions to improve -- and processes continuously proliferate their complexity and variety. (This is why process management is not the same as performance management but instead is only an aspect of it. Process, although likely necessary, cannot be a sufficient translator.)
Instead of all that, as the table above suggests, measurements at one depth establish facts that are likely important to the next depth only as they relate through the virtue of commitments made (i.e., assignments) and through the likelihood of positions established (ratings). Thus, with much more generic linkage involved, as we move up from production to operations we see the subject of "measurement" moving from capabilities to purposes, telling just a part of the story.
For example: let's say that we're driving, and as an execution matter we've decided to "go left".
- We produce this turn by assigning (committing) a selected turning radius and selected velocity. We may find out only later, through measurement, whether those specific selections should have been allowed. The results of our production effort leave us more or less satisfactorily turned to the left; that is, we retrospectively evaluate the production with a rating.
- But how useful is the turn that we produced? Is the precise "leftwardness" of our resulting achieved position suitable for the need at hand? Does it matter which lane we have gone into, and how far we are from other vehicles, at our post-turn speed? Did we hit anything during the turn? Are we about to, afterwards? All of these issues carry potential requirements that we address throughmeasures reflecting our competency with the turn (i.e., our execution).
- Our demonstrated production capability will strongly suggest whether in the future we should consider a decision to turn left to be a "good" decision -- but meanwhile a recurring need to turn left may insist on efforts to improve our production capability for the future.
V.
The bigger message from this situation is that "measurement" per se is an incomplete understanding of conditions, which needs to be supplemented by additional means of understanding. We cannot manage what we don't understand.
When we look at achievements against targets, the matter is about "performance". But sustained or recurring achievement is the whole point of management, and awareness doesn't cause that.
So, more to the point, when we have a supervisory understanding of functionality against goals, we work on managing their alignment as a matter of managing "effectiveness".
The next table below again elaborates the "effectiveness mindsets" -- except in more colloquial or "ordinary" language. This set of semantics illustrates how terms of alignment range in a general progression of influence from "optional" to "critical" as we go from (bottom left) production capability to (top right) operational purpose. For each intersection of functional depth or change level in the table, the provided term points at the notion of "in what sense does this matter?"... For example, an assessment of Capability is important, but it is important in different ways depending on what functional depth is being considered. In this version of the table, each term represents a distinctive expectation that executives and managers can always initially share as the default question of interest or comparison about each issue.
Overall, a baseline is established for discussing the "role" of each functional depth (row) or change level (column) in terms of effectiveness. It's not difficult to envision a series of conversations that explore progress and effectiveness, consistently using the language presented here, in mixed audiences, without confusion about how things are expected to influence each other.

VI.
The semantic resolution doesn't stop there, but since management tends to institutionalize its solutions, our various expectations of the management effort should be conceptually distinguished -- in a general way that clearly indicates what their evaluations will really care about and how they relate.
The conversation with our mixed audience should be able to cover the two broad reasons that usually steer the management of execution. Most organizations bring their concerns about achievement to the table in two flavors: financial and operational. If we cross-reference those against the worth of designated objectives and the value of execution, then we get guidance as in the table below.
Financial and operational concerns represent the two main ways that the organization keeps track of why any other party would want to have a relationship with the organization. Generally, the assets and trust that an organization has to offer are its main attractors. Management looks for, and distinguishes, related outcomes from its activity as follows:

Posted by Malcolm Ryder at 7:04 AM | Comments (0)
January 13, 2006
A Brief Survey of Gain
Why is it so often the case that when you get what you asked for it isn't what you wanted?
The easy answer is probably the correct one: you didn't ask for the right thing. Setting aside all matters of blame, the more important two points to consider are:
(1.) Why did you ask the way that you did? and...
(2.) What other way might you have asked?
An especially strong focus on this situation comes through using a portfolio manager. The amazing advantage of a managed portfolio is that it (normally) contains within it the logic that explains two things:
- how it is that what you ask for turns out to be what you want, as well as...
- why it makes sense to want what you need.
I.
Anyone raising children should be able to immediately appreciate the profound difference in the house that would occur if their kids had those two habits! And joking aside, this is really to the very point of portfolios: they implement maturity in the perspective on investment and gain.
A major ingredient of this maturity is the ability to distinguish different levels of commitment and expectations, and to logically match up commitments and expectations, consistently.
We can readily see this in the language that is typically used to describe events and conditions related to expectations and commitments -- but the irony is that in the heat of action we often lose our bearings and mismatch them:

One immediate "finding" from looking at the vocabulary is that it's a good idea to not confuse expense and cost -- and likewise to not confuse value and worth. By looking at what each of those items "will give" (third column) we can see that there's a difference and that one must ask for the right thing.
Our vocabulary chart seems to have a lot of redundancy in it, but one of its main points is to show that in a given situation we might easily think about gain in one way yet do something about it in a different way. What's the difference between why (before the fact) we pursue something and how (after the fact) we evaluate it?
II.
Another problem lies in potential confusion of what kind of commitment is being leveraged to serve the current purpose. Let's look at expense versus cost. What if, under the purpose of offering products or services, we're asked to "hold down cost"? That's not the same thing as being asked to "hold down expense".... Is something that is expensive necessarily costly? We can start to see in the vocabulary that the answer is "No" -- because the acquisition allowed by an expense might be something that greatly increases benefits, through ownership, and the benefits may be redeemable to lower overall cost.
Example: a person finds that a better car that is more expensive has reliability that, by allowing safe and flexible commuting over longer distances, increases opportunities to work for more money, which in turn can be used to lower outstanding debt or otherwise come to a better net balance. The reverse: a very inexpensive car has bad reliability, spends too much time not working well, and poses frequent risk and other limitations to reaching and keeping better work. Worst case, losing the job might also mean losing the car. In this latter scenario, "inexpensive" turns out to be pretty costly.
Such relationships start us thinking up the chain from expense to worth. How do we drive "good" value with cost? How do we drive "good" worth with value?
III.
On that point, what is the difference between worth and value? Simply defined, value is "a significant difference". But what is significant to one party or situation may not be to another. Worth puts the value in a context. Something may increase in value, but is the additional value producing high-priority benefits?
Example: a product or process might improve, but if it is not being used any more frequently by any more people then its additional value is not worth much. Different example: a party is trying to prove that a new approach is viable in a task; here, if the task outcomes show the slightest bit of improvement over the usual, that validates the approach, so that tiny increase in value has tremendous worth.
These are ideas that are not so much unusual or even news to us. Instead, the problem is that we often allow our familiarity with them to be sidestepped by decisions and actions that for some reason prescribe to notions and expectations that are not nearly as logical.
IV.
Observing a more rigorous vocabulary helps to clarify thinking. For example: if we think we need something to be valuable, we should know that what we are after is some kind of impact. This impact may or may not have anything to do with expense. But the point is that pursuing greater value does not automatically necessitate lowering (or raising) expense -- so we shouldn't expect expense to adequately talk about value. In some instances it might work out logically that expense will be a key factor of the opportunity to increase value, but that would be determined as a characteristic of the particular occasion for value-pursuit, not taken as a default principle of generating value. (Question: what does budget-compliance tell us about whether operations were effective? Answer: if anything, not much.)
Other scenarios as well should be more carefully understood. For example, can something that is very costly also be very worthy? Sure -- this is characteristic of the response to many emergencies, and in those cases it probably is true because whatever is very costly is also sufficiently valuable. On the other hand, we don't want everything to be an emergency, and it makes no sense to impose an evaluation system for emergencies onto non-emergency situations. Yet meanwhile, one situation that is not an emergency but is simply relatively "extreme" is common in the marketplace: it involves super-costly products (like the highest-end street-legal cars or virtuoso solo pianists), which virtually create business that otherwise would not exist.
Naturally, this thinking must also address ROI (return on investment).
Looking at the vocabulary chart, we see the left-most column naming commitments that "pay back" in accordance with objectives listed two columns to the right. When commitments are made , "returns" should be represented by the benefit provided towards the objective.
There is no special reason why the objective should ever be displaced as the reference for assessing the effects of making the commitment. However, this involves more than the benefits.
Following through with a commitment introduces other issues that, if tracked and weighed, might have characteristics that discourage or encourage a decision to make that same commitment again in the future. Knowledge of similar previous experience -- even that of other parties -- could have the same influence. It might therefore be that the "burden" experienced in certain commitments would compete with the basic objective in the process of justifying a decision to commit. The burden might set tolerances or precedents that must be forecasted and addressed "satisfactorily" before the follow-through is allowed to commence. Over time, attention to these "qualifiers" can dominate the perception of certain types of commitments -- especially for those that are recurring ones. A symptom of this is when the attention to the commitment is more about whether, compared to "the last time" or "usually", it is expected to be less problematic or moreso.
The execution of the follow-through to the commitment is a serious subject, but it still should not substitute its performance issues for the real objective of the commitment. If it does, it distorts the calculation of ROI.
V.
Instead, the objective is supposed to represent that a certain need has a sufficient priority to mandate supporting execution. The delivery of benefits to the objective should be assessed in terms of how much it helps the objective.
There may be competing objectives, however, and a limit to the overall capacity to address them all. So the correct way to approach things is to first decide whether the particular need is, at this time, really one that should be addressed -- and secondly, how aggressively it should be addresed.
In a portfolio, the corresponding move is to include or exclude investment categories in the portfolio. A category (which represents a need) has an objective, and investments are made within the category to help achieve the objective. Within the category, some investments made are better than others, from one time to another -- having to do with how effectively the selected sources of contributions to the category are executing as contributors.
By careful selection of contributors to carefully selected categories, we set up production of benefits that achieve objectives. But as cautioned in the vocabulary above, we need to be clear about what it is that we are really after, in order to ask for the right thing to make it happen.
Posted by Malcolm Ryder at 9:47 AM | Comments (0)
January 12, 2006
Compliance versus Compatibility in ITIL implementations
A key challenge of organizing service management practices along the guidelines of the IT Infrastructure Library (ITIL) is the issue of focusing on the objectives of practice as opposed to the mechanics of practice.
ITIL addresses this challenge by describing what differentiating effects of the practices are the ones that service managers and service customers should see in common as an outcome of any of its given management processes. These differentiating effects are where value in management improvement is measured.
The virtue of the followup process recommendations is that they link to those values by describing proven approaches to generating measurable and relevant results from the execution of the service organization.
The important execution results fall into two broad categories: interactions and outputs.
That may seem obvious, and it reflects the ITIL adopter's natural emphasis on processes. But what most organizations must remember to observe is that execution involves procedures, priorities and decisions blended together. Processes are just a mechanism for predictably binding those components of execution together, given the resources and culture of the particular organization that is responsible for conducting the process. By definition, the process cannot "override" those organizational elements because it is made up of them.
Every organization has specific characteristics of its resources and culture that can significantly vary or even disagree with those of another organization -- and even between one part and another part of the same organization. These differences stem from business requirements, funding histories, current knowledge, and other preconditions. Yet these disparate organizations have in common basic business functional responsibilities such as managing IT services.
In acknowledging that, ITIL clearly refuses to specify any particular resources or culture, but instead it provides operational objectives, along with numerous models for supporting them in the form of management processes.
When the organization prepares a service management process from an ITIL model, the process is said to have a degree of compatibility with ITIL.
The main goal of an ITIL Adoption initiative is to establish a known and measurable level of management process compatibility with ITIL.
Management processes have three fundamental purposes that link the ITIL compatibility to typical business needs for cost management, procedural effectiveness, and adaptability. Within the constraints of expense, target impacts, and change, the purposes of the needed management processes are, generally, to account for:
- why something should be attended to;
- what kind of attention it should get; and
- ensuring that appropriate attention is applied.
The first purpose is to establish regularity in associating response procedures with identified demand. Service stakeholders need to have a good idea of how demand will be handled before the demand is urgent. Key tasks to perform include:
- classifying and monitoring demand
- defining procedures and their scope, and
- granting permissions to both requestors and responders.
The second purpose is to establish the terms by which historical and current events will be described for triggering assignments and for analyzing changes in conditions. Key tasks to perform include:
- establishing quality-managed information repositories
- tailoring communications to fulfillment and auditing roles
- regulating the capture and transmission of critical event data
The third purpose is to prescribe enforceable responsibilities in the participation of all parties to a procedure. Key tasks to perform include:
- defining roles
- allocating resources
- tracking interactions and results
Meeting those three general obligations will result, respectively, in the development of rules, terminology and authorities. These management artifacts are typically used as building materials for organizational functions-- and can normally be used to compare a current organization against another current or any future proposed organization. However, those materials are not inherent indicators of functional performance; as with any resource or construction, their value to performance comes from how they are used, not from what they are. This reiterates the primary importance of objectives in the scheme of things, and that the notion of best practice is rooted in the objectives rather than in the procedures.
To sum up the above observations, an organization takes on an initiative to adopt ITIL guidance of the development and implementation of management processes that are compatible with service management objectives.
The guidance proactively reinforces desired levels of consistency with known best practices, but the guidance does not specify an organization's particular processes.
Rather, it helps to model process design and development for effective support of the key objectives of the service provision and relationship.
Posted by Malcolm Ryder at 12:26 PM | Comments (0) | TrackBack
Why You Can't Comply With ITIL
ITIL provides a framework of practice guidelines that offer a business-like model of managing IT operations.
To use ITIL effectively, comparisons need to be made between the resources and other commitments suggested by those models, versus resources and commitments that, for the given timespan under consideration, are certifiably available to and from the organization that wants to follow ITIL guidelines.
That comparison reveals the options and risks that:
(a.) get translated into decisions about what priorities and tolerances will be attached to actual resources and commitments, and
(b.) are controlled thereafter by management.
The translation, in other words, produces a set of requirements that are logically compatible with ITIL. These requirements can be intensively site-specific as well as idiosyncratic of the particular business.
The next step is to execute management processes such that the organization will comply with its peculiar ITIL-compatible requirements. The result of the compliance to those requirements means that the organization will become to some degree compatible with ITIL , even while potentially differing substantially and significantly from another ITIL-compatible organization.
The actual degree of compatibility is recognized as a level of "ITIL" maturity. But almost irrelevant to ITIL itself is the set of things about the organization that are not yet compatible -- irrelevant except to the extent that those incompatibilites are actually inhibiting or preventing further ITIL-maturation.
Meanwhile, at every point and level of ITIL-maturation, the impact of compliance to the ITIL-compatible requirements offers some amount of practical and measurable impact on the business, and that impact (whatever it is) will be examined in terms of "business value". The level of business value is not guaranteed by ITIL -- rather, ITIL helps to design greater opportunity to generate more value.
The actual business value of the impact will be strictly dependent on the strategic objectives and competitive positions of the business operations -- a set of issues for which the validity and scale lies entirely outside of the models of ITIL guidelines. But the business operations are logical "clients" of ITIL-guided improvements in IT operational competency.
Executives and Managers need to understand the difference between ITIL-Capability, IT's Competency, and IT Capability.
IT's Competency seeks to exploit improvements in IT capability as modeled by ITIL. But IT's Competency is essentially defined in the relationship with the client of IT: "competency" is a consistently appropriate responsiveness to the real-time demand of IT users.
ITIL-guided improvements achieved in IT capability can contribute to that competency through the benefits of good management. Management takes the responsibility for generating value from whatever level of IT capability currently exists, for whatever reason it exists.
But additionally, managers want to see that actual capabilities, if they are being modeled after ITIL, are getting stronger. This is a separate and important problem because of the burden that adopting ITIL places on organizations, when other paths to capability improvement (outsourcing, hiring, etc.) might be feasible from the perspective of the business.
Thus, organizations need to understand what level of "ITIL-capability" is necessary for the business at the different levels and segments of the organization, and not attempt to over-shoot the demonstrable business feasibility.
But management should primarily aim in all occasions to achieve ITIL-compatibility as a way to improve IT's Competency.
In light of all of the above, the notion of ITIL "compliance" is at best an abbreviation that helps to market ITIL's importance along with general commitments to standards. This might be an acceptable and even productive metaphorical take on ITIL. But at worst, if taken literally, the notion of ITIL "compliance" sends the organization and its management off on an expensive and furious path to solving a non-existent problem.
Non-existent? Case in point: organizations that are not really very mature in their ITIL-compatibility may still be entirely capable of generating high business value from IT operations; it just depends on what kind of demand the business is placing on them. This is at least historically verified, although it may not be true of most businesses past or present.
That said, for even successful yet immature organizations, the issue is one of whether their economies of scale and "economies of quality" allow them to be agile enough to keep up with evolving business demand. That is, will their capability offer enough to be competent? Here, the key point is this: synchronizing actual responsiveness with actual and foreseeable demand is "good enough", while pursuit of a hypothetical perfect match to some other model is arguably irresponsible unless it somehow magically places no unacceptable burden on being immediately good enough.
IT Capability improvement is thus a parallel consideration to IT's competency improvement. In particular, if the business determines that it is not being demanding enough to achieve a reasonable level of the potential represented in the business model and business plan, IT's capability might become a decisive new factor, with greater capability offering the business new kinds of opportunity that can be exploited for greater business value, and lesser capability being an all-around inhibitor.. This is not , however, a business decision that is essentially dependent on ITIL-maturity -- and certainly not dependent on a false concept of "ITIL-compliance."
By analogy: you're not likely to win a playoff game if all you have is your third-string rookie quarterback -- a not very mature quarterback. But in such a case, winning now instead of losing now will require having the right (probably other) persons call the plays, having the right additional roles execute well, and having everyone use the same system of coordination so as to maximize efficient pursuit of the only advantageous paths to the goal. Your longer-range intent will always still be to bring a great quarterback into your game. On the flip side, adding a great (very mature) player to an average team can obviously improve the team by adding new dimensions to its options and execution. But the rest of the team must be capable of taking advantage of the quarterback's ability, and it may need to be reorganized in order to gain that capability.
So, if your organization has an ITIL Initiative and you are frustrated with a perceived lack of "progress", it is entirely approprate to first review whether expectations are driven by a definition of the right problem to solve, and likewise whether the requirements that performance assessment is based on have been derived primarily to represent competency instead of merely capability.
Finally, if your primary perspective and responsibility is "compliance", then you are engaged in an initiative whose fundamental justification is risk management, not competency. In this case, there is no built-in conflict from using ITIL as a frame-of-reference, but the performance assessment should be based on measured changes in risk factors that are demonstrably linked to capability levels, not based on competency-driven business value factors.
Posted by Malcolm Ryder at 10:12 AM | Comments (0) | TrackBack
January 11, 2006
Why Strategists Must Think "IT" Through
Our big challenge with strategy is to tame it -- to translate the alchemies, voodoo and romance of intuitions and insights and intents, into something credible and practical; into capabilities and competencies that make a virtual opportunity real.
We took three shots at this.
(1) One translation is a thought experiment. Surveying the vast inventory of literature on strategy, we took a moment to try to parse its boundless advice into its typical themes -- with results such as: why to pursue execution for value; how to avoid a position of (poor) performance; and so on. Then we looked at the themes for their generic components. It gave us the following table of elements with which to reconstruct and predict themes:

This provides a hope that by mixing the building blocks (left to right) in different ways, we could derive the not-too-many worthwhile starting viewpoints, and thus throw a defensible practical fence around strategy! Each uniquely different combination of elements could be considered a certain known problem to solve -- addressed by strategy literature's various promotional and cautionary tales.
But such high-level problem definitions are mainly conceptual. To get them more specifically in focus, and get their corresponding solutions down to earth and in-house, we also need each element of a problem's definition to be detailed by the additional aspect of "management" vs. "infrastructure". Drilling down into the elements that way, we still "choose and add" the different elements to each other (left to right) to derive the problem statement. Connecting fine-grained elements to each other may actually give a more precise surface description of a particular organization's issue, but at the same time it accounts for how some problems leave us not being able to see the forest for the trees. Our table can help bring the forest into view.
(2) Another translation is already explicitly described in the literatures. Regardless of how many ways strategy stories begin, much of the discussion ultimately drives to the same counsel -- that decisions reshape the organization, after which the organization's operation must be motivated enough and funded enough to stay with the program.
This summary casts long political and cultural shadows over all discussions of any competency and capability that are to be acquired and committed.
(3) In a third and parallel translation, we note that all strategy refers to an opportunity (whether remedial or progressive) -- and opportunity always refers to the perceived characteristics of currently acknowledged conditions. In pursuing strategy, decisions follow the anticipation, observation and analysis of those conditions. Challenged by the conditions, much of this pursuit is competitive.
But the way we see those conditions increasingly finds them loaded with characteristics that exist only because of the impact of information technology. Because IT utilization dominates the shaping of the environment that strategy wants to exploit, strategists must always factor in IT. The way that IT changes things becomes the focus of concern, even moreso than the particular features that have been wrought.
Of special importance, "IT Innovation" means that people can know different things, in different ways, at different times than previously, and furthermore do different things than they have before about what they know. Put so bluntly, it is obvious why strategy cannot be well formulated without factoring in IT -- IT can be the thing that defines the competition -- whether the competition is an environment or another actor.
The question is, will the strategist's own organization manage IT utilization to virtually pick the competition that it wants to have?
Posted by Malcolm Ryder at 8:13 AM | Comments (0)
January 10, 2006
Innovation, Invention, and Interventions for Improvement
In the post-cost-cutting era, no improvement is more popular but elusive than gaining "sustainable competitive advantage."
Any one of its three parts is hard enough to deal with. And though their combination is even more daunting, it is practically irresistable. Why? Because as a justification for whatever else we do, it's pretty hard to beat.
We especially love the idea that we can do it over and over. And after all, what point does our old favorite continuous improvement have if it does not fortify the maintenance of advantage?
On closer look, just agreeing on what the phrase "sustainable competitive advantage" really means is a good trick in itself. We have to parse it carefully to be sure we go after the right problem...
For example: each part of the idea merits its own auditing: Are we competitive? Is our competitiveness creating an advantage? Is the advantage sustainable? This is the typical line for performance evaluations.
But some see the problem a bit differently: Do we have an advantage? Is the advantage making us competitive? Is our competitiveness sustainable? This is the line for launching new organizations, products, or ideas.
Today, the second interpretation has really come into its own, with "Innovation" being the major mantra. Is innovation always justified?
I. Change how you Change
On the surface innovation certainly seems like a good development. In real improvement, changes are always made and the changes have to matter. With an innovation, one might either change the rules a bit and scoot ahead of "the pack", or simply "break through" the status quo to hit a goal line before others do.
But most often, improvement calls for a change that is not even an innovation. Because we work ambitiously in increasingly complex circumstances, what we make is usually more likely to demand our attention to incumbent defects, omissions and errors. Also, due to shifting circumstances, improvement may not be significant if it is rendered only ephemeral. These points -- complexity and variation -- suggest that improvement should be tackled strategically.
As a strategic problem, improvement is challenging to solve mainly due to the way complexity and uncertainty affect the design effort for the solution. Navigating through the challenge, we respond to complexity (choices) and uncertainty (surprise) by making changes that can easily leave things different but not necessarily better. So how often can we say that innovation is strategic?
All innovation is pursued under the umbrella of improvement. To establish innovation as the most likely capture of value from action, the whole issue of what is "better" first demands some up-front declaration of what is really needed -- from which we can see innovation not just as a capability, but more importantly as an opportunity to solve the "right" problem.
II. Cause and Effect
The ambitions of having a "disruptor" or a "breakthrough" have often stayed separate, although without deep thought it might appear that they both lie at the end of the same "path of improvement". That is, we take it for granted that we know the path : innovation is a premeditated effort to produce something unprecedented.
But there may be some debate -- for example, as to whether a given "innovative" effect was intentional or accidental; that makes us look back for differing causes.
An innovative effect is often mainly a matter of using something old in a different way, or something new in an old way; along that line, accidents and luck both count as sources. But those point us at the more general idea of discovery -- what many people could later call innovation.
Against the status quo, a discovery is notable precisely because it is a change. But often the discovery of some new usage or effect remains only with the discoverer, especially if the discovery held no importance to the discoverer beyond the moment that it occurred.
Meanwhile, as they say, necessity is the mother of invention. Contrasting with discovery, invention is considered to be a more explicitly intentional effort for a certain lasting effect.
Of the two paths, invention is of particular noteworthiness to self-consious planners and innovators, but "invention" and innovation are only sometimes the same.
We politically reserve the term "innovation" for changes that impact arenas much wider than the laboratory of the change-agent -- in more or less the same manner that we reserve the term "IP" for referencing a situation that presumes distribution of content beyond the creator. This also affects our sense of where to get innovations.
And whether the innovation really means anything in terms of improvement will depend on the reception it gets in the arena to which it is delivered.
Not all arenas will be equally hospitable to the innovation; so (as all marketers know), if we want to get real value from the innovation, we first do a little forecasting of who cares about the innovation's impact.
Thus, the idea of attaining sustainable competitive advantage from innovation should be looked at in terms of confidently identifying where there is a need for certain kinds of change.
III. How new gets better
To help with the identification, we need a high-level view that tracks the "value chain of change" underlying an innovation's effectiveness. What happens? How do we make it happen when we want? Where do we want it to happen? Why?

Overlaying that sequence, we bring our three-part "improvement" goal: sustainable competitive advantage. Typically, sustainable signifies control; competitive signifies effective; and advantage signifies leverage -- so when the sequence above works best for us it supports all three parts.
Intentional improvement therefore presumes attention to how each point in the chain ought to support or increase the final control, effectiveness and/or leverage needed.
IV. Getting There from Here
Planned improvement always presumes control of change itself, while bringing a perspective that gauges the difference between the current position and a future position. It idealizes the path from point A to point B; but in real life, other distracting stuff usually happens along the way. It becomes necessary to anticipate where that stuff can come from, so we have to be able to understand that the "single path" results from our exposure and reaction to multiple influences -- the combination of why we do what we do, and where we are when we do it.
Planned improvement works hard to integrate those two influences and thereby control change. The following illustration shows how the corresponding issues of execution and position are combined in a single view.

In the planning sense, this picture shows the operating environment as a "current state engine": a set of "parts" -- material elements and action components -- that are manipulated in a defined change.
- Execution is composed of the managed interactions between the parts.
- Position (breadth and locations) is composed of the scope and range of the effects of that management.
That means we can directly relate position and impact. Since value is attributed to the impact, innovation's path to value goes through "position".
But since position is a result of execution, we have to look at execution as a way to understand innovation.
V. Paving the Path
In managing the state of operations, there is continual decision and action.
- Decisions select material elements -- i.e., Functions, Resources and Costs -- that determine the scope of what will be done, how, and to what extent.
- But using the action components -- i.e., Implementation, Allocation and Regulation -- we translate that scope into range , thus determining where operational impacts will occur.
By that same arrangement, the entire change value chain is attentively traversed. Therefore, at this general level, there is an inherent ability to do new things.
But management first sees to it that the action components give the material elements a regular interaction that approaches a "steady state". In each practical iteration:
- Implementation relates Functions and Resources ;
- Allocation relates Resources and Costs practicall; and,
- Regulation, closing the loop, relates Costs and Functions.
In designing a steady state, functions are designated first, then resources are proposed to support the functions and costs are derived to support the resources. Otherwise, the functions are not seen as viable and they get revised. These selections may be finalized through trial and error or by investing adequately in already known designs. Bringing about this alignment for the purpose of achieving a targeted future state is what the design of the controls on change --i.e., the design of the solution -- is supposed to do. The future may or may not need to be different from the present.
When change is intentionally pursued:
- management first alters the arrangement of functions, resources and costs -- manipulating or intervening by using implementation, allocation and regulation. - If that doesn't work, then new selections may be made in functions, resources and costs.
The designer can face challenges to both the activities and materials intended. They typically crop up in the form of complexity and uncertainty, which may force trade-offs and risks -- some of which might mean that the ideal outcome is compromised although still remaining useful. Naturally, management wants to minimize the need for compromise.
Invention within design is often all about finding a design that can overcome the customary challenges. The ambition of an innovation is all about finding a design that gets to the solution without the customary challenges.
VI. Likely Obstacles
Acknowledging that there may be multiple iterations (cycles) of effort needed, the general idea in "improvement" is to navigate from current point A to future point B, minimizing interruptions and tangents.
Invention and innovation may play big roles in getting to point B, but of course their occurrence will be helpful only if they produce differences that really matter while not unreasonably increasing risks.
We can't underestimate the importance of risk, because it can increase uncertainty and complexity, or even simply prevent change. Risk is perceived and real, and comes in various flavors and degrees.
For example: in the "continuous" improvement scenario, invention is a challenge to the composition of an incumbent plan of alignment. Literally, the manager may see the invention and ask, "what am I supposed to do with this?" and/or "why should I allow this?" Notably, invention can suggest that current efforts are solving problems the wrong way. Invention and management work most directly on the functions, resources and costs.
The effort to streamline and ensure the alignment similarly means that innovation itself is a challenge -- to accountability. Innovation may alter or even contradict the terms of the incumbent or legacy design, calling the design's interconnections (and/or their customary effectiveness) invalid for the need of most current importance. Innovation can suggest that current efforts are solving the wrong problem. Innovation and accounting work most directly on the implementations, allocations and regulations.
Finally, even improvement itself can be misguided. For example, one principle that has been proven in many situations is that "perfect is the enemy of good enough." This reflects the challenge of correctly prioritizing the goal of an effort.
Thus at every level of our intention to change, we have a contest of ambition and risk:
- improvement versus priority;
- innovation versus accounting; and
- invention versus management.
VII. Invention versus Management
Usually, we focus on improvement with the assumption that priority is not in debate.
To win the other contests, we proactively identify and influence the contestant activities: invention and management, or likewise innovation and accounting.
As solution designers, our task is to select the activities and then orchestrate their relationship to each other. We also want our design to be open to ongoing verification and validation. Therefore, from a perspective of change-control, the selections should be modeled, and the orchestrations should be monitored.
However, before any specific discipline or school of pratice is imposed on the design, consider "fundamentals" that are common across all specialties.
For example: we should identify the two different activities by their "essential" and distinguishing natures.
- the essence of the Invention effort is in design, development and deployment.
- Management's essential task targets are control, maturation and change.
Meanwhile, the key influences on invention and management are knowledge efforts -- Search and Research.
- Search: discover, define and classify.
- Research: assess and adopt.
The following table lays out those fundamentals, illustrating a responsibility or opportunity for improvement as approachable through invention and/or management.

Here, Search and Research tasks drive coverage of concerns that are characteristic in both Invention and Management approaches, producing four distinctive quadrants of interactions to coordinate. Parenthetically, the diagonals crossing the quadrants suggest "layers" of re-engineering that exist between Assessments (which often propose needs) and Control (which satisfies needs). But across the horizontal rows, we see that Search is instrumentally linked to modeling, while Research is likewise linked to monitoring.
Without this picture, we might have assumed the reverse -- i.e., that search is about monitoring, and research about modeling. But here we can see why that is not the case. Search must be about the nature of the thing being sought, otherwise we find the wrong thing; we need an identity of what to look for. Research must be about the importance of finding that thing, otherwise there is no value from knowing about it; we need a reason to look for something. Models express identity; monitors express reasons. As knowledge instruments, they expand our awareness of identities and reasons, thus enabling change, thus enabling improvement.
VIII. Innovation versus Accounting
As solution designers we also attend to identifying and influencing implementations, allocations and regulations. A different set of concerns applies here, but modeling and monitoring are terms that link this second group to the above.
Now, the view is on innovation and accounting, which like invention and management might be adversarial but can be complementary if their co-operation is understood. (Here, "accounting" means an investigation that establishes accountability.)
Again we start our considerations with fundamentals rather than with any branded discipline or practice.
First there are basic identities to establish:
- The essential nature of innovation is to remodel something within a given context. (Innovation naturally exploits the modeling in search, if search is provided.)
- Accounting, meanwhile, essentially aims to confirm compliance with a set of permissions or priorities. (Accounting naturally exploits the monitoring in research.)
Meanwhile: the key influences on innovation and accounting are demand contexts -- Needs and Requirements.
- Needs: responses make selections from choices, per an objective
- Requirements: responses incorporate selections per an operation
This following table illustrates the overlay of those issues.

In this picture, we see improvement described as a matter of decision-making about responsiveness. Overall, it shows four different things that can be changed in order to respond to a demand.
More specifically, Responsiveness is being exercised from two perspectives: innovation, in which new kinds of responses are conceived or proposed; and accounting, in which validation is applied to determine whether responses are appropriately directed. Across the horizontal row for Needs, we see strategy represented. And across the Requirements row, we see planning.
- With the responsibility for synchronizing expectations and tolerances, strategy addresses control.
- With the responsibility for reconciling the application of new responses with the forms in which they can be produced, planning addresses effectiveness.
In bringing that to light, this picture is another interesting reversal of typical presumptions: strategy is usually associated with a targeted effectiveness, while planning is associated with control. But here the point is that strategy sets the boundaries around the influence of potential responses, in order to direct them to a goal; meanwhile, planning organizes available resources and commitments to optimally format and support opportunities to respond.
IX. Improvement vs. Priority
The four pictures above expose major touchpoints at which management interventions will alter the position and execution of the current state towards the target state, and thus will moderate improvement.
For example: paradigms and policies, classifications and deployments, or functions and allocations -- all offer different locations and depths at which to intervene, while also soliciting the involvement of readily identified roles or members of the organization.
It's likely that all of these various items are already underway in the organization for one reason or another. The above illustrations provide an argument for how they would logically influence each other to engineer "improvement".
We said the ideal improvement frames the problem like this:
Do we have an advantage? (leverage)
Does the advantage make us competitive? (effectiveness)
Is the competitiveness sustainable? (control)
From the argument of the pictures above, planning turns out to address effectiveness, and strategy addresses control. But what about leverage? How do we identify initial advantage?
When we ask the question, "do we have an advantage?" here's what we are really asking:
"Do we have a characteristic ...
that we can dramatically exploit, in order to ...
change circumstances such that, ...
for what we want to gain, ...
our resulting beneficial options greatly outweigh our inhibitors?
Implementation, allocation and regulation together turn functions, resources and costs into a particular business operation. This is a matter of how those parts are aligned.
Production within that alignment provides the actual responsiveness to demand. The potential responsiveness is what we identify as competency, and in that light, we recognize the alignment as the basis of competency. The impact of the responsiveness changes circumstances in a way that is appropriate to the demand. Meanwhile, the alignment can host more than one kind of response, and any given response may be hosted more or less well. This means that there are multiple competencies to consider.
Planning aims at leverage by selecting and fortifying a potential competency, protecting it with strategy, and using it to allow the organization a highly convenient position with respect to demand.
To create leverage, that selected competency must, like a fulcrum, also allow actual responsiveness under demand to multiply the influence of the organization's position. This influence is measured in terms of the beneficial options -- or in other words, opportunity -- created by execution from the position.
The simplest way to envision this magnification of effectiveness is to imagine that more demand is being satisfied through the execution.
But to get to that effectiveness, the savvy organization targets "improvement" efforts for locations showing increases of important demand that it can satisfy more readily than can competitors.
The key to performance in this will be deliveries to those locations. But the underlying critical success factor is the working definition of demand. According to how demand is defined, the locations will change. Innovation reconceives the demand -- thus proposing not only the locations but also a new target relationship of competency and priority.
Posted by Malcolm Ryder at 5:02 PM | Comments (0)
Evidence versus Truth, or Will the Witness Please Answer the Question!
From the land of "ignorance is no excuse" comes this picture of the fine line between being "accountable" and being "guilty".
At Federal Agency employee performance evaluation time, overwrought managers avoid confrontation and hassles with poor employees, but go on to solve the wrong problem, by simply giving them (only) a passing grade that makes all further debate moot. But then a new manager takes over and wants to get rid of the bad worker, which can't be done because the personnel folder doesn't have anything in it to support the claim of poor performance.
Thus proving once again that when it comes to measurement, like with jokes, what makes it work is not what you tell but how you tell it -- then the problem usually kicks in with the re-telling by someone else.
So much for a single version of the truth!
See the full gory story by Washington Post columnist Stephen Barr at the Federal Diary for Tuesday, January 10, 2006.
Posted by Malcolm Ryder at 1:11 PM | Comments (0) | TrackBack
January 7, 2006
Execution as "Progress": The Four Types of Value in Performance
Here's an odd thought: if "execution" didn't change anything, then we wouldn't have to do anything to get where we want to be.
We just might not have any idea of when we'd get there.
But to know whether execution matters, it's mandatory to accurately determine whether progress is being made towards targets.
Experience has shown there's more to the problem, though: the target might be reached, and reached in the prescribed way, but the impact of that achievement might still not make the difference that was actually needed from the execution.
For getting the big picture of what matters, the most important issue is to know whether the right targets are in place. Having the big picture means knowing that the efforts thought to be "progressive" are solving the right problem.
I.
"Progress", a measurement of performance, is the concept that drives most management decisions about whether execution is "effective".
In practice, a target level of achievement is set, and "performance" pertains to the actual level obtained as measured against the target. Management continually adjusts execution to approach the target.
What a target really represents is a threshhold of change at which some necessary value is expected to be obtainable or obtained.
In other words, the target points to a working hypothesis of what kind of conditions need to be altered in order for the performer to intentionally arrive at a desired future state.
Granted, when things are going well and execution is usually reaching the target, the mentality about conditions is not so much that they are being "changed" as simply driven... Nonetheless the true importance of the target is that it originated in an awareness of some unwanted (if not harmful) condition that would likely prevail unless an effort was being made to change it for the "better"... That awareness is, after all, the motive.
But targets have a funny way of suppressing (or replacing) our memory of that baseline.
And from that point, the means go on to grab attention. Both the specific form of effort and the mode of the effort are variable factors in bringing about the change.
- By form, we mean the manner in which the effort practically incorporates the capability of resources and actors. For example, automation and manual labor are different forms of effort.
- But by mode, we mean the general but characteristic strategy of alteration being pursued by the execution. For example, persuasion is a different mode than force; gambling is a different mode than saving.
A forgotten motive and variable means can make the message in measured achievement deceptive. How does the performer know that the results this time are, through the same means, repeatable and relevant in the future?
II.
While measured against targets, execution is typically monitored in terms of actions versus requirements. Usually the actions are accompanied by attention to their associated risks and rewards. Management makes discretionary, circumstantial decisions based on tolerable balances of risk and reward.
But when we understand that the essential problem for execution is to change conditions, we can understand execution decisions more strategically -- as a matter of connecting choices (e.g., of resources, operations or relationships) to needs (which are what sets the context for strategic value).
From a strategic value perspective, we describe "progress" as being the satisfaction of need.
Thus, in considering the value of performance, one of the first key questions to address is, "what type of need is the desired future state presenting?" Getting the need properly defined must precede decisions about how to execute.

Then, needs are met through changes wrought by execution.
III.
Here we must look at the business as a performer, and at a way to generalize the concept of "needs" into practice.
The performer has four basic ways that it can address the environment in which it operates. These ways -- or modes of progress -- are used as working categories of opportunities that the performer thinks it must have in order to arrive at the desired future state:
- transform itself (e.g., transcend the environment)
- comply itself (e.g., match the environment)
- exploit circumstances (e.g., master the rules), or...
- adapt circumstances (e.g., change the rules).
Put simply, execution has no value per se, but instead is responsible for making those four things occur, whichever of them is selected as offering the best apparent likelihood of reaching the main goal.
IV.
In making that selection of what to execute for, we factor in necessary capabilities, thinking about the two basic ways that anything influences an intended change -- as either an inhibitor or a benefit.
What we want to be able to see is how different circumstances would inhibit or benefit the change needed for gaining the desired future state.
On the one hand, the means of execution are circumstances that will directly impact the intended change, so visibility of means is important to describing how the execution effort gets to create value.
But due to management, the most immediately significant circumstances around the execution effort are dictated by an objective that is attached to (and justifies) the effort. For example, supervision, resourcing, support and approvals are all aligned around the effort in order to make it bear directly on the objective successfully.
Speaking at the highest level of generality: when the purpose is to "improve" on a current state, the business as a "performer" has at least four objectives to work with.
For pro-actively generating value from the change-effort, the performer might...
enforce these:
- regulations (esp. involuntary); and/or...
- standards (esp. voluntary);
and/or develop these:
- modifications (incl. discretionary), and/or...
- new options (incl. contingent).
Generally, these four approaches tackle what are initially constraints on the current state. But they may be pursued with a special understanding -- namely, through execution the constraints can be exercised as opportunities.
That allows us to see the constraints as success factors for progress, but we have to answer the question, "for what kind of progress?"
V.
Answering that question, the framework below first assumes a "worst case scenario" about change, which is that change is usually going to be ad hoc, arbitrary or chaotic, unless explicit management is applied to it.
Considered against that assumption, management can generically distinguish each of the four approaches to execution. Each approach has a characteristic "default balance" not of risk versus reward but instead of inhibition versus benefit that it is expected to contribute to the performer's intended change-effort.
Through their typically lower or higher contribution of inhibition or benefit, the four approaches are positioned relative to each other in the framework. With that done, the illustration also maps them to the four basic modes of progress (i.e., types of value) available to the performer. In doing that, it suggests that each different approach "naturally" makes a contribution to certain types of value.

Likewise, certain approaches appear to be more appropriate to or successful for certain kinds of problems, while less so for others.
For example: If the performer can decide that the desired future state requires transformation, then "regulations" are less likely to be the place to look for key solution elements. However, transformation requires low levels of inhibition. And "modifications" are significant to transformation, while "options" are more aggressive.
The main purpose of this framework is to illustrate a mentality that allows logical analysis of how execution and value are linked. For certain managers or organizations, the details such as the four proposed modes of progress or execution approaches might be debated or even replaced with other items more closely matching their experience. But the most important management consideration with an overall view like this is that execution is in fact establishing a type of value that is truly relevant to the desired future state.
VI.
Supporting the desired type of value with execution comes with one other wrinkle. Each quadrant of the above framework offers a constraint to convert into an opportunity, but the conversion itself has a "default" or generic quality, which characterizes the quadrant's different approaches as follows:
- upper left: "conservative"
- upper right:"ambitious"
- lower left: "statutory"
- lower right: "radical"
This observation would be just a footnote, except that often the approval of execution plans is dependent on the political climate, habit or other tolerance that decision-makers have for certain styles of pursuit. Those issues could improperly insert themselves into the situation as the main reasons for "why" something should be done -- displacing the value proposition that identifies the performer's real goal or what outside observers would call "real progress"...
As a result, properly managing performance must include an aspect of assessment that first objectively describes the logic of the selected approach in terms of the value-goal, and only afterwards describes the feasibility of sustaining the approach. In that way, the most opportunistic or emotionally desirable approach might even get ruled out, but it is always more likely that the correct approach will be identified regardless of how difficult it is to execute. At minimum, this will prevent costly commitments to solving the wrong problem.
Posted by Malcolm Ryder at 6:49 AM | Comments (0) | TrackBack
January 5, 2006
Infrastructure, Information and Innovation - Who's on First?
"Business improvement" is an easy ambition to have but often hard to act on effectively, because it is so vague. However, the beginning steps of defining it are well known -- they always include deciding what are the needs and requirements of the business.
Yet too often that yields to confusion bred by habitual thinking, political and religious energy, risk-aversion, and inexperience. Each of those different influences is a considerable threat to "improvement" if it distorts a constructive path of change. However, all of them can be dealt with through the same review of basics that help identify why anything should change.
The outcome of the review is clarity on what kind of change is most likely to constitute meaningful improvement.
I.
As a rule of thumb, needs are recognizable as what effect must be obtained from activity; requirements are recognizable as how the effects must be achieved.
This is how we can understand that even when "everything was done correctly", the result may be unusable or unacceptable. In such cases, the mistake is often that needs were not adequately translated into requirements because the nature (persistence, priority or timing) of the need was not strongly enough determined. This uncertainty allows the "wrong" requirements to be derived, because the requirements do not actually solve the right problem even though they drive downstream impacts inviting not only failure but the "law of unintended consequences".
Paralleling the importance of that distinction, the key difference between capability and competency is that capability addresses requirements while competency addresses needs.
Because of this difference, when "business needs" change it is the type and strength of competency that must first be determined.
On the other hand, business requirements may be changing even when needs are not, and this should be addressed with capabilty.
The message to the business improvement crowd is that the organization's leaders must confirm the right problem to solve before it decides "the right way" to solve anything.
Meanwhile, for managers the most interesting aspect of the relationship between needs and requirements is that an inability to satisfy requirements that support a need can actually force the need to change. That is, if a party's capabilities leave its problem effectively unsolvable, the party must then either reposition itself to make the problem irrelevant, or it must suffer consequences that will alter its circumstance in ways that most likely reset its agenda. Either way, the needs will have changed.
In effect, business actually predicates its success on "picking the right needs"... That is, its needs come from a position that the business takes in order to have certain advantages, and it typically organizes itself around the needs of the position. Thus, unless the position is intentionally changed, the business is actually reluctant to have needs change! This focus on a status quo encourages a mindset of, primarily, attention to planned capability over competency. But capability improvement will prove to be no more important than competency improvement.
II.
Business looks to "IT" to provide capability that is appropriate for needs. The business value of managing IT is in that it manages a "resource", which in this case involves managing both the quality and delivery of information and of technology. But the key responsibility of that management is not to select the "correct" information; rather it is to establish and operate technology that assures quality and delivery of information.
A strict understanding of that scope of responsibility makes it easy for us to identify that "information technology" is different from, but accompanied by, "information process".
Information process, for example, determines what information should exist, where it should exist, when, and why -- in utilization. Information technology is then employed to enact and defend those decisions. A typewriter doesn't decide what to put on the paper, but it enables putting the right thing on the page.
If we extend this idea by using customary business mantras, we ultimately also distinctly consider "information people". Information people determine whether information is valuable or not. They must determine which information (from that which is available) should be accepted, and what purpose demands the acceptance.
Information people operate with a chain of dependencies -- they need information process to make suitable information available, and process needs technology to provide practical information-supply. Thus each link in the chain offers an element of opportunity to the business activity relying on information. But likewise, since each link has its respective responsibility, a lack of capability can strike at any of the three points, disrupting their interdependencies.
Supporting the integrity of the chain requires a practice that addresses the risk factors especially pertinent to each part of the chain. These factors can differ radically from one link to another, and ultimately the approach to maintaining the chain's integrity is not just one of spot maintenance of the links but instead systematic and ecological balancing of overall stress.
Seen as the "requirements" arena, this approach has to be translated into a management practice. The practice must include -- and organize dynamic access to -- knowledge that spans the experience, expertise and expectations of the three points in the chain.
III.
That holistic perspective strongly affects how we understand the three most urgent management concerns of the business "performance" -- infrastructure, information and innovation.
In general, "performance" measures how much achievement occurred towards a target amount of progress. Ordinarily, management emphasizes execution of planned procedures when trying to improve achievement. But to really grasp the situation, we need to look at prerequisites for progress, understanding that execution simply exercizes the potential these prerequisites provide.
Infrastructure provides the environment in which things can get done, in the form of services and facilities that support processes. This makes information technology and infrastructure parallel concerns, but the components of an adequate infrastructure are clearly broader than just technology. Obviously, you cannot have a service or a facility without also incorporating decisions and procedures. The challenge is to coordinate the various success factors of a "service" or "facility" to assure their presence for users in the environment. (Thus, infrastructure all by itself already includes technology, process and people dimensions to manage.)
Information provides the description of states and events that distinguish what needs to be done. The decision about what needs to be done will matter not just because of its eventual outcome, but more because at any given time more than one thing might be do-able and the challenge is to make the optimal choice.
Innovation provides the opportunity to bring new solutions to problems and/or to solve new problems. This represents a party's ability to act beyond its previous limits, but on its own it does not automatically mean that there is a need to do so. Without context, innovation has little intrinsic business value, so first the challenge is to identify the context that represents a "necessary change".
Given the co-existence of these three problems -- assured presence, optimal choice, and necessary change -- a party must consider its ability to work on all three, which calls for both capacity and prioritization.
Capacity will involve both (a.) resources and (b.) the practices that direct and constrain their lifecycle. Practices will in effect generate the technology, information and people that are actually employed at any time for the purpose of business improvement (i.e., solving the three problems). Pragmatically, that overall employment effectively predetermines the capacity.
Priority will involve both (a.) importance and (b.) urgency. Urgency will be the bulk of the influence by which the business's activity shapes the environment in which it finds itself. Urgency is not about how fast and hard something is done. Rather, it is about how soon the party takes significant action on a need. Pragmatically, urgency doesn't make an action important; instead, the significance gives the urgency priority.
Resources, practices, importance and urgency are ingredients that must be blended into a solution for each of the three problems.
But to direct that blending, the right first move is to isolate what the most fundamental inhibitor of business improvement is at the time, and rank the problems accordingly.
IV.
For example, each prerequisite has a characteristic underying issue that dominates its intensity, persistence, and overall difficulty. That issue is a candidate inhibitor.
According to the basic purpose we've identified for each prerequisite:
- Infrastructure must work within the certainty of user demand
- Information must work within the complexity of the operating circumstances
- Innovation must work within the equilibrium of the environmental dynamics
Levels of certainty, complexity and equilibrium -- which can dramatically and suddenly vary -- must be consciously approached with an awareness of what kind of opportunities and risks they present to the business agenda. In that awareness, rating them individually and against each other as problems establishes a sense of what needs the most attention. Thereafter, the issue is to look at whether the existing capability to attend to a problem is already sufficient or needs to be modified.
This does not mean that each of the three prerequisites has a single unique issue to address. The reality is that each one (infrastructure, information and innovation) has its own flavors and ingredients of uncertainty, overcomplexity and disequilibrium that it may need to resolve.
But the business overview of the problems must try to reveal where the biggest bang for the buck is in directing its capacity and priority, and this takes the matter back to understanding the interdependencies that create the chain of throughput needed for the business to succeed with its agenda.
As businesses become more knowledge-driven, the view and prediction here is more systemic: if infrastructure cannot adequately address the level of demand, then information cannot adequately address the level of complexity, and innovation cannot adequately address the level of equilibrium.
Success looks different at each of the three different points, while success at all three points maximizes overall "throughput". This is the picture of business capability -- the ability to generate necessary effects in the required way. But what about competency?
Business competency exhibits the ability to produce what is necessary on demand, but it must largely concern itself first with being able to determine and understand what is necessary.
Necessity cannot be determined without a model that defines (a.) the intended effect of the business and (b.) how the structure of the business logically addresses the intended effect. If the business has decided what it intends to be, then it has a reference point for determining what conditions are compatible or incompatible with that intent.
This awareness may never even reach "perfect knowledge", but it doesn't need to be perfect -- rather only "good enough", for health and growth.
V.
Increasingly, business looks to "IT" to improve business competency. This is important in two major ways.
First, it represents a set of expectations of IT-based capability that may need to be validated before they can be considered reasonable.
Second, it becomes mandatory to distinguish but then logically relate "IT competency" and "business competency".
The idea that IT might "improve competency" is probably an unhelpful contraction of what should really be stated: "IT support of improvement in business competency." This way we initially (and properly) focus on how business competency is recognized, and then on how those terms translate into (business) requirements that IT can help to meet. To complete the thought process carefully, we finally describe how those business requirements compare to the model of IT activity in the business, and concentrate on aligning the IT model with the business requirements, so that IT's position has the "right needs" defined for decomposition into IT requirements.
Some may say, "but what about e-business?"
E-business, in the form of end-consumers using IT to directly interact with the business, puts more business pressure on the performance management of the IT infrastructure, but it does not fundamentally change the relationship of IT competency to business competency.
Instead, what is brought into high relief by ongoing e-business is the business's ability to position the IT infrastructure in a more valuable sustained position for consumers (business capability), along with the IT organization's ability to comprehensively support information process (IT capability).
However, the transformation from pre-e-business to post-e-business was a crucial demonstration of business competency in the marketplace, and the accompanying management reengineering of IT practice to incorporate the e-business needs is a parallel demonstration of IT competency.
How do we recognize the position of infrastructure, information and innovation in the realm of business competency?
As a baseline:
- Infrastructure calls on Architecture;
- Information calls on Predictive Analytics;
- Innovation calls on Prototyping.
These three disiplines share the common objective of designing operations for optimizing the two-way relationship of change to demand -- the two factors most critical to business survival.
Architecture, predictive analytics and prototyping all recognize change and demand as independent factors. Then they all attempt to identify the ways that change and demand affect each other -- and thereafter they provide direction (requirements) to the development and use of capability -- for meeting needs dictated by the influence (i.e., opportunities and risks) of the change-demand relationship.
Posted by Malcolm Ryder at 7:47 AM | Comments (0) | TrackBack