June 27, 2010
The Tao of "New"
Back in April of 2007, Optimize Magazine ran an article by M.S. Krishnan titled Moving Beyond Alignment. Its summary: strategic business innovation requires a flexible infrastructure so that the company can utilize the business models needed to achieve goals. Thus IT governance and architecture must enable the enterprise to "synchronize with changes in the business environment".
Meanwhile, scheduled for late 2010, the book from strategic technology architects Greg Suddreth and Whynde Melaragno called The Path to Real Business Transformation discusses "dynamic synchronization... a rigorous, business-case-driven collaboration between the business-process owners and their IT counterparts." For this, the framework of problem-solving is what they call business architecture.
"Innovation" always has an aura that suggests the big moment of arrival of the new. But getting to utilize the new is the only way that value is derived from innovation, and utilization requires integration into, and synchronization of, the operational scheme of things. This emphasis on synchronization firmly declares that the problem of follow-through on business strategy is fundamentally about coordinating the moving parts.
Anyone who has tried to manually shift gears in a moving vehicle knows that synchronization has two operator-controlled aspects: time spent in the gear, and timing of gear changes. In a competitive context, where time and timing are pre-planned and managed for variances and circumstantial adjustments, this plan is even seen as a strategy itself. The performance level of the plan's execution, especially in complex or volatile environments, is then most often seen as "agility". Achieving agility is, for that reason, a common business objective related to scoring business goals.
Suddreth and Melaragno further state that "business architecture" is developed through a process that defines and institutes long-term change within a framework of strategy (for example of goals, related positions and directions), planning (for example, of resources), and execution (for example, of services). They go on to point out that multiple business areas must be complementary in the context of solving a defined business problem.
To assure proper pursuit of that agreement, it becomes necessary to appreciate the difference between innovative business uses of IT versus business use of innovative IT.
- In the former case, the emphasis is on the business-level understanding of how moving parts might be aligned in a new way.
- In the latter, the point is to introduce moving parts that have a different set of characteristics and interactions than those typically tried before.
From the point of view of these authors, the former issue is a concern of business architecture; and the latter issue is a concern of IT architecture, in which (among other things) the business architecture is "physicalized" according to Suddreth and Melaragno.
Given those points above, it would seem that the challenge is to prioritize business innovation, then leverage business architecture to identify and incorporate IT innovation that can be scheduled within IT architecture for a reasonable chance of sustained synchronization.
Posted by Malcolm Ryder at 9:36 PM
June 22, 2010
Social Networking
Leadership effectiveness requires followership.
Following requires accepting an extrinsic agenda.
Acceptance requires accomodating the agenda within a disposition.
The disposition is a point of view from within a network of influences.
Change management must generate a disposition favorable to leadership.
It is said, "Individuals do not evolve; individuals change, and populations evolve."
Posted by Malcolm Ryder at 10:51 PM
May 24, 2010
Discovering Leadership
Acuity may be the explanation for how leaders emerge from the complexity of ongoing operations. We expect leaders to be able to navigate; but often, after the goal-setting that dictates what should be IN the participants' points of view, the remainder of the task is largely delegated -- and this creates the risk and problem of losing awareness of what is AT the points of view. On the other hand, the successful navigator may acquire the leadership, gathering the role and position around them as they are found repeatedly, by others, at the right place at the right time -- a trick attributable to acuity.
Mythical leaders are most often soloists, but the complexity of modern organizations means that leadership teams are the rational way to assure that goals and navigation are not disconnected from each other. The purpose of the team is not to forsee the future, but to develop 20/40 vision of the present. Delegation into teams is a collaborative strategy that provides the bandwidth of attention to find the track to the goal and stay on it. And like all lines, the track is a collection of key points.
Image and full article Copyright 2009 Malcolm Ryder / Archestra
The track from current benefits to future benefits can be seen as a passage through various gates. Generally, four gates are along the way.
At the first gate, current pains are felt as a tradeoff accepted to sustain the currrent benefits. Because their impact extends beyond their causes and justifications, pains may become excessive and trigger a decision to find a substantial remediation, the second gate. This research for a course of action, usually fueled by analysis, will separate remedial action options into those that are mandatory and those that are not. With the weight of "necessity", these decisions or change mandates -- the third gate -- will drive determination of priorities going forward; and those priorities -- the fourth gate -- will in effect set the grounds and boundaries from which future benefits can develop.
For this pathway, it's often the case that leadership must reverse-engineer the course, finding and aligning the appropriate set of conditions at each gate. In this effort, acuity is paramount to determining if these conditions do, or can, exist.
Said differently, the gates in this route are practical checkpoints in the assessment of an organization that presumes to form itself around the leadership and follow.
- Priorities correspond to culture. Culture is the primary factor constraining future benefits.
- The requirement for changes that precede the culture corresponds to politics that, understood objectively, is the negotiations about the balance of risks between stability (quality) and progress (advantage). But it must be understood that because requirements are decisions, all needs are not necessarily requirements.
- Preceding the change requirements, administration moderates a competition for attention to needs;
- and administrative transparency may be critical to allowing the environment of operations to present its true current pains.
Building forward again, those issues can manifest on familiar management terms -- for example, terms such as quality, resourcing, policy, and governance. Other terms may similarly and respectively apply
But the more interesting aspect is this: the necessary ability to identify the path to future benefits within an existing organization suggests that from the perspective of the participating organization, real leadership may have to be discovered more than to be supplied.
Posted by Malcolm Ryder at 8:34 PM | Comments (0)
May 23, 2010
The Seven Ways that People Don't Listen
We know that strategy is essentially a proposal. All strategy says, "Let's try it this way..." -- or it says nothing at all.
But one of the most understated things about strategy is that it is more a response than it is anything else. The value of a strategy is not primarily in the impact that it ultimately has. Instead, a strategy takes its basic value from the problem that it wants to solve. In most instances, if the problem is very important, then the strategy that responds to it will be important.
However, what many people, including practitioners, fail to attend to is that a strategy's being important does not cause the strategy to be a good one, nor does it prevent the strategy from being a bad one.
That fact is why the quality of the strategy must have high priority, and why making strategy must prevail over the culture of execution. In too many cases, practitioners trip over another conceptual stumbling block, which is that execution does not make an important strategy good. Instead, a good strategy enables execution to be effective.
The most prominent dimensions of a good strategy are the following:
- Relevance
- Logic
- Credibility
- Visibility
- Urgency
- Distinction
- Change
What practitioners may discover, to varying degrees of surprise, is that the list above is a good predicter of whether execution is likely to result in effective outcomes. Even more importantly, they may discover the reasons why an existing strategy may be unusable or failing. In general, any point in the list makes sense only if the point preceding it is in good stead.
The overall single reason why a strategy may be structurally predisposed to fail is that the chain of dependencies inherent in the above list can be broken at any point by a failure of stakeholders to "buy in" at that point. What is even more surprising to presenters of strategies is that such "buy in" failures are not due nearly so often to rejection as they are to indifference.
The cult of execution holds that indifference can be pushed out of the equation by performance incentives. This poses the situation that a key participant need not worry about why assignments matter if they are well rewarded for being carried out successfully. These "rewarding" outputs are then advertised as "priorities", and managers are deployed to enforce priorities and to maintain a balance of their alignment amongst the complexity of their concurrent demands. This is exactly why metrics dominate management. Management then tends towards the idea of "best practices" -- the patterns associated with manageable high performance. But this is fundamentally different from strategy.
Let's turn back to the essentials of strategy and look at how indifference first appears. The most important notes to make are about why people decide to not buy in -- which takes place mainly by their choosing to not listen. As opposed to merely hearing, listening requires that the person absorb, interpret and represent the offered idea in their own mind. This is not the same thing as acceptance; instead it is the same as "realization", which for that person allows the idea to become the basis of their follow-on action. Otherwise the strategy remains an external fiction: someone else's story. In noting this, we also have to remember that typically, with strategy, exposure is not a universal experience. Different people need to listen at one or more different points in the chain of dependency:
- Relevance: how do we know that the problem being tackled is the right one? This may start out with identifying what the problem is really pointing at -- namely, a need. The primary needs are innovation (evolution), preservation (growth and health), and recovery (healing).
- Logic: what plausible mechanism is readily apparent to address the need given the most plausible disruptive risks or inhibitors to that mechanism?
- Credibility: who is the source, and presenter, of the case for the need and the logic? What is the agenda of that source?
- Visibility: what modes of validation-on-demand are available for the participants approached with the presumed relevance, logic and credibility?
- Urgency: why is the opportunity for the presumably required effort (not the desired outcome) more available now than it is later?
- Distinction: what is it about doing this with the designated parties that makes the effort as likely to succeed as competing strategies?
- Change: how do I know I will wind up better off than I am now?
Experience shows that strategies are often undermined or aborted due to such things as competing ideas, turf wars, and under-resourcing. That is, that actual design of operations indicated by the strategy cannot be fully completed, communicated, and subscribed. This general picture of resistance or disconnect suggests the scope of challenges to any strategy. But the picture should be much more specific; and again the matter is not so much one of rejection as it is a failure of the strategy's proposition to overcome the inertia of the present.
Given the specific dimensions listed above, here are the associated ways that people are predisposed to not listen. The idea that a strategy has high quality is all about the way that the strategy predictively addresses these issues:
- Relevance: not aware of this need's primacy over other possible or identifiable needs
- Logic: don't understand the mechanism
- Credibility: lack of trust
- Visibility: limitation of information access
- Urgency: risk to current commitments
- Distinction: appearance of being excluded
- Change: fear of loss
Given those issues, it is apparent that the most important things to materialize for substantiating the strategy at the participant level are models, education and proof -- none of which are the domain or responsibility of execution.
Without end-to-end substantiation, the interdependencies within the proposed strategy are not integrated, and this in turn means that the organization available to execute the strategy is either missing, logically misaligned or inherently deficient -- in other words, the engineering of the strategy is suffering from classic flaws of omission, errors or defects.
The pressure on managers and executives to deliver "performance" can often provoke them to "re-organize" somewhat ruthlessly as a way to "enable" a strategy. This is not uncommon as a business practice, and none of the above argument is intended to claim that it should or should not be done. Instead, the takeaway from the above is more importantly an awareness that aggressive management is not a substitute for actual strategy, and that the purpose of strategy is to create a basis for effectiveness, not to to create results.
Strategy designs operations; execution conducts them. As a further caution, it must be pointed out as well, though, that strategy is not static; as it is fundamentally responsive and is a design discipline, strategy must be dynamic and itself must be managed for real-time quality -- an ongoing process, not just a product.
Posted by Malcolm Ryder at 9:20 AM | Comments (0) | TrackBack
August 13, 2009
Why Business Processes drive Customization... and what to do about it
Customization of business processes means that there is more "precision" in the targeted effort to succeed. But in situations where support may not be up to speed and where targets may change, this precision comes at a high cost of achieving readiness and warding off eventual irrelevance, making it just as risky as it may be attractive.
The general sense of "customization" compares against three basic options for the formations of a business process.
Option 1: One-Size-Fits-All
For business processes, this is a myth, because “business” is primarily about accommodating multiple relationships and requirements, not primarily about manufacturing a standard product. The “process” must support what business “is about”. Relationships tend to be privileged, not indifferently available.
Option 2: Specialization
Sometimes incorrectly called “customization”, specialization is different: it means variations on a single theme. The theme has standard requirements; the fulfillment is where the variety occurs.
Option 3: Customization
Customization begins in the requirements, not in the fulfillment of them.
There are three reasons why requirements may be “custom”:
- Cost structures
- Competitive Innovation
- Capability Immaturity
Three reasons why requirements may be custom, not generic.
Cost Structures:
- Satisfying customers is not profitable if it is too expensive; different organizations (different suppliers, and different consumers) have different cashflows
Competitive Innovation:
- Existing customers, to decide to stick around, need to feel that the relationship is fresh and current
- Potential customers need a reason to prefer one provider over another
Capability Immaturity:
- The time available to use for improving capability may not be in synch (priority, availability) with other resources
Three reasons why requirements may be "custom", explained.
Cost Structures:
- Lack of visibility on true economic impacts puts operations on a risk-aversion basis seen in typical micro-management approches
Competitive Innovation:
- High rate of change is necessary to sustain improvisations that generate necessary nw effects or advantages
Capability Immaturity:
- Required performance level outstrips currently available supporting mechanisms, forcing risky workarounds.
How to mitigate or avoid customization.
Micro-management:
- An operational performance model allows activity to be prioritized and weighed by differential contribution to goals and thus by ROI perspective. (For example, the 80/20 rule.) Relieves pressure to dwell on the microscopic. Define objectives, CSFs and KPIs. Switch to “trust-and-verify” mode.
Improvisations:
- Linking process models to knowledge management allows standardized roles to be able to move quickly and differently on incoming information, without re-organizations.
Workarounds:
- Organizing around known best practices clarifies ways to structurally reduce risk and to more rationally divide the labor required to meet performance targets. Such greater clarity allows managers to make the compelling business case for additional help to cover properly allocated responsibilities.
When to Customize.
Considering the above notes, executives should still project the likely value of customizations. The punchline is that it cannot be taken for granted that customization is the best path to take, neither in the short run nor the long. Customization proposals that withstand comparison to the above considerations should be given even more enthusiasm than usual, as they probably then point at nearly unique opportunities to do something strategically important to the business.
Posted by Malcolm Ryder at 10:37 AM
March 8, 2009
Networking Social Behaviors
With the help of the McKinsey gang, important thinkers such as Soumitra Dutta and Matthew Fraser of INSEAD are hosting discussions about how the internet and the recession might collide. Their angle: "When Job Seekers Invade Facebook". In their conversation starter, Facebook is offered as a venue that has its own culture, now threatened with an alien influence that could change the nature of social networking.
This is a somewhat romantic notion, best held by facebook's marketing and legal teams but not a plausible or fact-based reality. The concern wouldn't be how social networks behave; rather, it would be how social behaviors are networked.
Interestingly, it brings up the question of how much a given tool can control its users, versus how much design can flex to assure that the tool is fit to its purpose. What's not clear is that there is any cultural "end state" of facebook that represents its purpose. Instead, both on the surface and in theory, facebook is one of multiple grand collaborative experiments to discover what social "connectivity" really includes, with social propriety being a necessary but secondary concern. This experimentation seems likely to show ongoing morphing in what we see being social networking, but it hardly seems likely that a horde of unemployed invaders at one site will change social networking into something it is not already.
The dominant feature of the most popular social networking tools is that they are gateways to fundamentally public environments where privacy policy controls get applied. But the trick is that the policy applications are done based on personal preferences, and the personal preferences reflect many different cultures. It is unlikely that any one culture actually governs a social network unless the network's environment is administered according to some dominant policy model that proxies a culture. The default condition is that public spaces (like facebook) are polycultural, and that the less polycultural the space is made, the more constitutionally private it becomes -- just like a club. Punchline: unless internet economics eliminate the chance for more new "price"-free gateways, it is not social networking that will change, but instead the variety of social network venues.
There is some counter-thought to this that insists on some "critical mass" of members for a social network to be seen as useful -- and therefore in some Darwinian way likely to survive. This presupposes that the "natural" limit on the number of networks is a small number, since most networks won't offer enough richness to be worth the troulble. But I think this oversimplifies things by assuming (arbitrarily) that the "richness" (value) of a member of the network must be measured by the interconnections within that network. Real life shows that assumption to be silly; incredibly valuable people join and use networks on a very limited basis all the time; and, some small networks can be incredibly powerful, like the smoke filled back rooms of old. We'll remember that these smaller ones tend to be more private.
Rather, some members who are not "rich" when they join public networks have the ambition that they can achieve some richness within the network. That is precisely the current sex appeal of the term "networking", as used for painting in broad strokes; well, fine, as long as we don't pretend that social networking is actually hostage to any network.
Posted by Malcolm Ryder at 9:07 AM
February 23, 2009
Federation, Synchronization and Consolidation in I.T. -- a lot, but not enough.
Anyone who has done systems research or done the care and feeding of systems is familiar with the idea that a system is often made up of sub-systems -- for example the way that the human body is composed, or a good old-fashioned hi-fi stereo component hookup, or compounds made of molecules made of atoms. One of the key things to consider in managing the higher-level systems is that their sub-systems are indeed complete systems themselves and have their own internal complexities of components.
"CIs" are things that are similar to the above, in that a higher-level CI such as a "service" may be composed of other "sub"-services having, in turn, their own constituent services -- but this is why in the conversations about "CIs" in many companies, confusion develops amongst the terms "service", "system", and "component". Questions and even arguments follow this confusion, such as "when is a system a CI? Are all services CIs? Do components combine to make CIs? Do CIs combine to make other CIs?" This puts an end to the usefulness of speaking roughly.
So instead, if we take the term "Configuration Item" and break it down without regard to its actual linguistic history, we should think freshly: the term "configuration" means something on its own -- i.e., a certain arrangement of selected parts -- and the term "item" represents something involved in a configuration -- namely, a part. Any construction has a configuration, and the parts in the configuration are items. This conceptual abstraction is still easy language, and it completely covers the aspect of drilling down into one thing to find, among its parts, other things that each can likewise be decomposed. What follows below intends to apply such consistency across old terminologies as well.
For our purposes of discussion, the key construction is going to be some service that we want to have. As we'll see in the illustration here, there is an important and consistent way to discuss what is found in the drill-down on a service. Generally, we drill down onto two different kinds of resources for the service. On the one hand, sub-sections of a construction are what should be known as "components". On the other hand, the materials that are used to make up the subsection are what should be known as "elements". Like fire, earth, air and water, there are different kinds of elements; they combine to make up components that can be sub-sections of constructions, including of course constructions that have only one logical subsection: the unit whole. Logically, this is always true regardless of what particular construction is developed. But now, to address an earlier question, when is a construction a "CI"? And the answer is, a CI is not a thing; it is a management perspective on a thing. This thing might be an item or a configuration. What makes the thing a CI is management's attention to its role as an "element" of a service.
Now, when the main construction will be provided for use as a "service", and we are talking about the "components" of the service, we are referring to the configurations within the service. Remember that the essence of a "service" is in that it is something being provided for use in a given way; the type and complexity of a thing does not define it as being a service. However, logically, the components in the management view are the actual "instances" of whatever type of CI, since the instances are what the service user is actually reliant on.
Remember also that the configurations within the service are constructions themselves. What we must recognize is that for a construction seen at a "top" or "parent" level, the involved configurations have elements; but at a lower "child" level, those elements of the parent may be constructions for the child. In this way we see the drill-down through a structural hierarchy based on a recurring logic. For pragmatic reasons, organizations increasingly adopt names for the different levels, such as "Business" (parent), "IT" (child), and "Systems" (grandchild). By this logic, systems configurations become items for (i.e., elements of) IT configurations, and IT configurations become items for business configurations. Meanwhile, "services" may occur at any level, because what defines a service is how something is provided, not what something is.
What is more interesting, then, in this whole thing is not so much the parts (items) themselves but the relationships that become the structural arrangement (or actual configuration) within the construction provided as a service.
In a management scenario, relationships become important mainly because, not surprisingly, they make the configuration manageable. This intent immediately makes some relationships more important than others depending on the perspective of the particular manager. And most interestingly, it throws attention on items (parts)that are not "equipment" such as hardware and software, but instead are "instruments" such as supervisory people, or regulatory documents -- indeed, any influential entity that can be logically assigned (i.e., related) as an enabling part in the ongoing functionality of the construction.
Now, since one of management's primary concerns is to establish and maintain the appropriateness to task of whatever is being managed, then another large focus of management is configurability. To throw quality control into configurability, there is initially the aspect of design, and quickly thereafter the matter of change-control.
The design side of things calls for specifications, which basically are descriptions of the particular configuration and/or item that is intended to be realized. With design and specifications, many instances of the same type of thing should be possible to produce with sufficient similarity to make the instances interchangeable if necessary, but all of the instances would be examples of a specific and unique version of a specific and unique model.
The value of specification is in its precision, which allows managers and users to have confidence that they have their hands on exactly what they need. The specification may point out that there are characteristics of a configuration that are produced or contributed by supplier X while other characteristics are given by supplier Y.
Keeping a central library of trusted configuration descriptions is the idea that gave birth to the Configuration Management DataBase or CMDB. In a CMDB, it is usually the case that configuration characteristics are identified as parts meeting specifications called "attributes". It stands to reason that a CMDB needs to gather reliable data from multiple suppliers responsible for the attributes of any of the configurations on record. The problem of managing the CMDB itself, then, is no different from keeping any complex database in good shape. If anything, the degree of confidence that the CMDB users want in its data makes the complexity that much harder to cope with.
Centralization of the data is the easy way to describe the strategy for meeting the goal of a highly-reliable CMDB. To really appreciate what this means, it is necessary to understand "centralization" in three tactical ways that reflect and resolve the CMDB's complexity:
- federation,
- synchronization, and...
- consolidation.
Federation refers to the multiple donors of trusted information working in a co-operative manner so that they do not fail to contribute the right thing by the right time. As teammates, they need to all be on the playing field together when the play is about to be run.
Synchronization refers to the possibility that more than one party knows about the same thing, but they know it and talk about it in dissimilar ways. In this case, if one of them is more up to date in its knowledge than is the the other one, the other needs to get up to date in the terms that it uses to refer to the same thing. This paralleling, in which if A=B and B=C then A=C, calls for some mechanism that can assure the parties' two different terms (A and C) can again represent each other correctly in the same moment.
Consolidation refers to the case where multiple terms that refer to the same thing are reduced to one term which becomes the singular preferred referent, making the redundant others unnecessary.
Ideally, any configuration in a CMDB is an instance of some single type that is a successful consolidation of descriptions. Each unique type can have, theoretically, an unlimited number of instances.
In typical implementations, a CMDB may or may not be federated, since the CMDB might be held responsible for only certain types of configurations that could be confidently composed and described without multiple suppliers. Federation, always a possibility, is usually more the exception than the rule.
Synchronization is initially an issue when the first decisions are being made about which data sources are the ones that should be considered authoritative. If there are already multiple systems recording descriptions of the same thing, they probably need to be checked against each other to see how well they match, before either one is chosen over the other. This will be most useful when CIs are being initially defined for inclusion in the CMDB, since there is no point in recording a CI unless there is a trusted mechanism for keeping the record up to date.
As the above issues go, things tend to resolve in a way that there is not much discussion about federation, synchronization or consolidation (!) -- however, a different term is constantly used and rules the roost: reconciliation.
Reconciliation refers to the need to take recent validated discoveries about the characteristics of actual instances of configurations, and compare the findings to the record about those configurations as found in the CMDB. Updating the CMDB records means that the recorded versus discovered information must be checked, with mismatches resolved through a manager's decision about whether to change the CMDB record or change the actual configuration instance. Because a CMDB is not trusted unless it is known to be up-to-date in its authority, reconciliation is a critical success factor for the CMDB utilization. However, in a little recognized nuance, "reconciliation" is often mis-applied to the effort to remain up-to-date.
To appreciate this nuance, consider that two parties start out disagreeing, but they wind up agreeing with each other in the end. This would be reconciliation. However, if the two parties cannot agree with each other, and a third party is required to make the decision for both of them, then the original two parties (still disagreeing) did not have a reconciliation but instead an arbitration. An important thing to note here is that an arbitration effort can always come up with the same results that a reconciliation can, but a reconciliation effort cannot always come up with the results that an arbitration can.
It is often the case that I.T. managers rely on a mix of tools providing highly reliable feedback each in its own terms. This sets up the important necessity for arbitration to the degree that the tools do not share a common descriptive dictionary. Arbitration rules enforce "tiebreakers" and properly dispose of exceptions; this clears the way for consolidation of information within the CI record.and brings the CMDB closer to the capability that management really wants the CMDB to support -- risk avoidance in decisions, under the pressure of Quality of Service expectations.
Posted by Malcolm Ryder at 4:17 PM
February 16, 2009
Consent and Dissent: the Decision Gate
In the four key scenarios, the decision-maker reacts to a suggested change in different ways. Meanwhile, there is no guarantee that, at the end of the path, acceptance will be reached. The change-presenter must determine which paths need to be navigated, and what sequence is called for. With that, the suggested change that is input to their decisioning may finally be output as an agreement.
- The idea of change that is being presented may in effect test the decision-maker's current level of acceptance. This is mostly like marketing for the purpose of highlighting a match between what both parties prefer. Messaging would be important here.
- More challenging than that, for the decision-maker, is being caught by surprise when the suggested change provokes some new or latent realization (discovery) that must be considered. Education would be important here.
- The third possibility is that an already acknowledged option is presented with higher priority, based on the attractiveness of its expected impacts. For the most part, selling is useful here, insofar as it emphasizes and offers the new availability of favorable future positions for the decision-maker.
- If the suggested change is not conceptually new to the decision-maker, but has not previously been acknowledged as an option, then the situation is most likely to initially be about considering trade-offs between the proposition and any personal alternatives believed to exist. Analysis would be important here.
Described more tersely, the factors that "gate" a decision include identity, knowledge, future value, and opportunity cost. Taking those factors as elements of a campaign, and orchestrating them to work with each other, the change-presenter can strategically and proactively design the presentation to the necessary audiences.
Posted by Malcolm Ryder at 8:44 AM
August 16, 2008
Why Leading Thinkers Won't Be Thought Leaders
In the ideas game, cutting edge thinkers are typically too far ahead of the approval criteria for implementers, and since "thought leaders" derive their credibility from the probability of implementations occurring, most leading thinkers don't become thought leaders.
To get probability on their side, leading thinkers usually have to choose to think about something that approvers already want to implement.
This certainly distresses the notion of "innovation", except within the sense of "infusing the accepted with newness". But that is not an outright knock on anything; it simply points to a reason for having the notion of "pragmatic innovation".
Much leading thought throughout history has been pretty rapidly dismissed as "impractical", which of course should have meant "unable to be put into practice"... But with 20/20 hindsight we are able to know at least that what is undoable for one outfit is merely inconvenient for another. And yet another may have no resistance to the idea at all and let it rip, wherefore the popular "disruptiveness" tag in the vocabulary of the betting pundits who track ersatz innovators.
Thought leadership is safe. It doesn't carry along with it the stockades, burnings-at-the-stake, smear campaigns, or other proven techniques used to enlighten leading thinkers about their impracticality. In fact, when you get right down to it, thought leaders are "voted into office", more or less like successful consultants, which means that they are the product of followers, not vice versa. This explains why the best-known thought leaders hardly ever have a hardluck story about finding followers...
In the other camp, leading thinkers sprout of their own accord and may carry on for quite some time with no followers at all. Some leading thinkers get lucky: they wind up being befriended either by a thought leader or by an influential producer who can spell "pragmatic" but isn't worried about it for the time being. But conventionally, the bridge between leading thinkers and thought leaders is the kind of engineering called "R&D".
The problem is that if R&D is not funded well enough, then the bridge may not reach all the way across. So the issue mainly comes down to who will sponsor the way that the R&D is adequately funded.
Leading thinkers really are often into fundraising, but a lot of fundraisers aren't any good at it. In a healthy organization that wants to be progressive as well, the case for funding thought leaders is not so hard to make, but the exceptional organization strategizes funding of its leading thinkers.
Posted by Malcolm Ryder at 9:28 AM
April 19, 2008
The Innovator's Real Dilemma
Jessica Stillman at the new BNET1 blog rounds up research from Accenture, the Conference Board, and Wharton to talk about why Fostering Innovation Stumps Executives ...
This is an interesting situation to ponder: making choices about how much to invest in innovation , versus in knowledge management and, separately, business intelligence as other paths to insight. Overall, what the organization is mainly after -- where the real money rests -- is the insight, whatever the path. But the current thinking about management priorities indicates that insight is pretty hard to come by, so lesser-beaten paths to it are also getting a lot of attention.
One challenge that surfaces, somewhat amusingly, is the presumed need to be innovative about how to foster innovation. For example, given that "innovation" is so easily approached as "creativity", it is not surprising that at places where real urgency comes from competition against either industry rivals or the budget, the idea of stimulating the worker's right brain with art experiences can gain some real traction.
But perhaps everything new is old again... The simplest way to assure that innovation is "fostered" is to provide
(1.) a clear statement of why the company will consider something to be "innovative" and...
(2.) a clear statement about what circumstances will cause the innovation to be rewarded in a way that directly benefits the individual(s) involved.
Generally, if company leadership can't get that much communication together and abide by it, then most other "fostering" efforts are essentially arbitrary.
Furthermore, this effort should not be confused at all with management's concern about how to measure the innovation's impact on the company's performance. The performance impact issue is not something that should be making innovation special. Any management team that rewards "performance impacts" with bonuses should simply add innovations to the mix of things that can be clearly accounted for as contributors to better performance. Meanwhile, innovation is about doing things differently to create opportunity; but execution is about doing things a certain way to hit performance targets.
This is where managers have to get real: if they will not reward innovators for being innovative, as opposed to making the reward conditional upon performance increases, then people will learn that innovation is not worth the effort at this organization. So in step (2.) above, the "circumstances" to be declared must start with something other than performance metrics.
Posted by Malcolm Ryder at 8:42 AM
March 30, 2008
Careful What You Ask For...
Anyone who has visited Archestra more than once ( all nine people! ...well, ok, eight not couting myself) knows that a major point getting made is this: what looks like problems without solutions is often due to the romantic allegiance we have to a misleading vocabulary.
It's especially important to catch those times when strategy, management, execution, and other fundamentals are being wrestled by name. In that vein, one of the longest-standing friends of Archestra -- Bruce MacEwen at Adam Smith, Esquire -- caught the notice (again) of a somewhat newer friend -- Jack Vinson at Knowledge Jolt -- setting the stage for the commentary now here.
Bruce starts it off by reviewing ideas in the The Halo Effect, by Phil Rosenzweig. Rosenweig explores the historical ineffectiveness of management guru wisdom, and Bruce shortly comes to his own punchline: "In this unknowable world, what attitude and what approach grace us with the best odds of success? Only one: Critical thinking."
But as you read Bruce's fluid argument to the conclusion, you pass through the equally important question in his theme: "What do you have to know, to be the best performer?"
Jack, a seasoned spokesman for the Theory of Constraints (TOC), embraces Bruce's conclusion; but moreso he picks up that earlier question with his own followup, posing a perhaps ironic counterargument to Bruce's conclusion. With no pretense of being gurus, both men argue for the value of logic to management that would aspire to the top rung of performance. But Jack shines a light in the dark corner of logic's chronic problem with gaining broad acceptance. Case in point: Jack's observation that TOC works but still doesn't proliferate poses this question: "What does it take to get chosen as the management approach?" And our question, naturally, becomes "if you aren't chosen, then how can you be the key to success?"
Evidently, what it takes to be chosen is a combination of marketing and politics -- and the facts may be that the underlying genius of "success" is not the management approach used but instead the competitive approach employed by the executives. What Jack points out, intentionally or not, is beautifully brutal: that sometimes things work and sometimes they don't. And we must remember that winning ugly is still...winning. TOC companies may be winners, but most winners don't use TOC. (True, or false? Jack suggests, True.)
Consequently, when it comes to competition, we can't be sure that a great lot of companies should do anything in common; but instead we have to focus on why something works for the company that it works for.
In other words, there is a glaring difference between strategic management and competitive strategy, with the better competitors doing most of the winning, not foremost the better managed.
What executives must be responsible for is figuring out what strategy their company can win with; and what managers must do is figure out whether the company is doing what that appropriate competitive strategy calls for.
As both Bruce and Jack assert, critical thinking ought to be a key tool, and here we assert that it is a key tool in both competition and management. But what overrides both circumstances is the possibility that the thinking will be done about the wrong thing.
Eschewing mythologies and the emperor's new clothes, Jack quotes Bruce's counsel against that problem : "rigorous and unblinking analysis of reality as it is, not as you want it to be..." What we must take this to mean is not that some approach is inherently more competitively clairvoyant than another, but instead that executives and managers must not run the company based on a mythology (of an approach) that does not fit the company. To puncture the mythology, you have to be able to cut through the marketing and politics that surround it within the company.
New punchlines: as the top person in charge, you can't know what strategy will be your most successful against the competition before you know your organization; and when you reach an understanding of what your organization can do, you then have to either select a strategy that fits the organization, or you have to change your organization to fit a different strategy. What's tough is that you have to do this while the game is already underway.
Posted by Malcolm Ryder at 1:53 PM
March 23, 2008
Suddenly, It All Made Sense
Finally, that track that everything went off of, and where to get back on.
For the hi-res view, click here and go full screen or print.
Posted by Malcolm Ryder at 6:42 PM | Comments (0) | TrackBack
March 18, 2008
The End of Irrational Execution
Faisal Hoque, Chairman of BTM, appeared in Baseline Magazine with a brief discussion on the three elements needed for "Transformation: Inertia to Agility" (BTM innovates new business models and enhances financial performance by converging business and technology.)
As usual, Faisal offers a wonderful summation of what levers to throw and why to throw them. Here, he observes innovation, efficiency and abandonment.
Sound familiar? Perhaps the most interesting aspect of his article's proof point -- Amazon -- is that it shows how far we have recovered from the dot com era assumptions, particularly when it comes to understanding that in a business we actually have to get paid for making people happy. What Hoque really pins down, though, like a refreshed road marker, is that the "making" part is not the business, but is instead the competency.
Amongst the problems in the mix, the inertia that Faisal details is arguably the description of how business frustrates competency (“We have to meet this quarter’s numbers or we’re toast.” ), while on the other side of the coin Hoque highlights how competency, through enterprise architecture, can drive a business ("the first step is to get a clear picture of the entire enterprise...").
Meanwhile, that flashback we easily have on older preached wisdom like "Fail Faster!" and "Destroy Creatively!" still seems to apply, but the difference is that we have actual history on that now. The history begs the question, "why are only the exceptions successful?" Hoque's answer looks to be a turnaround on the old saying "If you don't know where you're going, it doesn't matter how you get there..." The turnaround is, "If you don't know how to get there, it doesn't matter where you're going." But we can't make the mistake of joining the casual crowd exuberance for "execution": the point is that enterprise architecture is the competency enabler that then delivers execution for the business.
Posted by Malcolm Ryder at 9:01 AM | Comments (0) | TrackBack
November 8, 2007
Knowledge Workers : the wisdom of the Crowd?
No great company can expect to compete without a great stockpile of knowledge and, therefore, knowledge workers. Question: the more k-workers, the merrier, right? Answer: it depends.
The concept of the "knowledge-driven organization" is the strategic rallying flag for businesses bred amongst the Information Society. But that enthusiasm doesn't automatically translate from ambition to reality. Faced with the pressure of quarterly earnings reports, many companies can't decide whether the daunting task of becoming knowledge-driven is a "do" or a "die".
Yet most career hierarchies in an organization -- a.k.a., "success" ladders -- are marketed with the idea of "demonstrated expertise." This ought to mean that careers are the channel by which organizations actually apply the knowledge in residence. In turn, that ought to mean that organizations are already inherently knowledge-driven. If that's the case, today's idea of knowledge management being something new must indicate something that has heretofore been missing. So where's the gap, and why?
The reality is, careers are fundamentally about influence, not knowledge; and most careers are promoted on the basis of power; and typically the power is manifest in "productivity", not "skill", and productivity is measured in outputs, not inputs. Just as athleticism gets you on the team but not necessarily off the bench, for most players the primary key is to fit into a prescribed position -- which translates into measurable productivity good or bad. And as the authors of Mass Career Customization (Harvard Business School Press) describe it, the positions that typically matter in an organization's career tracks are management. Net: when it comes to career success in the organization, the way management itself is prescribed or defined will generally trump knowledge. This puts knowledge workers in the position of needing a strategy to make management repeatedly buy into their knowledge.
Cathleen Benko and Anne Weisberg, two executives of Deloitte, hit the issue from two directions in their book. One direction looks right at productivity through the lens of performance results associated with female executives. The distinctively superior results that the authors find there inspire the question of which female qualities are so naturally more productive. The implication is that innate qualities of women produce higher performance in the corporate ladder. But what evidence of these qualities makes the qualities explicit? Why would these same qualities generally drive corporate success, and can men practice them too?
At this point it's worth pointing out that most careers, really, are built on making one's decisions agreeable, not on intellectual athleticism -- but then again only smart women seem to have big corporate careers. The classic dilemma of these smart women has been, how smart is it to have a life outside of the company if we want a strong career inside the company?
Benko and Weisberg's discussion gives some answers to that, but it still leaves us (intentionally) with the idea that even for those workers with these better female qualities (one notable mention is about "multitasking" as a woman's talent) a corporate ladder is hostile territory, whereas a new and trademarked model -- a lattice -- will promote and keep more women (and likewise men) in a profile that drives business performance. Mass Career Customization (MCC) offers a way to make the important "career" qualities explicit and "tunable" like the different ranges of a graphical sound equalizer. The trick is to get the company to accept these tunings, or profiles, and the book is largely an explanation of how and why the company should.
The issue of knowledgeworkers intersecting organizational structure is the very singular topic of the Benko-Weisberg book. The issue amounts to more than one thing, but the most consistent thing it amounts to is a view of organizational structure managing knowledge workers as assets. One major reference used by the authors is (click here if you want it) the Deloitte Enterprise Value Matrix, and the book's major offering -- MCC and an alternative to the corporate ladder -- is given an ROI argument by being presented through a Deloitte-style framework.
A dispassionate reading of the Deloitte matrix reveals it to be an internal pipelining of assets from resource cost to strategic investment. But there is a story broader than the corporate boundary, which is the connection between the information society and the knowledge-driven organization, and the ecosystem that it generates around and through the company.
In this story, one plot-line is the following path of assumptions, which amounts to traversing the bottom, middle and top rungs of the ordinary hierarchical corporate model for workers' value:
But while the MCC framework promoted in the book finds an alternative to that pattern for the employee, there's an even bigger message for the company itself to draw from the book. As knowledgeworkers, we like to feel that we're selling our intrinsic value to the company, but companies have their own reasons for buying or not.
The bigger value framework posed by the book Mass Career Customization has terms of measurement different from productivity and from the Deloitte matrix, where the employee must determine how much value the employee can have to the company. Instead, as seen below, the key terms are about how the company can have value in the new ecosystem generated by the Supply of Employees, the Demand for Employees, and how they relate to the Information Society supplying them versus the Knowledge-driven Organization using them.
Posted by Malcolm Ryder at 9:14 PM | Comments (0) | TrackBack
June 18, 2007
How IT Assets come from Business Requirements
After twenty years of developing, managing, marketing and deploying IT, providers still have huge opportunities to miss the mark by giving the customer what the customer asked for instead of what the customer needed.
To see how much can still be missed in any new delivery, check this chart and ask whether the implementations you're familiar with came anywhere near covering what was important.
Key shockers to lookout for:
- Customers didn't know what they needed! How could they always be right?
- Providers weren't solving the right problem! Why would the quality matter?
- Most of all, requirements held no accounting for the difference between risk, complexity and difficulty -- so who knows when anything would actually "work"?
Posted by Malcolm Ryder at 11:35 AM | Comments (0) | TrackBack
March 13, 2007
Fast and Pretty, but not Cheap
Normally you'll find an article here instead of a conventional blog posting, but today Michael Hugos, of CIO Insider, caught my attention with his blog posting about agility on his site, Doing Business In Real Time. It definitely warranted a fast reply of comparative and perhaps contrasting views, reproduced here below. (Be sure also to see his Comment following.)
Very often the agility issue comes up in conversations with managers, and there are two interesting and recurring characteristics when it does.
One, it comes up *after* results have been calculated and posted. That is, managers see what already happened and ask "if we had been more agile, would it have made a difference?"
And two, there is tremendous confusion of agility with other ideas including "flexibility", "resilience", and "versatility".
The one-two punch of being reactive and confused makes "agility" something that remains vaguely ambitious as most managers don't know where to start, on which aspect they are really concerned about, or whether it is the right aspect.
Let's call that the worst case scenario. Hugos' article addresses that by outlining "agility" measurements -- which turn out to be what is largely now identified as Operational Performance Management (OPM) -- great stuff that is not the same as "agility" but is the same as "alignment".
I propose that the agility issue comes in when OPM is a strong practice, allowing targets and their pursuit to change in ways that are (here's the punchline):
- easily operationalized...
- with successful change management...
- to realign on time...
- without breaking things.
There, in a nutshell, you have the four points of reference that allow you to spot why your company is or is not agile. It's a process matter.
As for the 2% to 4% financial improvement that Hugos uses to stand for agility, that's a target, interesting as a representation of what ROI might justify the effort to be agile. But knowing where the target is doesn't tell you how to get there. For most managers, it is not so much that being agile will "cause" the percentage increase; instead, the issue is one of "prerequisities" -- namely, the probability of getting the increase without being agile is so poor.
Posted by Malcolm Ryder at 12:15 PM | Comments (1) | TrackBack
February 28, 2007
Gettting from A to B
Ideas are a dime a dozen; implementations are a million dollars per success.
Is there a "model" that describes the success factors of "implementation" as a practice or methodology?
On the surface, "implementation" typically presumes translating an idea into requirements, specs, and engineering, with a quality (compliance validation) check and delivery effort at the end.
A more sophisticated look will generally include considerations about likely necessary environmental adaptations, so more efforts get included in the form of assessments and monitoring.
So far, the point is that there is a layering of attention that not only manages production but manages change. Are there ony two layers?
In future versions of this article, an Archestra framework for implementation is coming.
Posted by Malcolm Ryder at 7:53 AM | Comments (0) | TrackBack
February 16, 2007
Mind Canary
For decades, as a precaution, miners have been reeling canary birds down into their mines to warn them of potential disaster -- as the canary is particularly sensitive to toxic gases such as carbon monoxide which is colorless, odorless and tasteless. If the canary dies, then the mine is dangerous.
A mind canary is very similar, with the word "mind" as a play off of the word "mine." If the "idea miner" sends an idea canary into the "mind" and it fails to return, then the mind may be lethal!
Thanks to marketing pro Alan Brooks at Mindcanary.com for memorializing this bit of Archestra legacy. He's adapted it a bit (as you'll see in the wording on his homepage) -- but to good purpose: he's guiding folks to safe mines. Hi Alan!
What do you do with a lethal mind? See "change management" and/or "knowledge management" -- at an Archestra location near you...
Posted by Malcolm Ryder at 6:28 AM | Comments (0) | TrackBack
January 16, 2007
CIs, IT and the Good Life
Still, of the three historical areas, Asset management handles most of the money issues and thus often exerts more of a business profile, tending to lay more claim to entrenched authority. Thus its perspective gets a chance to influence thinking in other practices, and the most popular of these cross-over ideas is the idea that items have a "lifecycle".
"Lifecycle" expresses the notion that there is orderliness in the entry, habitation and exit of items within the life of the business itself -- an orderliness imposed by the accountability required of management. An item's "asset lifecycle" covers its birth-to-death milestones that describe how it originated, how it got into utilization and fared there, and how it ended up when no longer needed. All of this stems from a business preoccupation with ownership of the item, the presumed target of all benefits and risks.
Most recently, Configuration management has reared up as an alternate perspective for the accountability of the impact that an item has on the business. A "configuration" is a description of those salient characteristics, particularly in the perspective of the intended "best" utilization for successful work outcomes. If the item is a "business resource" (which of course all IT should be), instead of just business property, then the characteristics of the item are important because they indicate whether the item is fit for the purpose imposed by its utilization. It matters, then, whether the item actually has the desired characteristics, in the heat of the business moment. It is very unfortunate that the term "item configuration" was displaced (for some reason) by the relatively obscure term "configuration item".
Systems management has historically been responsible for making practical characteristics come about in real operational time. But at the business level, Systems management did not offer enough of the authority of "standards". Although "business" would "require" technical standards, there was still a gap between the technology and the logic of the actual utilization that came from business behavior with the technology.
As a result, while items might still have been seen as assets or as systems, there needed to be another way to represent the behavioral standards of the relationship between the business usage and the technology used. This standardization and representation took the form of defined Services. The relationship of the item to the Service became indicated by the item characteristics that were required by the Service -- and those identified characteristics are the "configuration" that defined the item in terms of the service. Thus we have the "configuration item", or "CI"...
Asset management's influence and lust for lifecycle accounting inspired the notion that, since most CIs are assets, CIs must have a lifecycle, too. But taking the notion only that far, confusion has sprouted about what point there is to calling the lifecycle a "CI" lifecycle as opposed to an asset lifecycle. Why have two different names for the same thing?
The answer is that the true lifecycle of a CI is not the same thing as an asset lifecycle, nor the same as lifecycles that might be imagined for engineering, nor other disciplines that manipulate the item. A CI "lifecycle" is not about the management accountability covering the concerns of:
- development
- ownership
- availability
- performance
Instead, a CI lifecycle is about management's accountability of the item's impact on the integrity of a Service. (Service Integrity is a shorthand label that we'll hang on to for future reference to this discussion.)
When prescribed business behavior for the utilization of the item is set up as a service, the two key issues involved are from the service's point of view -- about the progressive degree of provision enabled and the progressive degree of support applied, relative to the state of the CI.
In the matrix above, degrees of provision and support intersect to generate the "milestone" state of the CI that represents a major phase in the CI's "lifecycle". The matrix generates four lifecycle milestones from top left to bottom right, and each milestone represents a degree to which the CI supplies integrity to the structure of the live service. The weakest is relatively conceptual at the top left, and the strongest is very tangible at the bottom right. However, it is important to understand that these four milestones or phases are points on a continuous circle; changes in business needs may require that the deployed and controlled CI undergo "re-modeling" to regain alignment (correct "service ability") with the go-forward business.
One of the most important aspects of that understanding is that an item is not necessarily always a CI: in fact, during its existence, it is a CI from some timepoint to some other timepoint, and for some service or other service. An item may fall in and out of being a CI. The matrix helps to show what management thinking and activity explicitly handles the recognition and association of an item to a service as a CI.
It is also worth pointing out that if there is a dominant historical influence on this thinking, it is actually not Asset management. Instead, as should now be somewhat obvious, the dominant relevant precedent is Architecture, which literally pre-figures and prescribes what should be approved, deployed and controlled in a structure that turns an item into a resource. Where CIs are concerned, the structure is a Service, and the business uses the service to exploit the item.
Finally, all management disciplines are essentially perspectives first and policies second. There is no logical reason why they should by default be mutually exclusive of what they take responsibility for... instead, they should co-operate by together bringing a broader range of attention to any given item. In presenting the CI lifecycle matrix, the intent is NOT to stake out an area of privilege just for "Configuration Management". As further emphasized at the bottom of the illustration, several management processes may have a primary role in attending to the CI's progression through milestones, and these roles are not unusual for most IT management teams. Not coincidentally, the concept of a CMDB will mature into the concept of a Configuration Management System (CMS) leveraging a variety of relevant management information donors in a well-orchestrated manner.addressing service integrity.
Posted by Malcolm Ryder at 5:51 PM
January 15, 2007
Critical Mass on the Critical Path
In his comments on the Archestra article "Why Change Is So Hard", Sid Kemp of QTI, Inc. picks up the beat on how to campaign a change. His description highlights the idea of transitioning between different stable states: the periods before the change and after it. A seven-element program that Sid outlines is a case methodology for "covering the bases" that the Archestra matrix on individual attitudes presented in the original article.
Where it comes to covering these bases, Sid's comment calls out something of more pointed interest to think about -- i.e., that an individual exerts influence on other individuals in a way that leverages the current state of things into a sufficient level of steadiness for a change to be either "accomplished" or "prevented". In other words, the individual can disproportionately contribute to a critical degree of momentum or inertia.
Good call. Furthermore, that has very obvious implications for the idea of "leadership"... It's a given that a group involved in a change will typically feature, within the group, different functional roles in the composition of the "to be" steady state. Not everyone will have the same kind of influence, and the new equilibrium will not ask them to -- neither in the composition activity nor in the final composition structure. In effect, amongst the group of individuals involved, would-be leaders may need to adopt the change differently from would-be followers, and so forth. Along with that, some individuals may experience a change in role due to the move from before to after the adoption campaign. Following suit, have we as change managers identified the leaders and followers on the "momentum" side, separately from the leaders and followers on the "inertia" side? (By the way: we'll note here, for future consideration, that change leaders and change agents are not the same role, even though they may both be played by the same individual. But how about when the agent is not a leader?)
This lets us revisit a "truth" that we've both observed and experienced, which is that in some occasions, "success" is not pretty. It goes without saying that becoming different is not necessarily becoming better, so a proposed change has to carry with it a presumptive confidence that its objective is an outcome that has more value than does the status quo. This is exactly why one of the quadrants in the Archestra matrix is "appreciation" -- it includes the same sense that we convey when we say, as an objective measurement, that anything else has "appreciated". The change proposal argues that the value will be there; the question is, will the individual say "I'll buy that..."??
When the proposed change is an executive goal, those individuals that don't buy that may in a different sense "buy it" : they may become either targeted damage or collateral damage, clearing the way for transition.
But if these individuals are still deemed important as resources to the future state, then managing these resources is a risk management activity within the campaign for change. At minimum, the individual's role must be proposed.
Attention to this issue had been developed methodologically during 2000-2002 by the consulting group Fulcrum Management, whose principals Howard G. Hastings, David A. Messineo, and yours truly M. Ryder offered Change Assessments using the analytic cycle Requirements-Risks-Resources-Approvals to reality check the top-down alignment of objectives and commitments in change.
It is on this point of "alignment" that Sid Kemp's comments on populations being "systems" carry weight. Additional specific light on this alignment problem is cast quite strongly since 2004 by Jonathan Becher in his work with Pilot Software, Inc. in Operational Performance Management. Kemp likewise offers work on the "leverage points" of alignment through his current offerings, under other labels, at QTI, Inc. Neil Russell-Jones puts out "The Managing Change Pocketbook" at www.pocketbook.co.uk, containing a fairly classical approach that we can see mapping to this issue. And (if you are still reading this!), similar efforts in your own sphere of activity are likely familiar to you under various other programs and entities you can name.
So what?
In further articles at Archestra, we'll maintain an opportunity to show how these different offerings reiterate the attitudes matrix from "Why Change Is So Hard", and how they help to explain the criticality of the individual's adoption to the design for change. Naturally, if we find that the matrix is broken, we'll change it...
Posted by Malcolm Ryder at 7:34 AM | Comments (0) | TrackBack
January 13, 2007
Why Change is So Hard
"People change; populations evolve."
The success of a proposed change will naturally depend on whether a critical mass of the necessary participants play along well. As change managers, we naturally prioritize that struggle at the top of the ToDo list.
But when it comes to having a proposed change adopted in the first place, it's not about groupthink. The difficulty begins with the predisposition that individuals have towards the evident idea of the change. Regardless of what the exact idea of the change is supposed to be, the process of adopting the change begins with what people think it is about -- and this will invoke their varying individual attitudes.
Attitude is when one's position is dominated by one's predisposition. It's what allows a guy who needs eight ounces in his glass to decide to call only four ounces either "half full" or "half empty"... Change provokes attitude-sensitive comparisons. Then, the comparison seeks "credibility", an effect which is always part objectivity and part validity.
What we should do is assume that the individual's initial position is always from a personal comfort zone, and that a change challenges it. In particular, starting from the individual's comfort with the "subjectively similar" (as in both the already adopted and the already familiar), the move that Change asks for is to a full appreciation of the "objectively different". This isn't about being easy or hard; it's about being sure to cover the bases.
To cause this move to take place, two key techniques are needed:
- Examples move the subjective perception to an objective certainty.
- Logic extends validity to the unfamiliar or different.
In practice, one can find these techniques utilized in the most common leading tools for influencing performance-related change, such as the Balanced Scorecard. While many differences exist between such tools, they share a reliance on the ability to present a logical "validity" model of causal relationships, along with definitions of elements that allow measurement to provide feedback as "objective" proof.
To summarize the range of attitudes that can exist, and their relative positions, the picture below maps the territory that is to be crossed in bringing about adoption of a change. The axes cross-reference point-of-view against the appearance of the proposed change -- which creates quadrants of positions. In the central area, key words representing the pre-disposition of the individual are placed in each quadrant. The words in the corner of each quadrant label the working evaluation of the prospects for adoption, which the proposer can expect. In the center of each quadrant, the individual's position is indicated. An extremely important principle illustrated is that while making a proposal either preferable or acceptable is probably necessary, it is insufficient to make it adoptable. (This usually turns out to be true because adoption requires creating opportunity, versus constraints and risks, in ways that preference or acceptance alone does not accomplish. Neither preference nor acceptance necessarily amounts to commitment. And while together they only maximize the likelihood, separately they rarely carry enough weight against constraints and risks.)
Posted by Malcolm Ryder at 1:42 PM | Comments (1) | TrackBack
December 18, 2006
The 3-D's of Change
Despite the obvious allure of innovation and efficiency, the two best reasons to change are not to "be different" nor to "escape dead ends."
But they are close. The two best reasons are to "be better" and to "create new options." In other words, what's the point of getting different without knowing how it would be better, and to figure along with that, what's the point of having more options without knowing how they lead to the difference?
Yet change does not guarantee those outcomes. To the extent that change is "driven" by reasons, change is about developing the new means for opportunity; it is not the end in itself.
Thoroughly thinking through the positioning and requirements for change might take some research, which might take some time; because time is often scarce and precious, gravitate towards the "fast tracks" of lessons learned and "best practices" about changes undertaken elsewhere or before.
Emulating such models of change management makes plenty of sense, and yet it remains empirically evident that two organizations trying to change in the same fashion may get two very different results. No real surprise: effective change is an environmental shift, and why should two different environments respond alike to a given model of change?
It's not that they couldn't.
Differences will occur because activities and environments have to form together into functional relationships, and this coherence will feature the detail level of chemistry rather than of carpentry. (Take note, ersatz change agents.) The specifics of cultivating two different environments may call for more risk, tenacity or tolerance in one environment versus another, not to mention time.
But the real key to a successful change lies in getting a grip on its entire lifecycle, which has three major phases that are about how the organization agrees to transform:
- adapt...
- adopt...
- approve.
As a true cycle, it has the property of re-iterating by having the approval phase directly influence the adapt phase.
But the individual phases themselves can be hard to progress.
Without tackling "risk" and "resources", the adapt phase won't have an output. Here, the "support" scenario must be described.
Next, the adopt phase can't mature without good marketing of how the stakeholders' own performance in the new scheme will be evaluated. "Roles" have to be declared and accepted. They will rely on support.
And the approval phase relies on confidence and clarity in how people will know that the intended effects are being realized. "Transparency" and feedback needs to be universally established, according to the roles.
Although driving a successful change has this cyclical buildup of viability, real change in action always shows all three phases occurring simultaneously. This makes them each able to affect each other at all times, more like "dimensions" of change maturity, not just phases of the change implementation.
So, as you might imagine improving on each dimension, the probability of sustainable success with the change gets higher. On the other hand, you can see that failing changes probably stem from weakness in one or more dimensions, which causes imbalances and discontinuities. The many sources of rigidity, resistance and disagreement are where the gremlins reside, undermining (respectively) adaptation, adoption and approval. But they are the flip side of a coin on which support, roles and visibility are the critical redeemables.
Map out your change effort, dimensionalize it, and see whether your efforts to manage the change are as rationally aligned as you think.
Posted by Malcolm Ryder at 7:01 AM | Comments (0) | TrackBack
December 1, 2006
The CMDB as a Knowledge Base
An executive overview.
In the front-office world of a business, the holy grail of a "360-degree view of the customer" is already old hat.
Well, much of what is now happening in the middle office -- the IT world -- revolves around the criticality of utilizing a "configuration management database", or "CMDB". This database is the key to a 360-degree view of any IT asset. In particular, it is a centralized repository of information about how items are defined and situated as components of the information technology infrastructure on which the business runs.
As a singularly authoritative (or "master") source of information about the infrastructure's components, the database content is very involved in the documentation and decision support for almost any business process workflow requiring IT enablement. But what is it about the components that the CMDB describes?
Typically the components for which the CMDB holds descriptions are referred to as "configurations". A quick survey of the CMDB literature shows that would-be CMDB users can get mired in great controversy about what consitutes a configuration, because there are so many ways to segment a chunk of infrastructure IT and legitimately call it a component. After all, the notion of a component necessarily refers to the idea of some larger entity that the component helps to make up. The problem is that any entity's distinctive identity must be defined with a boundary around its scale, complexity and purpose -- but just as any category may be said to be a subcategory of something else, any entity may be a component of some other entity. Thus it may be unclear where to draw a boundary, create an object, and call it a "configuration". The question always begged is "of what entity is this item a component?"
This makes it very difficult to decide what to include and exclude -- the CMDB's catalog of entities should be neither too general nor meaninglessly specific. How many levels of categorization and subcategorization (so to speak) must the CMDB contain?
In the below, we skip all of that confusion by looking at "things" in a more objective way. First, we take the notion of configuration not as a noun but instead mainly as a verb that has a result. The focus is on the motive for action. That is, nothing in the IT infrastructure is there except through the labor of making it fit into the company of other things -- and our first emphasis is on the labor that takes place to respond to the perceived need for including something that wasn't there before. This allows us to think of a "configuration" as the output of a system of functions, and the CMDB first of all collects facts about that output (and other ones, similar or related, in the same infrastructure ) -- as accounted for by its system.
But why collect the information? The primary reason is to put management of these outputs on a foundation of knowledge instead of on hunch. The CMDB's content can fuel knowledge by organizing its information into the three main contexts that matter to the difference between being managed and unmanaged.
Managed conditions always compare the actual against the planned and the authorized. This indicates three forms of knowledge that the CMDB would support: respectively, models, analyses and histories.
The essential CMDB content will be descriptions of states generated by the functions (as illustrated above), to be evaluated in these three contexts.
However, management tends to root itself in the posture of "operations" -- with the difference being that operations are mainly about organizational responsibilities while functions are about activity. This distinction is more profoundly yet simply identified in the hierarchy of management as shown in the next table. Top-down, starting from a focus on business value, the table rows address the questions "Why are we doing something?"; "how are we going to do it?"; and, "what are we going to do it with?":..
It is easy, then, to recognize the same top-down pattern in management's attempt to associate the needs of the business with the infrastructure that would address it.
Arguably, tactics are derived from respect for the customer's agenda, and functions leverage the offerings of suppliers -- so the primary challenge for differentiated management is in the operational dimension. Not surprisingly, Operations lays out responsibility areas in a way that tends to generally reflect functions. For example, the operational chain of development/implementation/administration/support is, on the surface, an echo of the functional flow of build/release/monitor/maintain. But Operations must intentionally, not coincidentally, associate its responsibility areas with the functions it can govern, if the dynamic is to be called "management". Operations must decide what functions will "execute the infrastructure" and how.
Consequently, what management wants from the CMDB is content that helps construct the artifacts of management that should populate the following framework. In this framework, captured knowledge explains how Operations currently puts functions into the context of the bigger management picture -- the one that generates business value. That overall knowledge-based governance looks to the CMDB to fortify its perspective and acuity on what to change, when and why.
Posted by Malcolm Ryder at 11:14 PM | Comments (0) | TrackBack
October 29, 2006
Changing Performance
Although quality of execution ("QOE") is not the same as "performance", in the minds of many managers QOE's Deming Cycle has long ago taken up permanent residence as the basis for performance improvement.
In that view, the mantra of PLAN DO CHECK ACT (i.e., design, execute, measure, and adjust) is a huge reminder that while the "activity" half of work (PLAN DO) is always to be attended formally and closely, the "achievement" half (CHECK, ACT) is not just a "gimme".
From that perspective, managers have a better view of how to make things work not just well but, due to the repetition of the cycle, also with continuous improvement.
Yet forty years after the cycle's debut, the challenge of ever-increasing organizational complexity makes the effectiveness of this advice harder and harder to realize. For management solution-builders like CEO Jonathan Becher of Pilot Software, a reinterpretation of management focus seemed necessary and timely enough to even build his company around. Becher's model -- MOTIVATE, MANAGE, MONITOR, MEASURE -- shifted emphasis from the "Plan / Do" of Deming to a sensitivity about how communication brings workers into the realm of reliable support for the Plan. As a result, purposecould become more consistently followed by execution.
Both of those men's approaches convey value through completeness in a scripted sequence of management influences. Yet both must be grasped within an even larger context of what more completely accounts for "performance".
What really controls the generation of events and their results is the interrelationship of internal forces in the organization; and what is often overlooked is the degree to which those connections are leverage points that are vulnerable to unscripted change. The following illustration's high-level view exposes these points of leverage:
In representing a cycle, part of how this picture works is of course how it positions the leverage points in question, which are Interpretation, Participation, Examination and Prioritization. Here, they take up spots in between the more conventional subjects of management attention.
Each of the "new" items significantly constrains the influence of managed strategy, planning, execution and evaluation. It is relatively easy to grasp that defects, omissions, exceptions or errors at any one of these four constraining points will potentially delay, disrupt or at worst cripple the cycle, despite attention to the more standard concerns. Yet all it takes to introduce those interruptions is competition from some recognized alternative -- in goals, methods or needs. Given that, can we say that we're managing things if we aren't attending to the four constraints on an explicit and sustained basis?
Sometimes the alternative comes from outside of the manager's field of view; sometimes, from deeply within.
For example, as now seen, a Plan is not a transcription of a Strategy; instead, it is more nearly a transcription of an interpretation of strategy. Or said better, interpretation is a precedent of the plan. People don't automatically interpret things the same way; and naturally, politics can play a heavy hand in which interpretation may have the best shot at prevailing. The point is, do we know why people are interpreting things the way they do?
And consider the phenomenon of a second opinion; if interpretation imposes a competing sense of credibility, opportunity or belief on the strategy, the prior anticipated plan will again likely risk being changed.
Further along in the cycle, at the point of Participation, a deeper look at people is also due.
Participation is perhaps the "intermediary" point that ordinarily gets the most attention. But what often gets overlooked in that attention is the distinction between productivity management and change management -- with the big question being how we know that people will really adopt and execute the plan.
These days it is still relevant and popular to understand productivity from the viewpoint of running healthy "systems". And most typical in our thinking about that is the mantra of "people/process/technology". That describes the three dimensions of the systems that we think are both useful and manageable -- plus it offers the encouraging claim that technology will make things more likely do-able. But the catch is: people have to want it to. If they don't want it to, a lot can change. (As noted frequently elsewhere in Archestra discussions, the People/Process/Technology mantra is essentially flawed and should be replaced with the mantra of People/Events/Technology, further superceded by Assignments/Processes/Configurations. But for now we'll leave that alone, and just take advantage of the focus on people.)
What about change? Underneath Deming's "DO", and between Becher's "MOTIVATE" and "MANAGE", people decide what they are going to actually bring to the party. They make the decision as a result of comparing what they are being offered as "next" versus "now". This will not just be a simple comparison of better versus worse, with "now" being the benchmark; "now" may not even be clearly good or bad.
Instead, the comparison will be about whether being involved as requested (for example, by the plan) is a difference that the person can prefer. So what in particular is getting compared?
Both "now" and "next" present possible but alternate realities that elaborate, in detail, the general picture below:
For the individual person, the issue is to reconcile how they already are now with how they are going to be next. Any part of the above cycle that changes -- whether that be expectations, intent, or observed effect -- can introduce a new preference, dissuasion, or even some cognitive dissonance such as pitting their desires against their ideas or against their ethics.
In this second picture, as in the first, the points of influence are interrelated by position. To the point, Acceptance is always preceded by Expectations. Then, when Acceptance is followed by Intent, people really arrive as drivers of the activity that eventually will be studied for determining performance.
What managers need to know is that the Expectations segment of the cycle is affected by both Awareness and Acceptance. If either of those changes, expectations change too. Likewise, intent will be sensitive to both Acceptance and Actualization -- so managers have to provide corresponding opportunity that moves Intent to real action. These sound a lot more like issues of leadership that managers must fit in.
Meanwhile, in the end, the individual's mentality about his/her requested role must track back beneficially to the participation needed in the point between planning and execution. That's what the two illustrations together reveal.
Posted by Malcolm Ryder at 6:37 AM | Comments (0) | TrackBack
July 26, 2006
Managing Change Partners
Solutions actually arrive for use through the activities of design, development and implementation. But each of those steps is a point at which opportunity and ability may easily associate with each other in ways that can unpredictably affect the other steps, and/or can result in doing something for the wrong reason. Worse, because getting a problem solved is important, sometimes the importance translates into a sense of urgency that makes most kinds of help look attractive. This can confuse the assessment of the value of the help, leading to a selection or acceptance that means doing the wrong thing for the right reason...
To avoid those problems, the division of labor and responsibility needs to carefully associate ability and opportunity through authorization and control. In short, the difference between what can happen and what should happen must be planned, and recognizing proper roles is a success factor in supporting the plan.
In the picture below, a number of typical opportunities for solution production are mapped out to show the situation in which they are most appropriate. This helps to guide requests for certain types of participation and investment in the solution production. Using outside help to supplement one's own capabilities in design, development and implementation should mean using the time and money on having the partner do the right work.
Posted by Malcolm Ryder at 10:52 AM | Comments (0) | TrackBack
July 9, 2006
Driving Action with "Values"
In most conversations about how to properly focus an organization for success, the prescription calls for the organization to leverage its identity as a source of performance strength. For doing that, the notion of "values" is promoted as a major success factor.
What makes "values" so important? The key ideas are that it is typically easier to maintain effort for what one believes in, and that not knowing what matters the most "internally" leads to an inability to sort out and navigate through what matters the most "externally".
In trying to make "values" an integral part of operations, the organization will typically develop priorities; then it will group and cascade the priorities into policies -- ones that can be applied as instructions accompanying activies that the organization anticipates it should conduct or host.
While policies provide the practical expression of the priorities, many organizations are only partially successful at providing them and even creating them. The initial challenge in developing the priorities is usually to decide not just what is considered to be a representative "value" but also to get agreement on why it is necessary to hold onto it. The challenge is made tougher by the fact that the circumstances surrounding the organization may be constantly changing in important ways demanding direct attention. Further, the identified priorities may seem to compete with or even contradict each other.
Consequently, this period of investigation and definition takes many forms and often must be repeated -- but while no two organizations may arrive at the same conclusions, they all try to arrive at them through what will be called a "value system" -- some model for evaluation that is persistent above and beyond the level of ordinary circumstantial change. This sytem will then govern, more or less, the ongoing refinement and validation of priorities and policy -- at least until again too many new occasions prove to be irreconcilable within that system.
When this roadblock occurs, individuals or organizations experience conflicted priorities as indicators of a defect or breakdown of the value system. But in this experience, it can be unclear as to whether the apparent conflict is really due to the system or instead due to a lack of rigor or understanding within its use. For example, rules are often seen as the specific expression of a priority. Sometimes in using them, there may be confusion about whether an undesirable situation -- meaning, one in which prior action has turned things sour or subsequent action will likely do so -- has been forced by "a bad rule", or whether instead a good rule has been inappropriately applied. The conflict stems from uncertainty about the correctness of what was done or of what to do.
This example is notable because the action that makes the situation "undesirable" normally derives its justification from the presumed value system. When the undesirability of the situation makes us debate the system's own correctness, we tend to wonder if the system is unfairly "skewed" one way or the other. Meanwhile, the conflicted priorities that come with the undesirable situation may be a disagreement between two or more parties, but the conflict can also be a disagreement that one party feels within itself.
An important part of a value system's responsibility is to provide a means of distinguishing the character of one action from another. A critical understanding of the importance attached to "value systems" is that they are focused on why things should or should not be done a certain way -- not on what the actual results are. But perhaps most important of all is that a value system's force comes first from its ability to identify and describe things, not from asking it to measure things. That is, a value system is a perspective, not a set of scales.
With that in mind, the discussion below takes a look at how the essential form of a "value system" works to provide critically distinctive identification (not measurement) in a "situation at hand".
To begin with an example, the following picture shows a highly generic framework, intended to more precisely declare the main factors that go into the often fuzzy notion of "values". These factors are what goes into actual decision-making in "real time".
In an ideal situation, this framework would represent an organization's or individual's "mindset" -- one with consistent awareness across all of the framework's factors. That is, there would be an equal and simultaneous grasp of what is "responsible" or not, and what is "right" or not. Armed with that awareness, the character of the action that is possible at any moment could be evaluated as one of a few basic types -- for example as being "virtuous" or being a "gamble".
The framework identifies these basic types by introducing and cross-referencing a major distinction between acts and beliefs -- which respectively translate into the corresponding difference between ethics and morals.
This framework can offer the terms that it uses without the burden of emotional and philosophical histories, because it is not concerned with persuasion but rather with description. All descriptive systems have built-in assumptions, and this framework is not an exception; however the purpose of the framework is completely explicit, with no ulterior motive -- and therefore it can easily be used or ignored according to the practical interest of the observer. It's not that one must compare acts and beliefs, but rather that one usually can.
Two important assumptions in the framework are indicated by the lower left and upper right tags added to the central 4x4 grid. (Arrows are also supplied to signify these assumptions in the diagram.)
The first assumption is that Laws are primarily concerned with enforcing behavior away from transgression and towards virtue. (Moving behavior both higher and towards the right eventually would converge in virtue.)
The second assumption is that Principles are primarily concerned with defining and promoting behaviors that meet acceptable standards. Principles "pull" behavior towards them.
The lower left and upper right regions in this framework are readily comparable. But what is among the most interesting experiences of our society and social value systems is that we are constantly bumping into behaviors that occupy the "middle zone" of sacrifice and gambling.
For example, with sacrifice, a person discovers, perhaps unexpectedly, that they feel an innate (not externally imposed) responsibility to do something that they actually did not otherwise believe was "right". The very occasion itself exposes the difference between what they recognize as acceptable from the standpoint of need, versus from the standpoint of preference. As very dramatic samples, commiting a mercy killing or submitting oneself to bullying in order to protect someone else both fall into this category. As a very mundane sample, giving up properly ("rightfully") earned profit in order to placate a confused customer falls into this category.
In the case of gambling, circumstances are such that the gambler (the actor) often knows a gamble is being taken when others cannot tell. TV shows regularly feature examples of this, where with the best intentions detectives search crime scenes without a warrant, or prosecutors try to use the "fruit of the poisoned tree". Yet sometimes the actor is doing something with self assuredness about rightness, while unaware of how it might be irresponsible. This latter case is accounted for by the framework, but in our discussion the framework is primarily interested in the awareness that motivates the actor. How does the actor decide to do something "irresponsible" in order to do something "right"?
The thinking behind this framework additionally assumes that the actor chooses to gamble -- to take an irresponsible action -- due to his perception of need, while the preference to cause something "desirable" is normally what actually provides the actor with his "justification". Clearly, this is the formula for pragmatism, or the idea that the ends justify the means. The problem lies in whether the "desirable" is also what's "right".
On the other corner, back to sacrifice, actors and their critics often mistakenly judge sacrifice as pragmatism. The judgement error lies in not realizing that sacrifice is not about the ends but instead about the means. Compared to gambling, sacrifice is about not having a choice in how to proceed and doing what is possible instead of doing nothing. This is why "heroes" are not always seen as "the good guys", even though they are usually distinguishable from anyone who is not heroic. Heroism is a way of being that is actually not defined by results. A sad and common example of this is the case of dysfunctional personal relationships wherein one party is routinely heroic but with only the effect of propagating a bad relationship. Likewise, heroic corporate leaders can quickly take the company to ruin. By the way, these examples only reinforce that the actor's overall frame of reference is the dominant one behind the activity. Meanwhile, external observers might readily conclude that the heroism was "noble" but still "not right". (Gambling is generally not seen as being noble.)
The above comments tend to suggest that action is based on needs while beliefs are based on preference -- and that suggestion is intentional even if conceptually experimental. Assuming the suggestion is valid, there is notably still no reason why both need and preference would be unaltered over time by experience and education, or by each other. So it is not a simple opposition of "needs vs. preference" that is unlikely to be valid -- rather, it is the actor's sophistication about the two of them that will make their opposition more or less complex and reconcilable.
We see this continuing dialog between them on a grand scale in the court system, where laws and principles tussle with each other for control of the interpretation to be applied to sacrifices and gambling -- to idiosyncratic heroism and to pragmatism. In light of the framework's clinical terms, the history is saturated with debates over things that seemed ethical but immoral, and things that seemed moral but unethical. Often, the challenge is to "unload" the labels of their psychological baggage, so that the important contrasts and comparisons can be made between the context that declares "right/wrong" (correct/incorrect) and the context that declares "responsible/irresponsible" (proper/improper).
On a corporate scale (i.e., a microsociety), requirements wrestle with policies to control the interpretation (and exploitation) of "opportunities". A company will agree that a lucrative and reasonable proposal should be accepted, but it will disagree that a non-executive should make the deal. The idea and goal of the deal might be right, but the non-executive taking charge of the transaction is irresponsible.
On a personal and private scale, roles wrestle with desires and wind up shaping personalities and relationships. In this discussion, the personal level is really not intended to be directly explored any further, but the recognition of the dynamic is not difficult on a personal level, so the discussion has leveraged this fact to help reinforce support of the framework's idea at other levels of organization or influence.
What clarification does the framework present, finally, about the notion of "values" ? The main clarification is that "values" are an idealized way of pointing at something more specific -- namely, the prescription for the balancing of beliefs and acts. But the framework shows that values come in a range from unambiguously good to unambiguously bad. Naturally we promote the "good", but this doesn't logically eliminate the others nor their actual practice.
The other key clarification is that the influence of values on action is by will of the actor -- meaning that values are not inherently compelling. Instead, the value system has to propose definitions of right and wrong, and propose definitions of responsible and irresponsible -- and the acting party (individual or organization) still has to find reasons to position itself within the range of values generated.
Posted by Malcolm Ryder at 10:22 AM | Comments (0) | TrackBack
June 18, 2006
Operations Value versus Operations Performance
To say the least, operations are a lot of costly effort. Then, because we're concerned about what our expended effort is worth, everyone wants to measure value and measure performance.
But not many bother to distinguish the two well enough.
The point of measuring performance is to determine what one's effort is worth. In fact, we'll often think and say that if performance is good then the effort was "valuable". But it doesn't necessarily follow that the effort wasn't valuable if performance was not good. Why not?
Don't confuse "value" and worth: instead, think of worth as the target impact of the overall effort -- or in other words the goal.
Meanwhile:
- Performance indicates how close to the goal your effort got you;
- Value indicates what was effective about how the effort got you there.
The danger in confusing the two is that steps taken to "correct" or "enhance" previous results can too easily turn into solving the wrong problem. For example, in the name of getting better results, changing value doesn't necessarily change performance -- nor vice-versa.
To choose and make the right kind of change, and to know how it will finally help, each kind of change -- value or performance -- must be accurately conceived, and their relationship to each other must also be defined.
I.
First, consider value. Put simply, value within operations is identified in the production of a significant difference.
Ordinarily, we think that "significant" means that things didn't just get different but that they got closer to what is desired. But more strictly speaking, any difference that alters the dynamics of conditions from what they had previously been must be recognized as "significant". In that case, determining value means understanding the meaning of whatever actual difference has occurred -- whether the meaning is desirable or not.
One of the main reasons to recognize different roles in organizations is to be able to focus on different kinds of value being created. For example:
- Leaders see themselves as creating culture.
- Managers see themselves as creating viability.
- Implementers see themselves as creating capability.
So they each have different ideas about value -- and also possibly about performance. More importantly, these different approaches have to be leveraged in a way that actually does improve overall performance, which means there must be some model or "performance logic" that explains and reconciles how the various approaches get the job done.
Let's take the example of what a business wants from an IT organization. To understand this relationship properly, it must be recognized that a business person who has responsibility for leadership, management or implementation is in the role of a "leader", "manager" or "implementer". Where IT is concerned:
- Leaders want IT to provide advantages through innovation and cost-reduction.
- Managers, serving the leaders, want complexity and risk minimized, and availability maximized.
- Implementers want customizations and configurations to be prefigured and completed, not ad hoc and hurried.
And to fully understand that state of affairs, it must be recognized that ideally an IT person can take on all of these roles as well. What should happen is that in sharing a given role, the business person and the IT person should divide the labor called for within that role, and conduct the labor to make the appropriate kind of difference with that role.
The division of labors starts with clarity on what the issues are to which each role should be primarily attentive.
- Leaders see change in terms of Opportunities and Threats.
- Managers see change in terms of Strengths and Weaknesses.
- Implementers see change in terms of Norms and Exceptions.
With the issues distinguished by role, a given role's two main viewpoints on responding to them are as a Decider and as an Enabler.
II.
In the Business/IT example, it is common that the Business takes the Decider view and IT takes the Enabler view. But -- to cite an instructive case in cooperative role-fulfillment -- these days IT executives are usually strongly urged to acquire the ability to understand things from both points of view, and to exploit that ability within their responsibility and domain expertise for managing IT.
In pursuit of goals (i.e., worth), everyone wants change to be positively valuable instead of indifferent or destructive. In the normal business context, recognized value is associated with the ability to positively influence the customer's acceptance of what you want to offer. For this purpose, the roles align with each other to systemically (not systematically) address each other's requirements and leverage each other's contributions. Leaders look at the market and respond to it; but Managers respond to the leaders, and Implementers respond to the managers. In the flow of requirements from leaders to implementers, this alignment -- or better, coherence -- can draft progress towards the goal. The point is that each role makes a kind of difference that nurtures the effort of the role next in line. In the following illustration, we go further and argue for a fully interconnected set of relationships.
Given this "closed loop" view, the final link of alignment would appear to be that Leaders will also look to Implementers in some way, not just to the market. Superficially, it's hard to argue against that link being "evaluation" or "assessment" -- that is, leaders taking the time to decide whether the implementers (were able to ) have realized what is needed.
But based on long-standing arguments in the field, most organizations need a better understanding of what this last apparent link is really about. The starting point for clarification is simple: Leaders should not tell implementers what to do -- but instead tell implementers what is needed. The better Business gets at defining needs, the more likely it will wind up with something valuable that it wants -- so it falls to Leaders to assure that Business Needs are well defined and communicated. For example, in the classic case of trying to coordinate business and IT interests, leaders need to set the business agenda for IT -- but business should not set the technology agenda.
But how do they forge their cooperation?
III.
In general, agreement, not command, is the "constructive" mode for their coherence or alignment:
- The business agenda for IT is made up of objectives; it should be all about when and why. Leaders and managers should agree on that -- on when some condition should be developed or pursued, and why. This will be reflected in planning.
- The production agenda is made up of requirements; it should be all about which and how. Managers and implementers should agree on which activities should be executed and how. This will naturally be reflected in the choice of producers but will also be reflected even more basically in processes.
- The technology agenda is made up of resources; it should be all about what and who. Implementers and Leaders should agree on what gets used and who gets to use it. But that agreement will be based on business needs. Policies, especially, will hold this connection.
The set of agreements describes how the continuously interacting roles stay contained in the loop.
How does this model the logic of performance instead of just the range of value types?
Going back to the basic definition of "performance", the focus is on how far the effort has taken us towards the goal. The key idea of the performance logic is that certain types of value are created by the effort, and the value-types combine to foster progress towards the goal. The "logic" of the progress is in how the value-combinations create advantages for, or remove barriers to, progress -- and the punchline is that progress itself must be defined before it can be measured. In the model offered by the diagram above, performance is seen in the additional degree to which a goal-oriented change means capability (through implementers), viability (through managers), and acceptability (through leaders). Said differently: what can be done, how well can it be done, and how much will we support doing it? To the extent that those factors account for successes already noted, their combination may be used as a predicter of future success. For the most part, amongst roles that generate these "success factors", the coherence provided by plans, processes and policies mirrors and directs the logic and its re-use.
The table below pulls together the above thoughts in a representation of discovering and cataloging the generation of these success factors. It overlays the distinction of the key roles with the main viewpoints within each role. The table lays out the task of identifying what decisions and enablements can be associated with each role -- and from there, alignment would be tested or attempted in plans, processes and policies.
IV.
Postscript:
Because production flows from implementers to the leaders, Managers bear the responsibility for proving that implementations can be aligned sustainably with the business objectives. In effect, Managers act as the "agents" and "brokers" for Leaders.
Of particular note in the IT example scenario, change is the biggest problem in IT, because it challenges standards, forecasts, and budgets -- all the things that make it possible for managers to minimize complexity and risk. For that reason, Change Management must be something that Leaders are willing to be champions for, otherwise they should not expect managers to do well.
Posted by Malcolm Ryder at 7:25 AM | Comments (0) | TrackBack
May 27, 2006
Seeing the "I" in Team
Some popular notions of teamwork promote "selflessness" as a critical success factor. But the reality is that success in execution relies on acceptance of requirements by people who conduct the activity, and those people never want to stop being "themselves". The question is, can they find a self that they prefer, in the context of the group's needs?
Organizations rely on an interesting balance of interests: that people will accept the way management combines its awareness of people as resources with its awareness of people's autonomy.
The basic factors in this balance can be teased out quickly as shown below:
The illustration suggests and even argues that the way a member of the organization operates is subject to at least four different predispositions. This raises the question of whether a member of the organization feels compatibility amongst his or her four different predispositions. Additionally, at any given time, one or more predisposition may dominate. And even further, the predisposition(s) can easily be complicated by the influence of superiors or peers who "cast" him or her in certain positions that may feel more or less tolerable or interesting.
Often, organizations -- or at least their managers -- take it for granted that the member's four predispositions are aligned. The vocabulary of jobs, as seen inthe bottom half of the illustration, promotes the idea that alignment is almost matter-of-fact. At least, the assumption is that the member of the organization is experiencing a level of compatibilty amongst the predispositions that is critically adequate for effectiveness in the work at hand. Just in case, a combination of incentives and penalties wrap around the person, helping them to rationally "bind" the four predispositions together themselves.
But despite these behavior-management tactics, psychology, politics and luck are amazingly effective at changing the balance. Each is an influence with a more or less direct "line of communication" to the four different predispositions.
High-visibility persons intuitively feel that their profile (of predispositions) is under more pronounced scrutiny than do low-profile persons. In effect, the stakes are higher, and this raises the sensitivity that their predispositions have to the influence of psychology, politics and luck. It also raises the level of need to develop or exercise personal skills for managing the predispositions.
But this is not to point out an issue special to the upper ranks. Instead, the observation is more one that proves the point by magnifying it. To the extent that the organization's key objectives depend on personal commitment to goals and to "professionalism", efforts to leverage a balance of predispositions must practice a higher consciousness. They cannot afford to lose sight of the many ways that the person's four predispositions might combine to offer acceptance or resistance to the experience of the initiatives that the person predicts for themselves. The truth is, without the "I", there is not much chance of having a team.
Posted by Malcolm Ryder at 6:31 PM | Comments (0) | TrackBack
April 29, 2006
KM, and Measuring the Value of Change
We normally perceive change in terms of "good" change or "bad" change. That is, usually, the value of change seems readily measurable. But why is this? The answer is, because we have a preference before we notice the change, which gives us a reason to notice it.
The usual approach is to first define "value" -- namely, the difference that we want the future state of affairs to have from the current state -- and then to go about measuring the progress that action and time make towards achieving the desired difference. Here, the issue is that although actions and time are both highly various, we usually decide (prescriptively) which actions and timing we will watch.
Because that approach is such a routine for managers, it is all the more baffling to go about it the opposite and less frequent way -- defining the changes that action and time make, and afterwards figuring out what is the meaning of the changes to the current state of affairs. That is, in what sense are the changes recognizable, post facto, as "progress"? What, exactly, is progressing, and do we want it to?
Said that way, we might conclude that, as in the former approach, the majority of management's attention to the phenomenon of change is "regular" and pragmatic, concerned with oversight and with assigning old or current meaning to new observations.
Yet that passes up the home territory of insight -- or, as in the less frequent latter approach, assigning new meaning to old or current observations.
Put more precisely, the distinction is one of being practical versus theoretical. For most business concerns, the problem with theoretical value is that it's either too slow or too speculative to realize -- which makes it expensive to sustain.
Case in point: the influence of knowledge in the organization is often seen as stealthy or unmanaged, provoking changes of unknown value. But harnessing it for managed value frequently appears to lean towards the expensively hypothetical.
This is where many KM efforts get stranded today. Yet meanwhile, that makes it similar to the issue of R&D. In R&D, there is normally some investment justified by the expectation that significant future value will come from new products -- or said more forcefully, justified by the belief that innovation in production is necessary.
Justifications specifically call out the connection between motivation and measurement -- which indicates the importance of thinking about why to measure -- not just what to measure.
Given the example of R&D, the question in most organizations is whether innovation can also be culturally accommodated as a normal and important phase of the ongoing "production lifecycle" of adopted operational knowledge.
The way most organizations recognize their adopted operational knowledge is as "competency". Thereafter, the way they measure the value associated with changes in competency is by measuring the before-and-after difference observed in what looks like a capability: predictably achieving progress through selected modes of action in given situations. At least casually, everyone sees that as "performance", and thinks about performance improvement.
Of course, one of the practical approaches to incorporating changes of competency is simply to buy the already proved "better" competency -- as in hiring "experience". The catch here is not in the difficulty of finding such talent, but instead in correctly defining what it is about the talent that demonstrates the greater likelihood of providing greater predictability of progress. Ordinarily we look for that demonstration in proof provided by prior known situations, or "performance histories"...
But as we know, all workers must adjust to the complexity of the organizational environment, and those who might have seemed to be the most experienced people coming in do not always prove to be the most "effective" people later. For example, struggles with the current work environment (context!) can strongly frustrate the promise of previous experience.
In fact, the most distinguishing problem to solve through knowledge management -- the most challenging "given situation" to address with competency -- is to enable us to know what to do about what we don't know. The main example of this is an ability to solve new problems brought on by dynamics that currently lie outside of our control. (Politics, competition, economics, or whatever.)
Operationally, we can think of the level of that ability as a demonstration of "intellectual productivity"... the degree to which knowledge inputs generate situational effectiveness. But explaining that productivity puts a premium on recognizing improvements in problem-solving capability, instead of on the historical outcomes of solution efforts. Outcomes may indicate improvement, but managerially, the emphasis must be on the mechanism that produces the outcome.
Articulating the features of "successful problem solving" gives a list of (mainly behavioral) characteristics. Those characteristics are really the desired direct results (i.e., differences achieved) of applying knowledge management as an approach to changing operations.
Bluntly summarized, the main goal of knowledge management is to change how things are done, not to change what the doing delivers. The deliverables may or may not subsequently change because the production changed -- but the primary importance is in transforming the production itself in "necessary" ways, so that deliverables can change.
That gets us back to the motivational aspect: the challenge is to define what it is about the production that is necessary to change and why. If successfully articulated and agreed, that particular notion of "necessity" puts pragmatism into the overall KM effort -- easing justification of sustaining investment in the effort.
In re-engineering operations with KM, two broad categories of response to the necessities are: the type of knowledge to develop and incorporate; and, the mode of incorporating the knowledge in the real-time of operations. Aligning things across the two categories can happen as a matter of determining a best practice (process optimization), or as pursuit of an innovation (R&D), but the point is to ensure that this alignment actually occurs. The difference between the current degree of alignment and the target degree is the value of change to be observed.
Posted by Malcolm Ryder at 6:26 AM | Comments (0) | TrackBack
March 3, 2006
Driving IT Bang for the Buck: Evolution, Improvement, or Innovation?
When we think of effective IT spending, we're focused on making the best current use of the money, given competing alternatives or emerging options. But increasingly, the basis of effectiveness in business spending on IT proves to be in how the business manages its reliance on IT.
Sometimes we don't have enough visibility of legitimate alternatives and options. The urgency of our attention to the purpose that justifies the spend means that this lack of perspective could be left unsolved. But for that reason, a diligent evaluation practice looks for opportunity costs that should be factored in. As part of this diligence, what remains to be emphasized even more is not how the IT will make the organization work, but rather how the organization is going to make the IT work.
I.
In the full cycle of management, the business first conceives and identifies why IT is needed before it makes any other decisions. To avoid taking the need for granted, this first decision means describing the business model in terms of what potentials are granted it by available IT. That is immediately followed with a forecast of how sustainable those potentials are -- which necessarily means identifying and selecting how to make them sustainable.
When that architectural aspect is clarified, the next part of the decision cycle must create a "delivery" organization that can constructively practice the architecture. This means two things:
- establishing the sources and resources that will produce the infrastructure from the architecture, and
- establishing the processes that will link IT production cycles to business operating cycles.
At that decision stage, reliable design and reliable production easily wind up being qualifying criteria used to distinguish the various opportunities, organizations and risks that the business will incorporate as the elements of realizing of its model.
Thus, investments in their incorporation aim to relate reliability to the goals of business. That aim immediately offers a perspective from which a high-level assessment of the current business investments might be done. Normally this makes us think of metrics; but as pictured below, the main point is to allow the perspective to stage comparisons and guide questioning. Here we might just catalog known commitments by critical business goals.
II.
Those commitments might then involve or indicate spending on IT. But, as described there and below, the associated "IT investments" are not about IT per se but rather about the application of IT. We can understand the idea of "application" by considering the purpose of the IT utilization.
- At the highest level of distinction, the business goals of incorporating the opportunities, organizations and risks are recovery, health or growth.
- Within each of those goals, sub-goals are development, maintenance, and change.
- And within each of the subgoals, another sub-level features assessment, design, and control.
Consequently, it is possible to ask questions at the management level such as, "Can we control the maintenance of our health?" or "Can we assess the development of our recovery?"
These are not IT questions -- but they are questions that present opportunities for IT to enable successful management outcomes. In turn, management is focused on enabling successful business outcomes.
Taking that framework of IT incorporation as the main perspective, it is easy to appreciate that business utilization of IT is nearly always altering something -- either a behavior or a current state.
The importance of how IT is managed, though, is in how well IT supports management's ability to intentionally change how the business can behave. (From here on we'll consider "change" in this larger context.)
III.
The observation just made emphasizes that we can and should compare the kinds of value offered by different classes of change, and then associate IT's effects to those values -- as contributions.
To demonstrate that, compare evolution, improvement and innovation.
Relative to each other, these kinds of change differently affect the state of the business:
- evolution permanently modifies the fitness of the business's model to the dynamics of the environment in which demand develops;
- improvement modifies the fitness of its conduct to the current and targeted demand;
- innovation modifies the fitness of its output to the needs of the environment's population.
According to perceived conditions regarding recovery, health or growth, business executives must determine when any of these three modes of change requires higher-priority attention. A timely reaction is mandatory, but proactive change is potentially strategic to optimizing the benefit versus risk of those conditions. That may result in new or extended initiatives to create the necessary related sponsorship and opportunity, including competencies and technical support that might drive spending.
To support a proactive stance, a good device to have would be a framework for envisioning, monitoring and ultimately predicting circumstances that we can agree will signify a need for change. Not coincidentally, those circumstances have the look and feel of key ideas offered within the business justifications for IT spending. That device might look like the following:
IV.
But given those considerations, executives and managers together should ask the "big picture" questions -- for example, whether an improvement initiative is the most likely candidate to produce better recovery, as opposed to an innovation initiative. At the same time, it is important to recognize that one kind of change may be an element of another kind and acquire priority that way. After all, form allows conduct, and conduct (i.e., production) allows product. As another more specific example, innovation may accelerate evolution, and improvement may create more opportunity (security, income, knowledge, etc.) for innovation. Thus, an improvement initative can strategically foster the goal of accelerated evolution. But likewise, the requirements for supporting an adopted innovation may obsolete improvement efforts dedicated to earlier production, eliminating that legacy cost while potentially releasing resources for new purposes.
These interrelationships are characteristic observations in portfolio management.
IT management must be focused on applying IT to business operations present and future. On the one hand, it is typical that an IT budget might be evaluated in terms of how much spending goes to "maintenance" versus "R&D" and so forth. Those generic classes correspond to how IT responds to the business requests for support.
But the rollup of dollars into those classes can easily obscure the more important and time-sensitive issue of whether the right things have been selected for maintenance, or the right things are being pursued through R&D. By calling for a distinction between wise spending and merely approved spending, we get to a conversation about how management leverages IT for the business -- as opposed to mere responses. In that conversation business and IT organizations together find the logical path to measuring the effectiveness of the decisions, and to measuring how much that effectiveness was worth.
The view that unifies their concerns is not one about how "IT investments create business value", but rather one that business value subscribes IT.
Posted by Malcolm Ryder at 8:16 AM | Comments (0) | TrackBack
February 4, 2006
Change How You Change
The overall session plan for the strategic planning retreat was conventional. It began with a period of discovery and investigation, and would follow up with some prioritizations and then finally some commitment-making. But now it's running late. Then the attendees hit the realization that they don't yet agree on how to agree...
This moment is likely to recur; we can expect it at least once during discovery/investigation; again during prioritizations; and yet again during the committing phase.
The way the sessions are currently formatted is supposed to get them past these points, but now that's being seriously tested. The particular instruments being used along the way -- collaborations, pop quizes or games, spreadsheets, anecdotes, humor, testimonials and others -- are important accelerators and steering wheels, but are they even the level on which this barrier needs to be tackled?
We can detect the heat of the moment by someone saying "How about, let's try this..." and not infrequently the group willpower to make progress will find something that seems to cure the moment. But what if this is really skirting the issue -- which is that not knowing how to agree is a symptom of not knowing how to change?
I.
Real change hasn't occurred until the party that must sustain the change has become an agent of the change. For this to happen, that party's consciousness has to be altered. When the party is an entire group, the timing might be more difficult to anticipate, but the rule remains the same.
The change of group consciousness is a pattern we come to recognize -- occurring in four main stages that will ultimately allow a strategy to be adopted.
To see this clearly, the three-stage session format must first be set aside, although it might later be brought back more clearly as a vehicle instead of as a driver.
Even then, though the direction is towards making strategy adoption allowable, the destination must be correctly understood. There will still not yet be a strategy plan to adopt; but this is appropriate and, more to the point, necessary.
Why is that more to the point? Because making strategy is inherently a creative process and the bulk of the value is in the process of making, not in the product (aka the strategy plan) made.
Once the product exists, the value of the product is not a function of strategy -- rather it is a function of applying the strategy plan, which really is the issue of execution. Execution accounts for the mandate "change how you succeed". Because everyone wants to focus on success, it's natural that almost everything gets seen through the filter of execution.
But Strategy accounts for the mandate "change how you change." The most significant transformation that the organization has to go through is not the difference between new directives versus old ones, or between certain new processes versus old ones, but instead between being routinely strategic versus not being routinely strategic. The key challenge for most organizations now is to generally and continuously behave strategically, instead of simply executing approvingly.
II.
Here's how, in these sessions, we get to the real "strategic goal", which is actually not a way of being new but instead a new way of being.
First, we learn or otherwise acknowledge that needs are not requirements. Too often groups go into "strategy sessions" believing that the reason they are there is to find solutions instead of finding themselves. The solutions of course are connected to perceived problems, which in turn are connected to ideas about intolerable current differences from a state that "should be". (Observe how much churning is associated just with the disparities in those perceptions...) This issue of what "should" be is most often set forth as a future state which is described as goals. Those goals are normally "felt" like requirements to meet. So what's wrong with this? Answer: the feeling is almost invariably interpreted through familiarity with the way things have already been done. That feeling is about what, and how much, of the familiar stuff has to change. Granted, it is sensible to think about "how do we get there from here" -- but this is not going to establish the reason or justification for adopting an emerging strategy. Actually, it's a source of wrangling over commitments to the past.
The one thing that must be clear before the next step in consciousness can emerge is instead a common awareness of what need must be met. Meeting the need will happen in the future, but the importance of the need is that it already exists. Yet the need will not be properly acknowledged until the stakeholders have been identified and ranked by their importance as target beneficiaries. Keeping in mind that we ourselves are stakeholders, too, our responsibility to the stakeholder(s) defines the need that must be addressed. We have to both acknowledge the primary stakeholder's mandate, and agree to cooperate with it. To round out the understanding of need, we also have to be able to relate our own interests as a stakeholder to the highest priority other stakeholder. It is necessary to ask, "What is our purpose", but it is insufficient; we must also ask "Why is that purpose ours?"
In the next step, that clarity of need sets the perspective that sorts out the discoveries from current-state investigations so that effective selection and organization of knowledgable inputs can occur. What should come here is visibility that allows us to identify the right problem to solve. This step is often deceptive because of the difficulty of defining problems in the way they need to be defined. In this phase, a "problem" is a necessary difference to be made, for which the significance is stated and agreed but the approach and means is not. In other words, the problem is the "value proposition". The working definition of value is "a distinction with a difference" -- and the essential task of this step is to decide what difference is necessary to satisfy the already affirmed need. In this stage, understanding difference involves recognizing that alternatives exist -- as opposed to just modifications. A modification means that the stakeholder can make something useful in a different (and presumably better) way, but an alternative means that they are free to simply use something else entirely. To eventually be responsible for an alternative, the providing party will take efforts that must be understood now yet need not be chosen until later, as in the next phase.
Consequently, some parties, at this point, understand for only the first time their true current position .
In the third step, the challenge is to choose your pain. This is a double-barrelled shot, because it calls for acknowledging that any choice has both positives and negatives, and because a choice must actually be made. Where do parties go wrong here? Their energy is highly charged and in large supply for trying to negotiate a consensus on which benefits and which risks should be accepted -- as if they were separated from each other in different aisles in the grocery store and only wind up in the same shopping basket by our discretion. But these invented match-ups will often be just fictions waiting to fail. Instead, some from of rigor must be applied to measuring opportunity costs, so that it is clearly understood that all value comes with risks, and that one cannot choose a value without choosing its already "built-in" risk as well.
When the logical associations of value and risk are frankly admitted across the board, the final step in the change of consciousness can develop in a way that can rationally affect agreed action. In this step, value and risk are both seen as aspects of opportunity, and the ability of the organization to leverage the risk of value becomes a foreground subject -- one that will point at logical material relationships of the expectations, structure and command of the organization. In effect, by emphasizing recreation instead of modification, this stage will change how we change.
Changing how we change does not necessarily produce a different outcome -- instead, the point of it is to be able to produce the needed outcomes in a different way. Developing a strategy is creating a way of being; and changing a strategy is changing a way of being. Being strategic is a competency, not an event.
III.
A design equation for the strategy forms: "why we should take this value" plus "how we should take this risk". Solving the equation will create the common vision of the way the organization should be. That provides the rationale for how strategy adoption on the personal level will link to and complement its adoption on the workgroup, departmental, division and finally enterprise level.
Many organizations will be able to approximately navigate the sequence of four phases by identifying and aligning such issues as:
- the purpose
- the value proposition related to the purpose
- the benefits and opportunity cost of realizing the value proposition
- the allowable and sustainable organizational structure given the above
In real life, all current states offer alternative futures but no guarantees. The part that we can control is the way that we will be. In picking a future, an alternative is proposed but until it is adopted it is just an idea. Adoption means that we have become an agent of the thing we adopted.
Here is a recipe for mistakes and posibly rejection:
- starting out with "requirements": requirements don't make sense until after priorities have been determined about committing to the value proposition. Essentially, requirements point at "allowable means". On the one hand, that makes them a huge source of debate, since different stakeholders have both different means and different allowances. On the other hand, starting from "allowable means" focuses attention away from purpose and onto opportunity. Justifying the opportunity is business planning, not strategy planning.
- mistaking "control" for value: control is a quality governor, which is an execution-driver, not a value-driver. Control means a proposed distinction may be sustainable; but it does not mean that the distinction is necessarily meaningful to the strategically primary stakeholder. Stakeholders see value as progress. Management should be dedicated to progress, and control is important only when it is an enabler of execution and thus of progress.
- not defining ROI in terms of the offered value to fulfill: doing this sends a message that the work and/or workers assigned to pursue objectives will not be evaluated based on impacts but instead on compliance. Consequently, it distances the worker's motivation from the strategic purpose.
Arriving at a strategic identity can get sidetracked at each of those three points, and an existing strategic identity can likewise be thrown off-track. In learning to change how we change, the learning is crucially dependent on visibility of the appropriate things, but no less so on the credibility of how they appear.
IV.
Visibility and credibility are two-thirds of the way that a changed consciousness can get to adoption. This is why the session format of discovery/investigation and prioritization is common.
The final element is constancy. Assuming a strategic identity becomes sensible because it shows signs of being sustainable for the period set out by the primary stakeholder's need. What naturally goes along with this is that successfully satisfying the need can change the stakeholder, so the strategy should expect to evolve as well. But for most parties, a pervasive plan of investment in the strategy must materialize and illustrate that the organization's impending coherence is predicated on the strategy. This will explicitly describe the reasons why participants can count on their involvement being supported consistently enough for them to realize the benefits that they need themselves.
V.
The biggest question in strategic transformation can easily be whether changes in consciousness allow visibility, credibility and constancy to be efficiently and effectively received and used by key participants. Said differently, while much data and information is evidently critical to the ability to formulate and describe the strategy, the more important issue is the perspectives in which such data or information are found and used. In order to get participants to agree on how to agree, they must have a shared perspective that is consistently appropriate to the subject of taking responsibility for realizing the primary purpose. The four stages in changing consciousness creates that perspective.
Posted by Malcolm Ryder at 7:03 PM | Comments (0) | TrackBack
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 12, 2006
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 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)
November 30, 2005
Environment or Process: which helps Innovation more?
Looked at entirely dispassionately, environment is cultural, and process is political. Add to that the key thing that warrants being called "innovation" -- which is simply a quality of newness that is the difference that has significance.
In practical measure, an innovation is something that is unprecedented and has either compelled or attracted acceptance. But the "newness" is always entirely a matter of context. Organizations, therefore, should understand innovation in terms of whether their basic need is for a cultural change (which alters the way value is defined) or a political change (which alters the way value is pursued).
As for being helped more by environment (culture) or by process (politics), the issue is not so much about one versus the other, but instead about whether the alignment of the two -- a prerequisite for successful innovations -- is more likely to be accomplished by emphasizing one or the other.
Acknowledging that, the opportunity to foster innovation can readily differ from one area in an organization to another, and from one time to another in the organization's operations. That's why innovation opportunities must be managed.
Posted by Malcolm Ryder at 8:16 PM | Comments (0) | TrackBack
November 13, 2005
Competency: the Organization's Inner Self
We know a lot about automating processes, and we do it to improve performance. But performance is all about behavior, the best of which is the competency that drives performance. While processes represent ideal behaviors, do we really expect to automate behavior?
The painful lessons learned from earlier efforts such as "sales force automation" may never be appreciated by today's innovators in knowledge management, operational performance management and social networking -- business's new power rock trio -- unless they recognize the secret: technology works when people want to work, and it doesn't when people don't. This gives technology two jobs: one, make people want to work; and two, make the work fit the people.
That looks like something automation can do. The easiest and most prominent example is found in great automobiles. And amazingly, a lot of great automobiles are now fairly cheap. Yes, mileage may vary with the driver, but the drivers nonetheless do what they intend to do more confidently, as they interact with the car, the road, and other drivers.
In the particular context of improving an organization's performance, this precedent tells us how to open and unpack the phrase "automating behavior", sidestepping its hype. Expanded, it means, "automating the support of desirable dynamics." Usually there are two ways of doing this, used in combination. One is to implement design-level support (of behavior) as "structure". The other is to implement design-level support as "programming". Both efforts are aimed at injecting "regularity" (predictability) into the dynamics -- which is why in both the structural and programming designs we tend to search for, or even create, "rules".
Example: while trying to assess organizations in a "performance" perspective, the notion of "behavior patterns" becomes critical. A behavior pattern is at minimum taken as a symptom of the underlying structure and programming in the behavior. Discovering the pattern, especially an unexpected one, is exciting because it gives a persistent reference point for deciding what (if anything) to change. Basically, we want either more of the symptom, or less. For undesirable aspects, we refer to the pattern for exploring underlying modifications; with desirable aspects, we refer to it for exploring underlying automation. Either way, we expect to find that general rules underlie the occurrence of the pattern. We'll then have our "improvement" programming use (i.e. exploit) the rules.
Because of that, the most critical issue is whether we have discovered the rules or merely invented them. The importance of the rules is to set priorities and consistency to the actual activity. In supporting improvement with rules, programming holds our attention first and longer, perhaps because it is easier to manipulate than structure. But the specific importance of programming is to set limits and methods to the potential activity otherwise inherent in the dynamics.
In that approach, automation is just a programming alternative. Normally, maximizing and fortifying the persistence of desirable behavior is covered by training. Still, in large or decentralized organizations there's the idea that process automation somehow directly manipulates what otherwise would have been unmanaged behavior, and that it does so more certainly for our outward intentions.
In fact, thinking in terms of behavior versus process, the typical expectations are as if behavior's "innate" programming and structure is natural, while process is synthetic on both counts. But then, if we see behavior exhibiting the characteristics of processes, we think we can manage behavior through automation just as we would improve a process.
What competes with this is the idea of self-organization -- of behavior that, without other programming, manages itself.
As the pattern that is discovered, self-organization seems to be the tacit or latent organization. Managers are cautioned about it, about the "shadow enterprise" or the "backchannel organization" stealthily constraining or dictating success or change... Predictably, our new performance improvement frontier is in using programming to manage that -- to manage the inner organization towards the outward performance intentions. If this is going to pan out at all, the first thing to attend to is ensuring that we don't set out to solve the wrong problem.
Accordingly, there needs to be a way to distinguish the key components of the organization's performance make-up -- the "what is" of the organization that builds up the "how to" that it exhibits...
So, you're sitting in the coaches office, looking at the videos of the team that just beat your pants off. You're trying to codify what they do, and you're trying to figure out what makes them tick. Play by play, you can see how they do something, but you're seeing it after the fact... You struggle to come to grips with the apparent spontaneity that they used to beat you -- the stuff you didn't see coming. You keep asking yourself, how did they know, during the play, to do that, then?
Deconstructing the opponent's execution requires understanding how their organization gets its capability both from its formations (structure) and from its routines (programming). But no less important is understanding the real difference between what seems to be ad hoc or natural, versus what is planned or synthetic. This much segmentation pulls up discrete factors that are clearly subject to independent changes but will continually interact to produce the observed results. They're the same factors that will describe the organization you are or want to be.
In attending to those factors, improving and leveraging them towards more effectiveness in their interactions, the definitive programming approach emerges -- that we should think first of cultivation, not automation.
Overall, that target effectiveness is, in real-time demand, the competency of the organization. Cultivating competency becomes the label for an objective that might otherwise be presented as "maturing capability" or "automating process".
In general, these different efforts should be complementary, as seen below.
But this model clearly allows for three ways to tackle a single thing. That is, the whole model could be applied to improving a capability in three ways, or a process in three ways, etc. This leaves us to think about why, for example, a process is different enough from a capability or from a competency to result in them being usually associated with different parts of the improvement model.
Meanwhle, as companies begin to look at social networking to discover and leverage their "inner organization", these companies will need to temper their excitement at the discovery of those behavior patterns with a reasoned approach to making use of them. The most obvious challenge is to first understand the communications protocol that is embedded in the social network, which is of course a behavior issue. Moves from behavior to process may or may not prove to be actual, agreed, consistent or preferred. Additionally, exposing a network may provoke it to change or discontinue before it can be engaged in any pragmatic fashion or agenda other than its own. It is therefore very unclear as to whether automation or maturity are even relevant formal management concerns until after cultivation of the network has been identified as a desirable opportunity.
Posted by Malcolm Ryder at 8:02 AM | Comments (0) | TrackBack
October 29, 2005
The Future of Change
Author and management practices educator Sid Kemp posed a question of whether production quality really drives financial success. Due to competition, we can assume that not having quality might prevent success, but does having quality "cause" it? If not, then what is the rationale for the expense and intensity of continuous quality improvement, a competency-based change program? After all, if change is the only business constant, how does continuous improvement apply to the agility needed to compete? The easy answer is to continuously improve agility. The hard answer is to determine what that means and make it work.
Asked Sid, "a question came up while I was thinking about quality management and reading up about Japan -- famous for quality but ailing economically despite that. What kinds of focus, what changes, could we say will be *beneficial* for the next ten years, even if we don't know what we will be producing?"
On the one hand, a 10-year forecast is not so easy. China will be the most powerful country in the world but we don't know whether it will be good for just them or good for everyone. Certainly the U.S. is the only precedent, and the jury remains out on the subject of our "goodness". Nonetheless, since the climate change, the globalization of politics, and the information-economics revolution are all upon us, it stands to reason that we need more clairvoyance and more security without creating more divisiveness. The more we can find good reasons to cooperate with each other, the better off we will all be. The age of Win-Win is now or never, and its implications certainly mean at least a first step of "enlightened self-interest". The biggest threat is "the telling of lies". It will be interesting to see if the practice of education can evolve towards a focus on Win-Win awareness.
But Sid posed the challenge in particular: deciding Beneficial Focus and Beneficial Changes vs. the uncertainty of future market requirements and product/service categories. The issue calls for considering the relationship between performance management and value management.
First, we define "beneficial". It has several flavors. But if we assume above all that we intend to keep our professional operations self-supporting (for continuity) and attractive (for growth), then we can work from the general notion that "beneficial" things are things helping us to achieve those two goals.
Then we break it down into the supply and demand issues that pertain to both goals.
FOCUS:
On the supply side, there are aspects related to our being Producers and Providers. We use and build the environment and the items in it.
- We should be good at doing that, as in being mindful of our intent and relevance in our time and place, so the perspective is one of Competencies.
On the demand side there are aspects of our being Partners/Community Members (collective) and Stakeholders (individual). We receive and are affected by the output of our acts and the acts of others.
- We should meet the requirements of our relationships, and meet the needs of being individuals, so the perspective is our Responsibilities.
In the picture below, we see how Competency and Responsibilities cross-reference, creating four focal areas: Ethics, Values, Roles and Missions.
The general issues (as focal points) are these.
Ethics: intent vs. requirements (sets position within a quality network. We used to say "chain" instead of "network" but we now know better. Quality network includes legal, cultural, industrial and other institutional players, reflecting regulations, norms, practices, etc.)
Values: intent vs. needs (sets position within a demand network)
Roles: relevance vs. requirements (sets position within a supply network)
Missions: relevance vs. needs (sets position within what we've usually called a value network)
So the idea would be to map attention to those four issues against the two goals:
(1.) keeping our operations self-supporting; and,
(2.) keeping our impact attractive.
This 8-part mapping creates a model for defining "the way we want to be."
As an exercise, I began assigning big company names to the four focal points, as examples of companies that promoted the issue or violated the issue. For example, Enron clearly violated the Ethics issue; Phillip Morris's marketing wants us to believe that it is promoting the Ethics issue; and a company that send free AIDS drugs to Africa is definitely promoting it. Dell is a master promoter in the Mission area; WalMart is a promoter in the Roles area but a violator in the Ethics area. Disney is a master promoter in Roles. Ford Foundation is a master promoter in the Values area. Microsoft violated Ethics but promoted Roles and wants to be seen as a Value promoter. Etc.
CHANGES:
There will be changes that are intended or unintended, and needed or not needed. So, there are four basic types of change:
- intended & needed (e.g. goal fulfillment)
- intended & not needed (e.g. innovation)
- unintended & needed (e.g. luck)
- unintended & not needed (e.g. discovery)
These four types of change can occur within any of the four Focal Areas. So, the 4x4 cross-referencing here gives 16 points of change. Across the possible changes, our overall question remains "which ones should we expect, and which should be prioritized?"
We can only make educated guesses as to which cases of the resulting 16 kinds of changes will emphatically occur and be "critical"... With enough information we could start working out our guesses the same way meteorologists work out forecasts. This tells us right away how intensive and daunting the effort would be.
So the challenge will be generally like this:
1. Understand where (and why) we want to be positioned in terms of the four "focal areas"
2. Master an ability to monitor responsibilities and detect trends that are relevant to the scale of our operations
3. Master an ability to rapidly acquire and deploy effective knowledge (not just data or info) for building competencies that will support and align the desired positions
In the end, there will be some emotional maturity required, to keep a grip on the idea that something helping you reach a goal is Beneficial even if its immediate consequences involve some pain or don't offer gratification. And furthermore, just because something is beneficial doesn't mean you're going to reach your goal; instead, you proceed with the idea that you won't reach your goal without the benefits. Finally, gratification and benefit are not the same thing, and there may be many gratifications (planned or unplanned) that occur but should not be confused with benefit. As I admitted to Sid, I love martinis, but they're bad for the brain cells and the liver.
Posted by Malcolm Ryder at 8:12 AM | Comments (0) | TrackBack
October 17, 2005
Why Projects Fail
It seems obvious that if any project is going to be rated a success, there are three high-level issues to successfully manage: Quality, Timing, and Expectations. Mismanagement in any of the three areas pulls the project towards what would be considered "failure."
But in looking at the project as an action, failure should be understood in two ways: in terms of "technique" and in terms of "outcome".
Every project is designed with the presumption that its technique will cause the intended outcome, but the execution of the design may involve an actual experience to the contrary. One point to make clear here is that it is possible for execution to be very good without the intended outcome being generated. This is because a project deliverable is not in itself an impact -- instead it is just a resource that has an impact when utilized.
In every complex structure, the potential value of its capability is designed in, and the actual value of the capability is the result of its reaction to stress. Projects, which are complex structures, are just an example of this.
All projects have the same basic function -- to *produce* something that, according to the specifications, wasn't already there. From the viewpoint of the designated recipient, "production" takes place in a variety of ways that might include buying, borrowing, and/or building the specified "product"... Depending on the recipient, it may not matter how the production was conducted. But from the management standpoint, what these three things have in common is that in their execution each one will depend on (deep breath) a "process" that is used to account for progress in the terms of a "project." It's noteworthy that the form of the process might need to adapt to the project's needs, either in appearance or in actual conduct.
This particular accounting is why, within every project, there is a group of what we should call "progress requirements".
The role of a manager is to ensure that actual technical progress is aligned with actual outcome progress.
A progress requirement becomes a criterion against which the processes that are used within projects should be selected and controlled. Therefore, one source of project failure can be *execution* -- namely, inadequate process management, including inadequate process integration.
*Impact* failure is an evaluation taken as a fact. This is interesting because of the law of unintended consequences, and because not all unintended consequences are undesirable or without great value. But to the point, since projects do not evaluate themselves, the perspective and terms of the evaluators are the place where anything that happens can make the ultimate difference. Inadequate precision and stringency in the terms of evaluation are therefore sources of project failure. Notably, this inadequacy can include unresolved conflicts and omissions amongst multiple stakeholders. Producers are stakeholders, too, along with owners, operators and users.
Since processes and stakeholders don't sit still over time, alignment of technical progress and outcome progress in the project must be defended dynamically, not statically. If managers do not continuously create effective relationships between processes and stakeholders in a project, then misalignment will pull the "project" towards failure even though "production" may have never halted.
Posted by Malcolm Ryder at 9:14 AM | Comments (0) | TrackBack
September 23, 2005
When is a system not a system?
Peter Senge kept coming to mind after a handful of exchanges with some colleagues about organizations being systems.
To grab a really crisp definition of systems that I knew I'd seen from him, I checked in at Frank Patrick's blog Focused Performance where lots of crisp things get presented in great context.
Frank quoted Peter:
A system...is anything that takes its integrity and form from the ongoing interactions of its parts...Systems are defined by the fact that their elements have a common purpose and behave in a common way, precisely because they are interrelated toward that purpose. - Peter Senge
What's tricky about this definition is the ease with which it's clarity seems self-evident. I can run with the statement up to a point, but only through another point first. Let's be sure we know that when Peter says "interrelated", he's giving us a verb and not an adjective. The elements of a system don't inherently know that they have a common purpose. That is, they have to be "told" about their commonality somehow. The telling involves a lot of things like engineering, configuration, assignment, regulation, and so forth. In other words, we "define" a system by deciding what purpose and behavior it is that the elements have in common. What Peter is really indicating is that if we see a bunch of "elements" and can't decide what is common in purpose and behavior, then we haven't identified a system. In another case, though, we might recognize what we'll call a "natural" system -- in which case we're just saying that the force dictating the system is not our willful invention.
Which brings up another question: how do we know something is an element before we have actually "created" the system by defining it? Usually this puzzle can be solved by taking what we can readily detect, and imagining it as a component that has the potential to be an "element". Once we give the component a job, it can become (or at least contribute to) an element of a system. Even if the inherent capabilities of the component is what gives us an idea for a system, the job actually comes from our idea of the system and may not even ask the component to do what it otherwise might do best. (I really ought to get that PC monitor off of those old phone books, but you know the monitor height is just perfect with them...)
Something related to this is that the more parts the system has, the more chance there is that a subset of the system's parts can develop a new interrelationship and behavior, diverging from the overall system model. So even when we know what components "belong to" a system, we might find that the elements are not sufficiently available.
This gets to the other important thing to think about: the system might be invented or it might be discovered. When it is discovered, it might not be the system that we wanted to find. Then there is the challenge of what to do about the difference. The reason why this is finally so important is that we often invent and activate systems that develop unanticipated dynamics and become different systems from the one we thought we invented. In effect, the system might "find" its own purpose. When that happens, how quick are we to detect it? Just because something's parts are "interrelated toward a purpose" doesn't mean it is cooperating with us.
This reminds me of my working definition of "mythology", which is "occasions when prescription substitutes for description." And therein lies the wariness I have about Senge's definition of a system. I don't disagree with the definition, but I worry about it's use. We should all be careful to find the system that is really there, and not just the one we expected or wanted to see.
The usual practical interest in systems comes from an interest in control. But between engineering a system versus training or coaching one, and between discovering a system versus synthesizing one, the variability in what we should do about systems is pretty vast; thinking in terms of systems gives a distinctive point of view but it's probably the view from the tip of an iceberg. We can be pretty sure that controlling an organization is an iceberg.
Posted by Malcolm Ryder at 7:37 AM | Comments (0) | TrackBack
September 1, 2005
IT Operations Intelligence - The Business Logic of the CMDB
Without question, business is overwhelmingly predicated on the ability to service needs through leveraging IT resources.
The ever increasing frequency in the variation of business needs means that there must be an increasingly intelligent mechanism for determining the current appropriateness of the available resource for the need, on demand.
I.
Technical advances have made it economical to store and communicate increasingly vast amounts of descriptive data about resources. It is now feasible to at least federate myriad descriptions into a single logical reference database.
But a key issue is how to actually increase the effective intelligence of the usage mechanism, which means increasing its ability to determine the relevance of the data in qualifying the resource for active assignment. Meanwhile, an accompanying problem is of course to ensure and confirm the availability of appropriate resources.
The sensible thing to do about those issues is to use the information to develop profiles of resources that allow quick identification and anticipation of productive associations with existing and predicted business needs.
But with the pace of change and the proliferation of business process variations, that would be a logically improbable achievement unless there was some framework of business demand that could help to define and anticipate the most likely requirements that resources need to meet -- thereby bringing order to the task of vetting the ocean of descriptive data by relevancy.
II.
For example, a business process makes functional requests that require the support of appropriate resources; this offers a step towards making a framework (or frame of reference). The functional requests establish what is appropriate by specifying resource characteristics that are known or predicted success factors. In reality, that specification may just as likely be discovered through trial and error (i.e., testing) as it is proactively designed. Still, in either case, any given resource can (at least hypothetically) be certified for its compatibility to the functions of a business process.
Then, by cross referencing multiple business processes, it will eventually become evident that a given type of resource applies to the range of constructive assignments. Patterns of both common and exceptional functional dependencies on the given resource-type emerge in more or less architectural perspective. Particular instances of a type of resource can then be audited and rated within their type or class.
Conversely, preventing and remedying destructive (or counterproductive) resource assignments means determining in timely fashion that an existing or probable mismatch of resource characteristics is imminent versus the expected demand.
Related to that, another challenge is that a resource, as a discrete unit, may not have all of the characteristics necessary to meet the requirements. In this case, its relationship with other complementary resources may allow it to offer a virtually complete profile for the specifications of the business need. Here, an accompanying problem can be that existing inter-resource relationships may actually reduce the effective availability of a discrete resource for duty, by too strongly capturing the resource within a virtual profile that is inappropriate for the current demand.
III.
Creating the composite of a resource's functional assignments and inter-resource relationships, the characteristics making up the functional profile of the resource are its configuration.
In this light, a defined configuration's lifecycle, from inception to retirement, is consequential only to the degree that at any time it's current phase is associated with business demand.
That association -- seen in terms of whether the resource is both appropriate and available -- translates into quality and capacity management issues mainly significant for addressing the performance of the business processes being served.
But the configuration itself -- seen in terms of the patterns of its utilization -- translates into access and impact management issues addressing the measurable value of creating, deploying, modifying or retiring the configuration in the face of feasible alternatives.
IV.
We can support management decisioning through storing descriptions in a configuration management database (CMDB) and analytically processing them.
As the nexus of business process management and asset value management, configuration management uses and controls the view of resources that evolves in those two dimensions -- emerging as an explanation of how to translate the IT architecture from an investment to a benefit.
Just as strategic product management connects market requirements to engineering, configuration management strategically connects business process requirements to asset management. The connection can be expressed as responsibilities that formalize the major intersections or "coordinates" of the two dimensions.
As seen in the following framework of such responsibilities, the dimensions are:
- the utilization performance spectrum (as in market or business process) ranging from enabling to strategic -- i.e. from a willingness to exploit the resource, to a need to optimize it;
- the production value spectrum (as in product or asset) ranging from planned to actual -- i.e., from initial discovery of an appropriate asset to proactive release of the asset (into production).
(click here for enlargement.)
While the framework does not intend to presribe any overall method for managing resource information, it does provide a context that presents resource description data as business intelligence. As an example of the implications of the framework, the illustration further observes that the intelligence can be approached from the general operational perspective of aligning resource versions with business practices that operations logically direct through usage accounts and usage models -- providing effective management of services.
Note: in this framework, the idea of "discovery" is important to the purpose of communicating that whether assets are built, borrowed or bought, the key business production issue is for the business process to find an appropriate available asset for use as a resource.
Posted by Malcolm Ryder at 8:58 PM | Comments (0) | TrackBack
The Cost of Value
Walk into a meeting, say the word "value", and tally up the other words that people thought you meant.
If your results look like this:
- profit
- performance
- ROI
- economy (as in economical)
- impact
then you already know why the next thing you say about value might easily split the audience into different groups. This split readily occurs based on how much their concerns are:
- goal-oriented
- process oriented
- resource oriented
The interesting thing to note here, though, is that each group at the meeting actually blends together some level of sensitivity to each of those three concerns, and it's the blend that makes the difference in how they understand you when you say "value".
I.
As articulated by the picture below, the blending shows up in the form of three main questions or "attitudes" that people bring to discussions of value. Essentially, what happens is that new ideas that claim to have value are considered in light of what related changes to current affairs are thought to be requested. The three questions are mental placeholders for the assessment of the current affairs:
1. What should we be doing? This looks at the list of current obligations and questions things in terms of priorities.
2. How are we doing? This looks at the way things get done and questions whether those ways -- capabilities -- are effective enough (successful and appropriate).
3. What could we be doing? This looks at whether the assumptions that have driven current choices for engineering benefits are still more logical and exclusively relevant than other credible assumptions that would also represent opportunity.
From the picture, we can also understand how discussions can quickly focus on certain "levers" such as:
- how costly is a resource?
- how risky is a process?
- how beneficial is a goal?
These levers typically show up as hot-buttons -- "justifications", "success factors", and/or "criteria" -- in the consideration of a proposal. Our picture also shows that each lever (such as "cost") easily gets a shared audience (in the case of cost, both the "commitments" and the "progress" crowd). It is not always the case, though, that the audience identifies its shared concerns as readily as its differences.
II.
Addressing multiple stakeholders with a single proposition means investigating shared concerns as much as possible; having a logical approach to doing that should make the problem easier to solve.
But if we go back to the list of those synonyms provoked by saying the word "value", things initially seem to be all over the map.
To sort this out, we can use simple working definitions of each synonym, and use the definitions to map the synonyms to our picture.
- performance: a measured level of achievement towards a target outcome
- impact: the measured difference between the quality of the current state and the quality of the proposed future state
- profit: a net gain in assets beyond the total allocated cost of effort.
- ROI: the difference in resulting assets between the proposed consumption of a resource and the current consumption of that resource.
- economy (as in economical): the efficiency of converting a given level of assets into a given level of resources.
As we now see, some of the terms -- profit, ROI and economy -- are actually types of the other terms -- performance and impact.
Furthermore, performance and impact both refer to the change that has occurred between the current circumstances and the projected or forecast circumstances. They are generally similar. But we can see that performance is really a context-specific description of impact.
In the typical Archestra terminology, "value" is identified as "the importance of the difference". The point is to determine whether the proposed value will test "positive" for being not just "different" but "better" than what is already in hand. The different audience perspectives explore the idea of "important" or "better" in respectively different ways:
What type of "resource" is consumed or created?
- does it increase conformity to obligations?
- does it decrease obligations that are liabilities?
What is the significance of having the new kind of resource versus the old, OR of having the new mode of resource consumption versus the old?
- is it more manageable for the current efforts needing resources?
- does it enable a new or alternative effort
How does that significance logically support the desired future state?
- does it make the path to the future state easier or safer?
- does it provide a path where previously there was not one or where in the future there will need to be an alternative?
III.
Now it is more apparent that the range of issues under the topic of "value" covers a lot of ground that is not crossed by counting money.
But because so much of business is predicated on having the assets necessary to fuel future effort, the overall sense of value typically "rolls up" to an estimation of the change of assets. In fact, it is usually the case that the shareholders of a business will tolerate a wide range of goals and even frequent change of goals as long as the change of assets is "profitable". Perhaps unscientifically, both economy and ROI are assumed to always be underpinnings of profit unless proved otherwise. This finance perspective is in high contrast to the main issue for stakeholders, which is that the way the business does things should be consistent with protecting the operational effectiveness towards the goal.*
Consequently, it seems that shareholders are much more tolerant of change than are stakeholders.
The generalized implication is that when "value" is proposed in terms of effectiveness, stakeholders perk up to catch clues about capability; when "value" is proposed in terms of "advantage", shareholders perk up to catch clues about opportunity.
Although distinct, the points-of-view are not mutually exclusive. In fact, as our earlier picture shows, the factor in common across those two groups is "risk". Although everyone knows that it takes money to get anything done, when the subject is "value" the sense of a related cost is not so much about dollars as it is about the tolerance of uncertainty.
In short, the "cost" of value is risk.
* See an outstanding discussion on stakeholder versus shareholder orientation, in an article about "social enterprises" called
How Organizations Create Social Value, by Manda Salls.
Posted by Malcolm Ryder at 6:27 AM | Comments (0) | TrackBack
August 20, 2005
Invention, Improvisation and Innovation
I.
Every day, operations proceed with essential concerns about continuity and direction, within this same basic value-management cycle:
- Can we do it? / What are the outcomes? / Why is that important? / (Repeat) -
At each point in the cycle, operations managers presume that the desirable answer is a logical result of cause-and-effect. Putting pressure on each point, meanwhile, are significant forces (such as, respectively, skills and knowledge, location, and competition) that are tough-to-manage variables affecting the actual answer.
Now, with unexpected or rapid change occurring independently at each of the three points, as well as across them, more and more time is spent trying to overcome complexity in determining the difference and the linkages between intended cause-and-effect versus actual cause-and-effect.
Without this determination, management cannot know whether the most effective operational path to meet currently targeted ultimate objectives is through the existing environment or through a modified environment in the future.
There are many ways to conduct an environmental review that generates both an assessment of the current environment and a design of a future environment. All of them have the purpose of solving the same "You can't get there from here..." problem, by either repairing critical stepping stones or building a new path.
But always just as important as the path itself is how you run on it. For organizations whose management feels (rightly or wrongly) that it is in a known, locked down environment and needs more effectiveness from its activity within that environment, that train of thought is increasingly important. Here is where Invention, Improvisation and Innovation have pushed to the foreground, being additional ways that management can run.
Each option is an idea with important cache that, if abused, will reduce it to a buzzword. To prevent doing that here, let's point out the source of each one's attractiveness --that is, the associations that explain why each merits any attention.
a - invention: relates to products and productivity
b - improvisation: relates to capacity and agility
c - innovation: relates to differentiation and advantage
At a given time, the relative attractiveness of any one of them likely reflects the organization's current estimation of its performance problems. Any week spent reading the management trade mags will bear this out in the columns of strategic advice.
Meanwhile, it also seems easy to indulge the implication that the group of three line up as a "chain" of success factors, a-b-c. Indeed, what often happens in discussion is that the lines are blurred between the three, such that any one of them appears to be a spoke leading to the the same virtuous hub called NEW -- which reduces them to being synonyms for each other, or to being alternatives just requiring some pragmatic prioritization.
Those views are not always the case. But at worst case, misperceptions readily lead to misinterpretation and misuse. For the sake of being more proactively positive and avoiding "lost opportunity", we can look at the way that invention, improvisation and innovation generally get traction, and use that visibility to guide ideas about how to most sensibly incorporate the interest in them, as part of management.
The following diagram illustrates business components and relationships with which managers generate business capabilities. At any of these same touchpoints, management can manipulate capabilities with a range of options including invention, improvisation and innovation. But effective organizations take invention, improvisation and innovation seriously by managing the operational environment necessary to see them through the value cycle of can we do it, what are the outcomes, and why is that important. The high-level view shows infrastructure, goals and culture holding down the three points in the value cycle.
The picture's high-level story is about the complexity involved in the balance to be struck between value and its associated risks, and likewise between requirements and the options for meeting them. Respectively, high-level improvisation and innovation engage those tasks.
Let's look at invention, improvisation and innovation one by one, to start factoring in their opportunity, purpose and effect.
II.
In its literal root sense, Invention refers to "finding something within". Practically, this sense is associated with exploration and experimentation, the two activities that typically host and court the experience of invention.
Because both of those activities can be structured, their practice may be placed on a supporting mechanism designed to make them accessible, accountable, regular and persistent. We can see that underlying mechanism as a combination of methodology and infrastructure.
But once methodology and infrastructure are in place, they become the key constraints on invention. The challenges become to maximize the effectiveness of leveraging them, and maximizing the ability to re-engineer them if necessary. The importance of this is in the need to know whether they are promoting invention more than they are inhibiting it. As we increasingly find in the arena of knowledge management, invention is a fundamental daily activity necessary to site-specific problem solving in the organization. Nonetheless, an equally big challenge is to commit the investment in that methodology and infrastructure to actual invention as opposed to routine production -- otherwise the methodology and infrastructure are unlikely to change towards effectiveness. This commitment is seriously challenged because of the similarity thatinvention has to production activity. The similarity makes it easy for the organization to appropriate the means for one purpose instead of for the other; so invention must compete for priority in order to keep its means:
PRODUCTION
- manage compliance to known causes that effect specifications
INVENTION
- Manage attention to assumed causes that effect theoretical outcomes
If the organization does not have theoretical outcomes representing high mission priorities, then it is less likely to find the fortitude for sustaining use of its methodology and infrastructure to drive invention. This would likely prevent R&D in infrastructure and methodology. With the pace of change in business requirements today, that would be crazy: who was it that said the definition of insanity is doing the same thing over and over but expecting a different result?
III.
Improvisation, in its literal sense, refers to "the unforeseen". From that, it attributes two key characteristics to activity -- unplanned, and extemporary (casually observed as in "the heat of the moment" and "at hand"). Importantly, it involves no lack of understanding of what is to be produced; rather, it is concerned with how the production was organized. Being aimed at a target "effect", improvisation seems to be related to invention. But the real difference is that while invention proceeds according to a plan to make something of undetermined value, improvisation is unplanned but aimed at making something of determined value. The even more important issue with improvisation is that, unlike invention, it occurs under production pressure: that is, an acceptable outcome is already described and targeted, and the means of generating it must succeed within the excited restrictions of available time and materials.
In short, the problem in improvisation is not so much "product" as it is "process". As a shorthand for what could be another whole discussion in itself, let's think here of process as navigation. In this way it is easier to recognize the real significance of improvisation as a production mode -- which is not that it is any less rigorous than following a plan, but that it relies on a different frame of reference for guidance. The star-charts and weather forecasts of the operation's environment -- such as scorecards and dashboards -- must be the basis of decisions about pace and course corrections.
For management, the decision to improvise is challenged mainly by the dual concerns of accountability and risk. Thus, the choice to improvise must be made through prioritizing effectiveness over the expectations of accountability and risk. Deep experience, for example, offers a cognition and frame of reference that allows a manager to abandon what seems to be a failing prescription and improvise instead. We tend to discuss this in terms of "instincts", but for most managers, confidence in actually executing this way requires an understanding of the difference between process and "technique" -- with confidence in technique. Both process and technique are ways of describing "the method of procedure", but the difference is that process is specifically about the method of activity, while technique concerns itself with the method of using available tools and materials. Consequently, the key contrast is between improvisation and construction:
CONSTRUCTION
- organize production procedure around accountability and risk standards
IMPROVISATION
- organize production procedure around resource availability and logic
Usually, for improvisation to take hold, the organization's management must decide that in the face of a construction's projected inadequacy, the consequences of ineffectiveness are too harsh to tolerate. This explains why improvisation is most often considered for issues where unexpected failure looms. But it is also the case that improvisation serves as research for future construction-process improvement. So improvisation becomes an extremely valuable experience for enhancement through re-invention...
IV.
Taken most literally, innovation has the fascinating responsibility of "introduction". In turn, introduction has a core meaning of "to lead into" a position. This accounts for why every vendor touts itself as the "leading" whatever, because the vendor stakes its argument for your attention on the idea that it has "introduced" its particular distinction into some context with which you identify. But if all comers are "the leader" then what matters is what might be new about each one's effect. As noted frequently in content here in the Archestra collection, there are at least three main ways of being significantly "new", and the value of each will obviously depend on how relevant it is to the occasion at hand:
- new solution for a new problem;
- new solution for an old problem;
- old solution for a new problem.
As we know, any of those results might come from invention or improvisation... but to the extent that this is true, it occurs because there is a concept of "solution" that is actually applied to a problem. On the one hand, this application might be speculative. On the other, it might be highly strategic. On either end of that spectrum, motivation levels may be just as important. The issue is to determine the source of the motivation and whether the source remains a catalyst or driver. In short, is the innovation "needed"? The most important context for determining the answer is likely to be one that examines priorities for innovation versus improvement:
IMPROVEMENT
- increases the value of the result by enhancing its current type
INNOVATION
- increases the value of the result by changing its type
The key challenge to management is that innovation creates pressure on competency at an elemental level, possibly interrupting the terms of value already established for resources through their existing configurations. While the point of innovation is to get to a result, the practice of innovation requires that organization and competency are not misaligned through a redirection provoked by innovation.
V.
That leads us to the observation that infrastructure must be balanced against culture if the organization is to "get there from here."
In our environmental diagram (repeated below), this idea is illustrated as components and relationships that management can manipulate, with a range of approaches including invention, improvisation and innovation. Organizations take invention, improvisation and innovation seriously by managing the operational environment necessary to see them through.
Again, the picture's high-level story is about the complexity involved in the balance to be struck between value and its associated risks, and likewise between requirements and the options for meeting them.
At any given time, the current operational environment plays mediator by determining what types and levels of value correspond with given types and levels of risk. Meanwhile, norms (primarily including expectations and standards) usually set the terms on which operational alternatives are committed to requirements.
In situations of potential invention, improvisation or innovation, the broad middle zones of environment and norms are where change (through management) creates the energy and leverage that drive potential results.
VI.
In the diagram, the key change-points can be seen within three perspectives that comprise the environment: infrastructure, goals, and culture.
Strictly speaking, all three are generated by invention -- with the form of invention variously being physical or conceptual, essential or political.
Each perspective includes a characteristic value objective that is associated with a characteristic issue of risk. For example, infrastructure value is essentially expressed through management's ability to assure its availability, but meanwhile the risk inherent in infrastructure is in the configuration that it currently presents, which is also a consequence of better or worse management.
Typically, innovation adopts a new example of the value objective and calls for the risk to be realigned to it through the environmental factor. The major precedents for this have been reorganization and re-engineering, but the main observation that this illustration makes is the layout for integrating a variety of internal innovations. This puts the organization on an evolutionary path to threshold-level ability for producing and supporting a successful external innovation.
VII.
Two facts common to enterprise change also distinguish one organization's efforts from another:
- Direction creates focus; but different cultures have different ideas, which sets or resets direction.
- Competency creates opportunities; but different norms set different tolerances, which motivates or inhibits competency.
Management is working on direction when it tries to link goals to culture. When it tries to link infrastructure to goals, it is working on competency.
Improvisation navigates the potential connections in real time, which is the prerequisite for what the enterprise calls agility. Thus, improvisation works out alignment across the perspectives rather than within them.
However, the horizontal alignment effort that management has usually committed to is process improvement. In the big picture, that helps opportunity, but it only affects things from one perspective. Its relevance to goals and direction is still critical to protect its power to enhance the overall benefit of the operation. Infrastructure must be balanced against culture if the organization is to "get there from here..."
VIII.
A final observation about the model in the diagram is that it is an abstract model, not a literal one. This means that it is "scalable", because it can be applied to a small end-to-end effort as well as to a very large one. Wherever an effort can be described in terms of the related options, norms and requirements, there will be aspects of the effort paralleling "infrastructure" (the means), "goals" (the authorizing target results), and "culture" (the permissions and tolerances surrounding the effort). That means, according to the model, that invention, improvisation and/or innovation may be applicable.
Furthermore, since small efforts combine to complete larger efforts, we can see in a logically abstract sense that, for example, an innovation on one scale might be a component of improvisation on a higher scale.
Is this meaningful? As an example of "yes", consider that an innovation in infrastructure might enable an improvisation in business process -- one way to describe the architecture of a breakthrough to agility.
Posted by Malcolm Ryder at 7:51 AM | Comments (0) | TrackBack
August 13, 2005
Business-IT Alignment: Three Levels of Change
It's most commonly said that the alignment of IT and Business focuses on the way that IT "delivers business value". Because of the pace and intensity of change within and around the business, the alignment effort emphasizes the need to define and protect both the deliverables and the integrity of the delivery path.
Said more carefully, IT delivers support of the value-capture modes of the business. This clarification points out that business value is not just "created at the IT point" and then run through a gauntlet of business issues on a delivery path.
But even that should be put more precisely. Instead, interlinked value-creating modes in a "value chain" are managed by the business, and IT is managed distinctively at each link, thus affecting the way that business value is ultimately realized.
Viewing that value chain as a hierarchy of dependencies lets us associate certain changes with different depths or levels of intervention, while still seeing that changes can simultaneously and independently occur on all levels. The challenge of alignment is to identify and coordinate these changes.
From the business point of view, change in the business affects the integrity and performance (i.e. success) of that "value chain" on three general levels.
One change level involves the definition of the basic components that are used to construct the business's production tools and procedures. Change alters the quality of the components.
Another and higher level involves the arrangement of the components into the various forms of facilities, resources and locations that the business uses in daily execution. Change alters these forms.
The highest level involves the agreements and expectations by which the business executes its activity towards goals, opportunity, and stakeholders. Change redirects activity and the demands it makes on underlying levels.
The following tabular diagram illustrates the active business elements in the management of the value chain versus change.
- A software application is taken as an example of IT being managed for alignment.
- As shown by the far left column and the center arrow, management expectations drive and constrain the cultivation of value at each link or level.
- These business expectations bear particular ways that IT functionality is developed into business resources.
- In turn, the effectiveness of those approaches is leveraged through operational management that works to confirm and conform the IT utilization to the business expectations.
Alignment must be seen as a business success factor if change across these levels is going to be strategic instead of merely opportunistic. Because the different levels and types of change are each independently sensitive to the strengths, weaknesses, opportunities and threats of the organization, management must continually view and assess the benefits and risks that various changes present to the value chain -- specifically, lowering the risk of driving benefits to the business bottom line.
Posted by Malcolm Ryder at 8:20 AM | Comments (0) | TrackBack
August 8, 2005
Strategy vs. Governance vs. Alignment
When is a solution not a solution? When it solves the wrong problem!
Hunting for solutions is so complicated because it is a multidimensional issue.
First, solution approaches vary:
- re-engineering, or "designing the problem out"
- innovating, or defining a new relationship of a technique to a task
- renovating, or correcting mismatches of current configurations to current requirements
Additionally, a choice must be made between pursuing the root cause of the problem or pursuing something less (such as symptoms). This choice is affected by:
- timing
- execution risk
- cost
- agreements
And not least of all, stakeholders affect the prioritization of the solution effort. In general, stakeholder concerns include:
- solution scope
- benefits and liabilities
- safety
These issues of approach, range and priority are almost invariably brought up in discussions about strategy, governance and alignment. Relying on the guidance of these discussions, a very substantial checklist of action items can easily be built. This level of awareness is a critically useful shot of clarity, but how do you decide which action items are the "right ones" to put at the top of the list?
First, defining the list's "top" region should follow the technique of rating alternatives according to both importance (the need for a certain impact) and urgency (the starting time needed to ensure likely achievement of the impact). Items that rate highly on both counts go to the top.
This won't prevent high-priority issues from competing with each other. And the competition doesn't mean that something big should be dropped... But the different items should be distinguished by their purpose.
This is where most of the confusion reigns in the literature about strategy, governance and alignment. There is no debate that most of the concerns in any of those articles and studies are vital to preserving and improving business opportunity, but that doesn't automatically communicate how to incorporate the advice at the appropriate times and levels of the organization's operations. Such incorporation is a critical success factor to the solution really being a solution.
Too often it seems that every concern is trumpeted as an item essential to every cause, whether the cause is strategy, governance or alignment. But if there is any importance to the different names for these causes, then how can the most effective distinctions between their respective basic concerns be drawn out?
The quickest way may also be the most reliable and comprehensive. Often the difference between the causes is mainly a difference of "perspective" -- and perspective is something that by definition is generated by looking around from a certain point of view. It is possible to see the same item in more than one perspective (or literally, from more than one point-of-view), and this is how the same item comes up in different stories. But the item's meaning can and often does vary with the perspective. The trick is to detect that difference, and this relies on point-of-view.
We can describe the key organizational management perspectives called strategy, governance and alignment, as follows:
- Strategy: addresses needs; needs are about the values of the organization, which reflect its idea about where it is in the scheme of things and what importance is attached to that position.
- Governance: addresses requirements; requirements are about the critical dependencies that exist amongst interactions that define the organization's functioning.
- Alignment: addresses specification; specification is about the particular definition of deliverables that are measured for their level of impact (whether benefit, neutral, or liability).
How confident can we be that these distinctions are correct?
The first way to test that confidence is to simply imagine if there is any importance to the initiatives for strategy, governance or alignment if they did not focus on the key components in these descriptions. Strategy that does not organize things around needs is pointless. Governance that does not organize things around requirements is pointless. And so on.
The second way, in case the first is not decisive enough, is to look at what the three perspectives respectively show us about the organization's current state and therefore what kind of problem is at hand. Generally:
- Failures of strategy pertain to the way an organization became disassociated from the basis of the opportunity that it pursued. It lost relevance.
- Failures of governance pertain to the way it became unable to control the dynamics of the opportunity pursuit. It lost viability.
- Failures of alignment pertain to the way it misunderstood the importance of its output versus the way its stakeholders did. It lost value.
As a result, we can finally understand the differences in an even more rudimentary way:
Is it time to change directions? -- Strategy
Is it time to change the rules? -- Governance
Is it time to change measures? -- Alignment
In order to follow up on any of those three things, certain actions prove to be constructive, and some of those actions prove to be constructive in two or even all three of the areas.
This further explains the recurrence of certain points and advice across all the various topics. But the key to their being "successful" solution components is to understand why it is important to achieve the difference that they make, set expectations accordingly, and then use them explicitly for that reason.
Posted by Malcolm Ryder at 11:08 AM | Comments (0)
August 4, 2005
How Maturity Models Drive Timely Value-Capture
The most basic problem of IT alignment with Business is the need for IT to improve business capabilities within the business's ability to pay.
Of course, the ability to pay is supposed to be a product of good capabilities, so... the question is this: how far in advance of its payoff can we afford the initial capability improvement?
This reminds me of the promise of cold fusion, wherein two key things are at stake. One, the nuclear reaction must produce more energy than it consumes. Two, the reaction must be manageable, as in non-destructive in room-temperature conditions.
In the business scenario, money is the energy, and change-impact is the risk of disruption, while the existing infrastructure is the "room temperature"... And there are big ambitions that come along with that scenario; but are they any more viable than cold fusion, or is it still mostly hype?
Here's one ambition: most capability improvement is "funded" in advance; let's imagine that the net economic gain from the ultimate improvement is as simple as subtracting its cost from the price of selling the capability.
Here's another: most risk of change-impact is prioritized by severity of interference posed to designated parties; let's imagine that the attractive new capabilities are usually really well siloed.
Now, when I snap my fingers, wake up… that hot new capability and its economic value boosting powers are the children of complexity and integration, not simplicity and separation. Why?
Likely, because the capability is, operationally, a process that is orchestrated and optimized across multiple functions, events, occasions, and/or organizations. That's a lot of opportunity for interference. And the net dollar gain tends to be reached by gradual accumulation of payback, not all at once. That's time during which the unexpected can happen.
So, while we're waiting for the dollar gain to pile up, we're carrying a lot of risk. There is an initial risk of disruption to existing conditions, and there is additional risk of discontinuity and error in the downstream run-time exercising of the new capability itself. Hmmm...
Naturally, we want some kind of quality measures to be in effect to minimize the risks -- particularly since taking the risks and losing will cost more money in the form of needed recoveries and remedies -- thereby eroding the presumed, potential, net gain.
Unfortunately, this game is much more about choosing the right risks than it is about avoiding them. The issue at hand is to choose the risks that must come with the desired changes, but to also manage those risks to the point where the probability of them hurting us is minimized. The risk doesn't go away; it just becomes more contained. That's the quality assurance.
What then about productivity? Generally, since a new capability comes with preconditions, and those preconditions are risky, then practically speaking, the capability becomes available to the extent that the risk is managed away from the scheme for productivity (in both the development and use of the capability). The question is, what is the level of manageability that can currently be exerted on the preconditions? The degree of manageability will impose a *constraint* on what kind and amount of influence the capability can have -- influence that directly drives the type and amount of value that can be generated. If value is generated in a smaller and slower way, there is not as much to redeem for economic gain, and it's not clear that the capability will ultimately generate "more energy than it consumes".
A maturity model directly addresses the problem of determining how to balance the risk, cost and productivity associated with making the new capability available.
The model proposes a universe of factors making up the full scope of complexity pertinent to the capability; those are the preconditions. Further, the model helps segment that universe of factors into various combinations. Different blends of factors -- featuring their types and intensities -- associate with the kind of influence the capability can render under their role as circumstances.
This segmenting allows a user of the model to think in terms of when a particular influence (that is, a possible outcome of the capability) needs to already be in hand, and to then begin investigating (in the segments) what it will take to reach that level from the current circumstances. And each kind of influence may turn out to require that a certain minimum degree of manageability be applied to its underpinning factors. In anticipating net gains, we can imagine what the capability's target influence might be worth, but the manageability behind it determines the cost and risk levels that will be active, making the influence feasible and viable or not.
As an example, let's say that the desired capability is "locomotion"... There are three interesting influences or aspects of that capability: speed, safety and reliability. The ability to generate maximum value (and associated economic gain) through this capability calls for all three aspects to be maximized. But initially, there simply may not be a realistic possibility of hitting all three at top levels. On the way from the initial development of the capability, one or two aspects may progress ahead of the others.
And what propels the progress? Here again there are multiple factors involved, such as capital, negotiating skills, science and technique, and other resources commonly needed for development. These development factors can, individually or in combination, affect the progress of support for speed, and/or safety, and/or reliability. The key issue is, what is the operational ability to apply these development factors against the different aspects of the locomotion capability?
It is always tempting to think of mastering the capability in terms of being expertly comprehensive. But this is not the basis of the capability's value to the business, and therefore it should not drive the roadmap for progress in mastering (i.e., maturing) the capability. Instead, a business-level prioritization must kick in.
Now let's say that for some reason the early desired use of the locomotion capability is for the purpose of shipping cargo. In this purpose, reliability, and possibly safety, might outweigh the importance of speed. But if the main purpose for the capability is to shorten personal travel time, then of course speed might at first outweigh safety and largely outweigh reliability.
Further, for example, if we're selling shipping, we can attribute dollar-importance to those factors (and their combinations) that most strongly enable that aspect of the overall locomotion capability. As a shipper, we might not prioritize speed, and instead look at the requirements and costs to develop and maintain reliability so that we can start shipping and billing for that sooner.
Later, with proceeds from our shipping business, we can invest in adding speed and perhaps expanding operations into personal transportation as well as shipping.
We shape our buildings, and then our buildings shape us. --Winston Churchill
Having been reshaped by our buildings, what should we expect when we build again? Through us, the previous building will have *indirectly shaped* the new building, and isn't that how our operations environment evolves?
What our example shows is how maturity models help to map out a managed evolution that creates value at each stage along the way.
Posted by Malcolm Ryder at 6:34 PM | Comments (0) | TrackBack
July 28, 2005
Why performance evaluation must precede cost reduction
"Vision" and "Mission" intend to continuously guide organizations to a position and stance that is considered "optimal" for the business.
As defined by Princeton's Wordnet, optimal means "the most desirable possible under a restriction expressed or implied".
Certainly, companies consider "excessive costs" to be an expressed restriction -- but worse a restriction that actually represses desirable outcomes.
To understand how costs amount to a repression, cost must be seen in a variety of contexts.
Investments that create resources build capacity; capacity creates opportunity to respond, and response creates the differentiating impact measured as "value".
- But expenses that deplete resources or capacity or responsiveness risk altering the potential impact and can therefore erode or prevent value. (This might be expansions or alterations of property or systems that increase use by some but provoke inhibiting problems for most other users.)
- And excess capacity carries costs that are therefore unavailable as investments in other uses. (For example, consider funds that are allocated to maintaining systems that are not being used.)
- Likewise, expenses that intend yet fail to create capacity hold potential alternative investment hostage, decreasing opportunity to respond. (Here, think of projects that fail, or purchases that acquire the wrong thing.)
Since value is defined both by type and by level of impact, the question brought up by those circumstances above is this:
- Given the demonstrable use of current capacity, does the organization consider the value actually currently expected, which is the real value at stake, to be "the best possible position" ?
If the answer to that question is no, then what is the proper correction?
- Should managers concentrate on removing the risks to higher levels of that expected value?
- Or instead is there some other type of value (that is, some other differentiating impact) that should be installed as the target?
Although we can see that one of those choices should be taken, neither decision necessarily lowers costs!
Meanwhile, the only way to rationally answer either question requires that first we validate the currently targeted type of value as the correct type.
This brings up the issue of mission. A mission is simply a definition of an intent to produce a certain differentiating impact. If current capacity does not support a likelihood of succeeding at the mission, then the value promised by the mission is clearly at risk and potentially impossible.
When capacity mismatches mission, the only two corrective choices are to change the mission to fit the capacity or to increase the capacity.
The chief obstacle to those correctives is a contract or other formally binding agreement that does not allow adjustments without an additional expense that outweighs the related cost-benefit of making the adjustment.
Whether literal or metaphorical, the oneous "switching cost" can raise the cost of a capacity correction beyond practical acceptance, while leaving the capacity imbalance unresolved.
Further, in that way, the consumed-to-date portion of investment in the mismatched capacity becomes "sunk" cost, and the prevention of capacity reorganization increases the effective cost of some potential alternative opportunity (i.e., "opportunity cost").
Overall, what this means is that cutting costs is an action that actually needs to generate a return on investment greater than or equal to the amount of costs cut. Oversimplified, this says that a ten-dollar cost-cut needs to target a twenty-dollar gross benefit. Why? Because if the saved ten dollars is needed at all, it should become an investment working to earn its own way.
This "ROI of cost-reduction" will not materialize except through renegotiation of the agreements underlying the switching costs. Wherever the renegotiations don't offer stakeholders equivalent-or-better benefits compared to what they already have, the mission of the organization remains potentially compromised by stakeholder resistance.
This illustrates that change management is a prerequisite to the success of cost-reduction.
Then, to understand what must be changed and thereafter derive a cost strategy, stakeholder roles in the proposed new configuration of capacity must be mapped out such that their performance under the new agreements will logically produce a mission success suitable to replace the old (mismatched) mission results.
By comparing the proposed performance logic against the bases of current performance, change requirements emerge, and costs related to the changes surface, which allows adjustments of current costs to be made more rationally. Punchline: cost reduction is not an action: it is an effect.
Posted by Malcolm Ryder at 11:34 AM | Comments (0) | TrackBack
July 27, 2005
Performance Improvement requires Change Management
Performance Management is a concept best defined by business solution developers. That is, it is based on a definition of a problem called performance, and by focusing on a theory of the problem it derives many approaches and components of "solution"...
In a comparison of myriad definitions from vendors, analysts and industry journalists, the working common denominator appears to be "management of the alignment of people and technology to improve the effectiveness of their run-time support of business objectives."
One of the more significant notes about that consensus is that it does not include "processes" in its grasp. This might be for any of several (debatable) reasons, such as:
- business process management (BPM) is thought to be a peer of performance management rather than a part of it
- solving process problems is not thought to improve the solution of performance problems.
While both of those notions seem unlikely to be true, what makes them provocative is the way they force us to defend our theory of the "performance" problem. Indeed, since process management has already had intensive attention for years through automation and reengineering initiatives, the current idea that the "performance" problem has remained unsolved lends credibility to the sense that a focus on process is at best necessary but insufficient. The suggestion, then, is that a focus on performance is at least more important than, if not actually an alternative to, process management.
Put as simply as possible, the difference between process management and performance management is, respectively, the difference between "how to" and "how well"...
Defining the performance problem as "how well" readily explains the collection of interests addressed by performance management.
At the core of the problem theory, there is a set of target levels of activity impact or event impact.
The impacts are meaningful in any of several ways (contexts):
- financial
- legal
- operational
Standards or benchmarks are established and adopted to set impact targets in any of those contexts.
The compliance of operational outcomes with the impact standards is continuously monitored, which provides alerts and data for supporting further management decisions.
The fundamental issue is therefore how to manage impact targets and manage impact compliance.
This two-pronged management requirement means:
- deciding on what specific examples, mechanisms, and evaluation models to implement regarding targets, and
- doing likewise regarding compliance to the targets.
Given that perspective, it isn't surprising to hear lessons learned such as that offered in Intelligent Enterprise by former corporate planning chief and Hackett Group cofounder David Axson:
"you can put all sorts of policies and processes in place to try to achieve compliance, but if [that] doesn't change practices and behavior, your investment in compliance [initiatives] is of marginal value..."
And why is this a predictable outcome?
While policies deliver explicit guidelines and definitions to identify priorities and permissions, their effect is essentially environmental, leaving inhabitants with the politics and preferences of adapting to the environment -- in other words, with the latitude to not comply.
And while processes prescribe the rules of activity, they don't set the motivation. And the more complexity exists in the design of a process, the more opportunities there are for motivation to vary from what is minimally required by the process to meet its execution requirements -- in other words, to not meet the "standards" for support.
The punchline is that if "performance" is essentially the degree to which execution meets impact targets, and execution is a variable phenomenon driven by behavioral issues, then there is a two-tier prerequisite to performance improvement:
- successfully managing performance (to meet targets) will be critically dependent on deliberately managing the changes that affect behavior; and...
- successfully changing the impact targets (to define "improvement") will specifically require managing behavioral adaptations to the perceived opportunities and risks of the "working landscape" offered by the new environment that compliance prescribes.
So what about technology? How does that play into the situation?
The two dominant ways that technology affects the situation are procedural automation and communications. Typically, business requirements for speed and accuracy in work flows mean that people depend on the efficiency gained through technology to "effectively" initiate, intervene and interact. However, leveraging technology functionalities offers appropriate impacts when in the right hands, and risks inappropriate impacts in the wrong hands. What makes this particularly important is the pervasiveness of the technology. Consequently, the secret to technology's role in its alignment with people is in how the administration of the technology allows the organizational structure to drive value by meeting targets. That is, technology is a critical environmental factor of organizational behaviors, affecting behaviors while also asking for behaviors to adapt to it.
Posted by Malcolm Ryder at 5:36 AM | Comments (0) | TrackBack
July 18, 2005
Collaboration and Analytics: driving production with intelligence
Most organizational managers may not admit it, but the myriad complications of managing costs lower in order to increase net operational gains mean that this approach hits a point of diminishing returns much sooner than anyone prefers. Thus, in order to increase value, the approach of growth-oriented management becomes an immediately critical alternative to cost-orientation. Collaboration and analytics are two of the strongest tools for leveraging existing resources towards value-generating growth.
How? Collaboration and analytics are two modes of discovering and synthesizing intelligence for driving production.
As such, they are both decision-support mechanisms that can make a critical difference to the effectiveness of operations within the time-span of the operation's execution.
In decision support:
- Collaboration, using coordination, especially integrates varied expertise to create competencies from at-large communities.
- Analytics, using formulae, especially distinguishes latent patterns to create information from data collections.
How do coordinating expertise and formulating patterns contribute expertise and information, at a level particularly critical to production value?
Actually, Collaboration and Analytics each provide competencies and information, to recognize and productively incorporate new and unexpected influences -- in less time.
One view of this involves seeing them work together.
Collaboration can leverage analytics by using analytical findings to support decisions that adjust or guide the integration within collaboration. An example of this would be to have, based on forecasts, certain links in a supply chain modify their individual current outputs and/or output schedules to preserve the timeliness, cost limits, volume or quality of promised deliveries.
Conversely, larger data collections can be developed more quickly via collaboration; so, analytics can leverage collaboration to explore a wider range of alternative data sooner. This, within a given time period, can produce more patterns and/or perform more validation of given patterns. An example of the former benefit is identification of viable product alternatives that attract new business or contingent actions that reduce risks; an example of the latter is determining from multiple perspectives whether an idea really meets a quality standard for stakeholders, such as through a peer-review process in academia or in business approvals for complex proposals.
In practicing collaboration or analytics, a basic problem is one of providing an underlying model for organizing the activity. However, in collaboration there must be a model for putting things together, and in analytics, a model for taking things apart. For that and other reasons, another view on their potential delivery of benefits must consider the two techniques separately.
Collaboration is a special form of co-operation, in which all participants are adhering to the same goal for the same reason. The model that is needed in collaboration will, in effect, offer operational objectives to be mutually respected by all participants. More importantly, the model, usually called a "policy", will prioritize activity options that are offered by the various participants or that develop as interim possibilities during operations. This sounds very much like how any process is regulated, but the difference is that in collaboration the operation is constantly open to new inputs that were not anticipated before the operation started. Collaboration therefore requires the ability to effectively re-organize the operational integration based on the new inputs. Distinctively, while the operation is already in progress, a collaboration invents the solution to reaching the goal.
Analytics is a special form of de-composition, in which a pool of data is tested for its key contents -- namely, what it might include that is pertinent to a given fact or assumption. The model needed for analysis, usually called a "hypothesis", describes cause-effect relationships behind "factual" events or conditions (states). However, in an attempt to discover and confirm significant relationships, the analysis must isolate and identify the key factors of the relationships -- thereafter looking for clues or evidence of the factors. Sometimes it turns out that the "suspected" factors are not the real ones, or that the factors presumably needing to be investigated are not relating as suspected. This detective work is usually mandated as auditing; but the difference is that in analytics (for example, with weather reports), it is more important to discover possible futures than the confirmed past. As a result, although analytics are typically used to find proof of something, the primary basis of value in analytics is actually an objectivity that is focused on credible explanations agnostic to the data.
In those various ways, collaboration and analytics should bolster management-based effectiveness. But what does that look like? It's fair to look at progress from the "performance" perspective that a business typically brings to measuring effects; progress means both sustained improvements in operational quality and timely development of desired business advantages. Since there are many management techniques for pursuing those outcomes already, what motivates an embrace of collaboration and analytics?
An important issue clearly suggested by collaboration's inventiveness and analytics's neutrality is innovation -- or the ability to take new approaches to problems, due to having freedom from prior restraints such as resources or points-of-view.
Yet "continuity" is no less important to support. Here, collaboration and analytics matter when a breakthrough is needed for progress that is not, so far, being successfully driven by the capacity of solo efforts. Flexibility and objectivity (as supplied by collaboration and analytics) are key to getting the needed breakthrough.
The challenge is that managing operations towards a repetitive sameness is a technique we have fully embraced in the name of process improvement. Yet all processes are constantly confronting the eventuality of change at many different constituent levels including their resources, controls (management) and beneficiaries (perceived value). The danger of protecting "as is" processes is that they will become inflexible or irrelevant over time -- in short, counter-productive. The shift in operational habits that collaboration and analytics both encourage is straightforward but potentially profound. It is nothing less than a different approach to effectiveness -- requiring us to:
- stop protecting (in the name of efficiency and predictability) the "as is" form of operation; and instead,
- work to grow the operation's effectiveness by continually shaping it to broader opportunities that are more extensively qualified.
For some managers, this may throw their dedication to "optimization" under unexpected pressure. But in that case, it becomes appropriate to give the idea of optimization a revised context, by working on it specifically to support operational growth. An example of this approach is the attention many managers give to pursuing optimization mainly within the guidance of maturity models that are growth-oriented, explicitly sensitive to how the manageability of change (i.e. agility) regenerates and multiplies capacity over time.
Posted by Malcolm Ryder at 9:07 AM | Comments (0)
June 19, 2005
Evaluation versus Value
Evaluation closes the loop of management activity that begins with idea definition and continues through design, implementation, operation and support.
Following and actually overlapping "support", "evaluation" determines when the effects of operation are complying with initial standards and objectives, and whether the effects are compatible with requirements that have emerged and become newly current during the elapsed time of the idea's actualization and employment.
For managers, that current compliance and future compatibility mean something primarily because of the initial justification for the idea being actualized. This justification is often simply called the "baseline", and one of the primary goals of evaluation is to generate information that supports decisions about how to respond to changes from the baseline. As a result, performance information feeds change management to protect value.
Normally, the justification is a description of "value" to be gained by realizing the idea. Compliance will mean that the terms of the original justification are being met, but compatibility to new requirements means that expectations about future value are still reasonably positive.
An evaluation that cannot include both perspectives -- that is, of original and current expectations -- is at least incomplete, if not downright suspect. For example:
- an evaluation based only on the (earlier) original expectations might describe work done properly to produce something whose intended impact is no longer possible or relevant by the time it is actually delivered.
- an evaluation based only on current expectations, ignoring the previous forethought behind how the current conditions developed, might mistake a presently mismatched organizational stance towards requirements for a lack of capabilities instead of a lack of direction.
Another problem in evaluations is confusion about what approach yields information of the right type of importance. For example, these three following approaches are distinctive enough in purpose and capability; they can and should be complementary but are unlikely to successfully do each other's job:
Assessment - a determination of what kind of value should be associated with something, not just how much something is worth. In determining what kind of value, the assessment process examines how something actually creates value, and/or how it fails to do so.
Measurement - a determination of the degree to which something has a given quality or property.
Analysis - a determination of something's constituent parts and especially their inter-relationships, explaining a particular characteristic of something.
As an example of why these must be correctly used, look at the common need that organizations have to conduct performance assessments, performance measurements, and performance analyses. Casual conversation might use these three terms interchangeably, but in actual practice they will not correctly provide the necessary decision support if misused.
A performance assessment should investigate, and report on, the likelihood that an operation can meet the demands of given types of requirements. Along with this, but regardless of what current requirements are the established ones of record, a performance assessment should expose what types of requirements the operation is most likely constitutionally fit to meet, based on knowledge about how such requirement types have been successfully met in the past. This is usually where notions such as best practices are referenced.
A performance measurement should investigate and report on what level of compliance the operation has achieved regarding specified target levels of impact for certain types of impact. Typically, benchmarks are referenced in measurements instead of elsewhere.
A performance analysis should investigate and report on why measurable performance levels have occurred, regardless of what the measured levels are; then based on the reasons why, the analysis should predict the levels and types of performance that are most likely from the same dynamics. Forecasting is usually expected here.
However, the three approaches are complementary:
- Assessments and Measurements can share categories
- Measurements and Analyses can share data
- Analyses and Assessments can share models in common.
Taken together, the three approaches provide a complete reference for describing the relationship of operational effects to the objectives that for managers represent creation of value.
A full evaluation that includes assessment, measurement and analysis will give a description that traces the logic of what is actually happening in a way that accounts for expectations. In that way, managerially practical comparison of original expectations to current expectations should be possible, identifying the underlying conditions that are shaping or being shaped by operations.
Posted by Malcolm Ryder at 7:41 AM | Comments (0) | TrackBack
June 15, 2005
Business-IT Convergence? What happened to Alignment?
CIO Magazine, covering thinking from their CIO's Perspectives on Enterprise Value conference, reports that we've gotten ourselves into another semantic knot. But not a tough one. The debate pits "convergence" versus "alignment". Is Convergence the new and improved Alignment? Is it time to change horses again?
Perhaps what's going on here, in this overall discussion, is just reverse-engineering the underlying systems of a good plan...
Alignment (noun) is a process having the objective of real-time structural compatibility. But convergence (noun) is an event, literally a co-incident, with the characteristic of having critical influence on the state or direction towards some outcome (which is why we care to notice it).
Fundamentally, alignment emphasizes compatibility -- essentially, "usefulness". Convergence emphasizes concurrence -- essentially, "agreement".
But the two-ton idea casting a shadow over both alignment and convergence is "Integration". What hasn't changed with the terms-du-jour is a goal of integrating whatever is called "business strategy" with whatever is called "IT strategy". What has changed is that we now can usually distinguish the need to have operational motives align from the need to have operational outputs converge.
As we move into performance management, we kick things up a level where we then start working on the problem of "making outputs align" and "making objectives converge"; but we already call that "planning."
Posted by Malcolm Ryder at 6:50 AM | Comments (0) | TrackBack
May 18, 2005
Strategy versus Change, and the battle for Agility
Now that we're used to the idea that change is the number one challenge to a company's business performance, it would seem that strategy and change compete for the right to dictate priorities.
Business intelligence vendors go so far as to say that "managing change" is the top survival skill of a business. But the meaning of this is typically specified just as Business Objects puts it in their white paper on enabling business insight: "...organizations, plans and management theories don't accomplish anything directly... success lies in making each person as productive as they can be..." -- which means "to make the right choices among their daily decisions."
The most important aspect of that idea is that the point is not to make the same choices correctly and repeatedly, but to make the right choice each time.
What we could be seeing is a gradually forming understanding that productivity and agility are two views of the same thing - effectiveness:
- productivity being the view that describes resource-effectiveness, and
- agility being the view that describes process-effectiveness (as supported by productivity).
This proposes the logic of responding to an appropriate awareness of change. If timely information about new states can be input to people's decision-making on a continuous basis, the actions driven by those decisions become the life of the processes that drive the company. Ultimately, the process behavior is the output of the linkage between the people and the process.
Given "inputs" and "outputs" as just described, it seems that the people-process link can itself be treated as a (processing) system.
But there are caveats: the inputs are only meaningful to the extent that they are actually usable, and the outputs will of course be subject to tolerances that the business either mandates or discovers within its idea of "business-valuable".
That means there are three stages of management involved in the progression from the initial awareness of change to the business response provided:
- information modeling...
- followed by decision support...
- which is followed by policy compliance.
But this description still leaves "successful" decision support as either a wishful assumption or as a "black box". What's the related caveat? A decision is a micro-process, so to speak. The question is, in that middle stage, how do we organize decision-making so that it actually effects a dynamic alignment of new changes to previous objectives?
To get through this problem, the first step is to think about decision management.
Decision management would mean that the types, distributions, and timing of decisions would be defined and controlled throughout their lifecycle, with alterations made according to the demonstrated patterns of value generated from their current setup.
One useful analogy for understanding what this means is asset management, in which a collection of assets is categorized, inventoried, and tracked throughout their distribution into a user-population according to ownership, location, and occasion of actual use -- from the birth (acquisition) of each asset to its death (disposal). At a given moment, the condition of all these assets can be mapped, and that map can be used to establish correlations of asset distribution against economic impacts. These correlations tend to be used along with allocation histories to establish recommendations, permissions and standards for the use of the asset.
By analogy, each type of "decision" is an asset, and it may be "owned", "allocated" and "utilized" in various ways over time.
What controls decisions?
This perspective on decisions gets into the issue of what the organizational chart looks like, insofar as the orgchart might map how responsibilities and authorities are mixed, matched and bundled around the enterprise.
But (due to the analogy) we're also considering the aspect of "recommendations, permissions and standards" being applied to the decisions. Here, therefore, it makes sense that we'd look into what is considered to be an "acceptable decision" -- acceptable both in terms of how the decision is made and regarding what the decision addresses. The subject of the decision would represent some point or issue of "business value" that makes the decision important to have and use in the first place. That is, the decision will address the subject, but the subject actually validates the need for the decision.
Thus, if we take the subjects of all the decisions being made, and we map them out per their interrelationships and impacts, the subjects map should look like a model of value-capture -- or in other words, like a strategy.
This is pretty much what is presented by many "strategic performance management" solutions today, which offer a strategy map that is decomposed into objectives, their supporting (underlying) performance targets, and the initiatives that secure prioritized achievement of targets. It makes sense that these are, in fact, the "subjects" of business value-capture. Decisions and actions go on to address those subjects.
But that's only half of the picture...
"Business processes" present a different view of action-requirements that drive decisions. The processes are modeled to operationally coordinate resources and actions around specified events that have defined business value. But the events are mainly transformative ones, representing a prescribed change to the state of some environmental condition or some relationship.
If we take the desired states that all the processes are pursuing, and we map them out per their interrelationships and impacts, the states map should look like a model of the operational environment -- or in other words, like an ecosystem.
This leaves us with the challenge of reconciling the two main models -- strategy and ecosystem. This reconciliation, which needs to be continuously produced in real-time, is the essence of "alignment".
Managing alignment
So - regarding change: if decision-management is the people-process linkage where alignment takes place, and there are inputs and outputs regarding alignment, then how can we manage the alignment as a dynamic process? The answer we decide upon will be the real basis of the agility that otherwise is presupposing productivity.
Finding the answer means understanding why environmental states change, and what to do about it.
Along with that, the really big issue to consider is this: what happens out there that makes the business "change the subject?"
Here is an approach that deals with both issues.
Let's position the business model as the principal client of all operations. The business model makes judgements about whether it has different needs now than it did before. In effect, the business model (not something else) changes the subjects.
If it has new needs, and then requests follow-up action to them, it looks to business processes to conduct the fulfillment of the needs. The request that it makes will describe what kind of conditions need to prevail, and this will indicate both a difference from current states and a priority for achieving the difference.
Processes will see the requested difference as the result of events that should now occur, and the processes have to "configure themselves" to execute the events that generate the desired future states.
The requested priority will mean that some configuration options are viable while others are not. Therefore, some "intelligent rules" will need to be imposed on the real-time configuring of the process. The source of these intelligent rules may range widely -- from historically successful habits, to negotiated policies, to analytically discovered recommendations. (This is entirely typical of a change management procedure.)
Meanwhile, a risk-lowering condition is that multiple processes could "collaborate" to "orchestrate" the appropriate event-support, which means that one process will not be burdened with singly covering the huge variation that can occur from one request to the next. Here, there is evident need for a "broker" that can acquire and coordinate the support on time. The source of this brokering can range widely -- from contracts, to service agents, to discretionary managerial intervention.
We've seen it before
Think of the business model as a client with a portfolio, who decides to change contributions or investments -- from one part of the portfolio to another part, or from one level to another level within a part. Operations should respond to that decision by acting through rules and brokering to adjust the portfolio to the client's current needs.
An Enterprise Performance Portfolio segments business model needs into areas for operational attention applied and adjusted in real-time by rules and brokering that engineer process workflow for targeted, risk-managed fulfillments of business model demand. This links business strategy to the business ecosystem, facilitating agile response to change that translates resource productivity into business performance.
Copyright 2004 Malcolm Ryder
Posted by Malcolm Ryder at 3:34 PM | Comments (0) | TrackBack
May 14, 2005
Performance Management - The Return of Engineering
Engineering -
The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems. - American Heritage Dictionary
This definition is a good reason to ask what is intended by the use of the phrase "performance management". Isn't "operation" already responsible for performance? What is separate about performance that needs to be managed?
In the generic cycle of responsibilities that make up management, engineering clearly refers to the conception, development and implementation of whatever instrument is being utilized.
But we're asked by "performance" management to consider how and why the effectiveness of the instrument is faring.
What's interesting is the step from engineering's economy and efficiency on further to effectiveness.
In the management cycle, the "support" phase follows the implementation phase; so, is support where effectiveness starts?
Normally, performance management places top priority on the cause-and-effect relationships -- namely, the operational designs -- that drive and account for achievement of intended results. The approach, however, assumes that information about the causes, effects and results will be available for analysis in order to deduce or (more often) infer what part of the operations should be accountable for results -- and accordingly what part if any should be reinforced or changed.
This makes it obvious that feedback is the primary active ingredient in the support phase. By comparing feedback to the intended effects of the operations, we get indications of whether or not the operations are appropriate to the intentions.
Informing the decisions about reinforcing operations certainly qualifies as "support"... But where changing operations is concerned, it's appropriate to investigate whether the change should be made to the intentions that are labelled results, or instead to the result-oriented activities that have so far been developed and employed.
How does this relate to effectiveness? A simple working definition of "effectiveness" distinguishes it as being the quality of the given means's ability to achieve necessary levels of impact. In performance management, as in engineering, effectiveness is an aspect that is tested under the stress of action.
Based on the feedback, it might be decided that engineering adjustments of those activities will be made, or that the intentions themselves might be adjusted as acknowledgement of what the engineering is really capable of offering.
A key here is to have both a broad field of view regarding what the engineering should be capable of, and a narrow field of view examining the situation-specific results. Variations in both the means and the circumstances will be discovered to be the rule rather than the exception, and tolerances will have to be established for all the combinations that allow a desired outcome. The ability to dynamically adjust within tolerances must be built in.
In the end, "acceptable performance" is not merely constructed or induced -- it is engineered.
Posted by Malcolm Ryder at 8:22 PM | Comments (0) | TrackBack
May 10, 2005
Much ado about Knowledge
Here's a riff about KM.
You have the hierarchy (bottom to top) of data-info-knowledge-wisdom.
Data+context = info
info+usage = knowledge
knowledge+history = wisdom
All four items in the hierarchy can be recorded, making them "content".
Every kind of this content has a lifecycle of:
-acquire (discover/create/buy)
-store (classify/format/save)
-deploy (publish)
-process (consume/transform)
etc.
Then the fun begins:
-what are the reasons for taking any action in any phase of the lifecycle of any kind of content?
-what are the restrictions for ditto...
-what are the rules...
-what are the requirements...
Why are those the reasons/restrictions/rules/requirements?
- authorization (by who)
- circumstances (where, when)
- benefits (and for whom)
- costs (and for whom)
Perhaps lastly you have the idiosyncratic stuff:
- expectations
- permissions
- quality
and those kind of things tend to determine whether behaviors with content get exercized, prioritized, banned, or whatever:
- sharing
- distribution
- licensing
- maintenance
- etc.
Now, in each of those groups of considerations above, think of every separate item as a possible term or factor or "feature" of a content package that party A can make available to party B. (Ignore that some of the features might be undesirable or irrelevant sometimes; they still have to be accounted for in production as being intentionally included or excluded.)
Next, work up all the feature permutations and price them. What's the "market" for each permutation (i.e., type of package)?
Then, if you think of yourself as the package provider, and you think of the start-to-finish provision of a package as a "made-to-order, from scratch" event, it's easy to imagine yourself quickly wondering "hmmm... how can I do this as a mass-customization gig, where my speed and cost and complexity is not pushed out of control by the unpredictability of the next order versus the previous one?"
In designing that thing, you'll clearly have to run the gauntlet of politics, property, ambiguity, and risks.
It's amazing how much knowledge it's going to take to manage knowledge!
Wherefore, my two impertinences of the day:
#1 - "When information is free, only bums will have information." (Original, thanks.)
#2 - "A fool with a tool is still a fool." (Borrowed that one.)
Don't let this happen to you!
Posted by Malcolm Ryder at 3:00 PM | Comments (0) | TrackBack
April 27, 2005
ITIL - avoiding ITIL implementation mythologies
A consensus exists that ITIL - the defacto standard reference for IT service management - is a library of descriptions of "best practices". But it is crucial to note that in those descriptions, there is content pertaining to several different issues, three of them for example being objectives, practices, and processes. Just saying "best practices" does not logically mean that all three issues are best, nor understood, nor self-fulfilling for an organization. Saying "best recommendations" is more likely to the point.
It's an understandable urge to acquire the best "solutions" that makes some organizations try to force-fit ITIL -- acquiring by forcing themselves to fit ITIL's apparent prescriptions of behavior. Unfortunately, that doesn't work unless everyone wants it to. Meanwhile, organizations can't just simply run an "ITIL.EXE" installation wizard.
This calls for revisiting the idea of "implementation" on a fundamental level. Strictly speaking, implementation means *applying* something (an implement!), as a practical function within an existing operation. Our corporate experience with most large "applications" is that they must be customized to the targeted operational environment before they can "go live" and survive to deliver ROI. But the whole trick to that is to first understand whether the application must be customized to the current environment or to a future environment, or somehow to both. The IT organization, as run by its managers, *is* the environment. The dynamics of that environment are all about people and the reasons why people will do things.
Therefore, the typical prerequisite elements of "implementation" are always "target, commit, adapt", respectively meaning (1) the goal to adopt the implement; (2) the commitment to the necessary level of operational performance; and (3) the ability to adapt to using the implement.
Put differently, the necessary trio of implementation success factors is strategy, maturity models, and change management. Without this trio there is no rational roadmap available to guide the evolution of the organization from its pre-ITIL orientation to its ITIL-orientation. To create this roadmap, organizations may or may not need outside help, but the point is for organizations to embrace the concept of ITIL-orientation as opposed to ITIL-installation.
Posted by Malcolm Ryder at 10:26 AM | Comments (0) | TrackBack
April 20, 2005
The Performance Analysis Framework Pt. 2
"Performance Drivers" are the conditions that usually obtain for value to emerge from the interactions of the organization's operations, locations and relations with other parties. Drivers may be causes or they may be prerequisites. Typically, when managers translate a leader's mandate into actions, the step initially considered is to decide how to configure resources and methods to leverage environmental conditions that "drive" progress.
Management's job is not just to orchestrate the interactions but also to cultivate those conditions and, through designing the co-operation of conditions and interactions, to prescribe when the emergence of value is most likely supported or inhibited.
For performance management, an organization needs to comprehensively manage information that is used to:
- develop a performance logic model (a theory of progress)
- develop the supporting plan for organizationally implementing the model
- initialize and prioritize action
- monitor status
- confirm underlying or correlated events, and
- reconcile significant differences.
Those actions will primarily involve information that describes operational conditions in terms of value, including:
goals,
assumptions,
relevance, and
priority as well as
variance and
status.
In emphasizing the value-perspective on the operating conditions, performance analysis has two needs: one, for the first four of the six types of information to be logically interrelated; and second, for that logic to be continually applied as a major influencer on business operations.
The real-time decisions for directing activity then matter because, as evidenced in variance and status, they emphasize how follow-up activity is succeeding in turning "plans" into "actuals".
This follow-up activity constantly confronts opportunities, restrictions and expectations that surround the ability to use procedures, tools and people for getting things done.
The practical intelligence about those constraints is distributed throughout the organization. To allow discovery of how to optimize resource utilization for the plan, that intelligence must be coordinated and integrated. Then, refined activity can realize the plan, and drivers can be supported, to produce desired outcomes, which will be observed as good performance.
With the Archestra framework for performance analysis, the identification of goals, assumptions, relevance and priorities is subjected to a reality-check. Opportunities, restrictions and expectations that mitigate them are excavated and grouped in two dimensions:
- reasons (typically dynamic)pertain to the "why, what, and when" decisions that drive resource deployment, while...
- requirements (typically structural) pertain to the "who, where, and how" decisions that establish the organization's position regarding its relations with other parties, locations and operations.
The most important influence of the framework is to illustrate that progress cannot occur unless business reasons are articulated as organizational requirements-- and that if reasons change, then requirements must adapt through change or realignment with the reasons.
As shown in the following example, the framework elicits and accounts for another set of defined progress drivers to be managed, beyond the typical basic level of operational "components" such as designated procedures and resources. The overall value articulated in this example is "sustained superior fulfillment".
-------------------------REASONS versus REQUIREMENTS:-------------------------
WHY versus:
- Who: A director must ensure that an on-time deliverable occurs
- Where: Responsibility for fulfillment will be with the department that directly supports the customer
- How: A process for controlling the production schedule must be used
WHAT versus:
- Who: A workgroup must be authorized to manage an activity or condition that ensures an on-time deliverable
- Where: Production must take place in both a primary and secondary (backup) location
- How: New facilities, instead of prior ones, will pilot the production
WHEN versus:
-Who: The deliverable is on-time when it meets with the recipient's agreed expectation
- Where: Adequate lead time for fulfillment should be built into the delivery, including contingencies
- How: Start-up of production should be supported by a contractual arrangement
-------------------------------------------------------------------------------------------
Staged by the framework, this "plane" of requirements specification is the arena of the direct performance analysis, addressing the underpinnings of progress above the component level and instead on the policy level.
Posted by Malcolm Ryder at 6:07 AM | Comments (0) | TrackBack
April 19, 2005
The Performance Analysis Framework Pt. 1
All businesses operate on the presumption that progress is viewed through purpose. But in assessing progress, too often the business is distracted by the pressure for efficient activity, to the detriment of managing for effective achievement.
Typically, when managers translate a leader's mandate into actions, the step initially considered is to decide how to configure resources and methods to leverage environmental conditions that "drive" progress.
"Drivers" are the conditions that usually obtain for value to emerge from the interactions of the organization's operations, locations and relations with other parties.
Management's job is not just to orchestrate the interactions but also to cultivate those conditions and, through designing the co-operation of conditions and interactions, to prescribe when the emergence of value is most likely supported or inhibited.
Attending to the drivers, managers first need information that identifies how the key condition in question is helping or hurting progress, and this means identifying what underpinning aspect of the plan's cause-and-effect prescription is being influenced.
Management typically puts a lot of attention on monitoring the "components" of a plan, in the sense that there are mechanical parts such as the steps in a procedure or the quality of a particular resource being used, and the plan assumes that their use is necessary.
But those specified components are just one aspect of the plan's underpinnings. An equally critical aspect involves the actual reasons why their usage is necessary, and the requirements that are success factors for their usage in the planned way.
Those reasons and requirements are what make the components "appropriate" for the organization's attempts to execute its strategy. Managing this appropriateness is generally a matter of establishing policy.
Cross-referencing the reasons and requirements forms a framework for understanding how the organization can actually organize for performance, because it looks directly at organizational characteristics that will tend to inhibit or protect opportunities for progress.
This follow-up activity constantly confronts opportunities, restrictions and expectations that surround the ability to use procedures, tools and people for getting things done.
The practical intelligence about those constraints is distributed throughout the organization. To allow discovery of how to optimize resource utilization for the plan, that intelligence must be coordinated and integrated. Then, refined activity can realize the plan, and drivers can be supported, to produce desired outcomes, which will be observed as good performance.
The utilization of that intelligence is the focal point of performance analysis.
Posted by Malcolm Ryder at 8:50 AM | Comments (0) | TrackBack
March 16, 2005
The Nature of Management
Management likes control. In most business organizations, operational control is a packaged deal - a bundle consisting of a core uncertainty, wrapped in tolerances, wrapped in procedure. Because control is established that way, whether the wrappings are looser or tighter, it is often only the procedure that is detectable evidence of control.
What's more, procedure is often the only evidence of operational consistency -- that is, something that managers want to be accused of when things do work, and want to not be hostage to when things don't. But managers should not -- must not -- mistake procedure (nor superficial consistency) for management.
A business likes to take it for granted that certain things are possible because managers have other things under control. This is similar to assuming that you can get to work in the car even on a pretty stormy day. To dramatize this assumption, imagine an angry person driving a powerful car on a bumpy road in the rain -- altogether an operating environment of at least four pretty major forces interacting: temper, motor, surface variation, and weather. We might even think of each force as a "system".
But first facing facts, the commute is all predicated on the notion that these four forces will interact within a usable range of uncertainty, otherwise the deal is off. The combination of forces may at any time become fundamentally unsound for the purpose of completing the travel. Each system is capable of independently excelling at what it does but likewise interactively throwing the overall driving "environment" out of whack for the intended purpose.
All environments have a deep structure that is simply:
- whatever forces are in the environment;
- whatever types of dynamics are generated by those forces;
- whatever types of regularity there are to the dynamics; and
- whatever interactions between those dynamics is likely to be generated by their regularities.
And then there's management. Basically, management brings interventions to the "natural" scenario that develops from the existing forces. The most useful way to account for these interventions is to simply call them tasks.
Broadly speaking, tasks either help to navigate the environment or help to reengineer it, usually by acting on the dynamics. Introducing counterforces that redirect extant dynamics is always popular; changing the systems that generate the forces that create the dynamics is also a well-worn path. On the other hand, anticipating their patterns and threading through them or leveraging them is the minimum requirement.
To more fully imagine those options, think of any operating environment as a pool of magnetic syrup, in which the manager can introduce fences and gates; steps, pits or inclines; heat or cold; and of course, more magnets. Performing tasks that distribute these interventions in one way or another, managers get the environment to more or less take a desired shape with a desired level (or degree)of stability. The logic of the tasks and distributions is the design. The purpose and duration of the shape is what lets the business do what it is trying to do -- or stops it. The manager's responsibility is to keep conforming the shape and duration to the real-time needs of the business, in effect, to exercise continuous deployment of productive interventions. Because of the frequency of business change, uncertainty is always a given whereas procedure is not. And this is why, in management, design is both more powerful and more essential than procedure.
Posted by Malcolm Ryder at 4:37 PM | Comments (0) | TrackBack
February 24, 2005
About Alignment
Usually, our concerns about "good work" are well covered by just three big words in our vocabulary:
- quality,
- performance, and
- value.
Naturally, no one of these three things just arrives on its own. Additionally, it's hard to think of cases where having any two of them is likely without the third.
In the management effort, we constantly see and plan for the relationships that link these three to each other. But of the three things, the issue that is possibly most sensitive to management influence is "performance" -- that is, the execution to desired goals.
I.
Goals are usually thought of as end-points; to set that endpoint the goal provides definitions of certain conditions. We say that execution has had the required impact when execution conforms conditions to meet those definitions.
Among the conditions to be conformed, it's normal that some are already acting separately or interacting for some special purpose while others are at least indifferent to what we now want. For that reason, execution must act on the nature and relationships of those conditions -- and coordinate them so that they don't compete with the intended progress towards the goal. This coordination or alignment helps to overcome inertia, momentum in the wrong direction, and/or volativity.
In other words, alignment is a state that functions as a precondition for performance.
II.
Execution includes both the decisions and the hands-on actions that we call production. Production itself commonly selects inputs from external sources and channels, and "processes" them internally through a designated organization (such as a workgroup or project) under supervision.
This throughput is variable, and to keep it within acceptable tolerances the coordination of external and internal conditions must have high priority.
For example, external conditions include the quality and volume of inputs (supply); and internal conditions include the functionaility and immediacy of processing (readiness). Predictability and consistency is vital in both cases.
Therefore, alignment is needed both in external and internal environments.
Furthermore, because alignment may be practically discovered (self-emergent) or built (programmed), alignment actually comes from four directions:
- emergent external alignment;
- emergent internal;
- programmed external; and,
- programmed internal.
Managing alignment depends on awareness of the environment's dynamics. Each one of the four types of alignment must deal with a set of distinctive dynamics -- the flows and blends of states and events that characterize the conditions of the type of environment. Consequently, the information that each type presents to management can be quite dissimilar to the other three types. Yet each is a significant factor in the supply or readiness aspects of throughput.
Whether overall alignment proves manageable or not depends on leveraging distinctive competencies from within these four different situations in order to achieve and sustain the coordination necessary. A competency dynamically combines awareness with knowledge and skills under real-time demand.
III.
At any given time, all four types of alignment are factors with varying relative impact. Given this situation, the initial problem to address is to successfully sort out and describe the causes and effects characteristic of each area, that are most relevant to execution throughput.
In the representation of the distinctive alignment areas below , the picture shows four corresponding types of influence on execution, along with the two main reasons (accountability and compatibility) that management tracks them.
Following on that, developing a "common awareness" across the different areas of alignment is the key to their coordination.
IV.
Much of the work of defining the view on each alignment area is carried out by what is now called "business intelligence". Each area reports on matters that explain how its own activity and events are influencing things or are being influenced. Competencies found within the various types of alignment differ , and are and sometimes optimized in ways that increase their differences. From the perspective of execution throughput, the extent of those differences is often not as much in the foreground as it should be. But when recognized, this problem is addressed through integration initiatives.
Integration appears to circulate required information across boundaries, but the crucial work of developing the awareness common amongst the different areas falls to what is being called "knowledge management".
We're very accustomed to the idea of discovering connections through information processing, but to create the common awareness, knowledge processing must also be implemented. Knowledge processing discovers how different things are alike, not just how they affect each other.
V.
Information processing and knowledge processing contribute in different ways. The challenge is to make them co-operate in the four types of alignment.
Management's supervisory responsibility relies on sensitivity to pertinent descriptive facts -- or "intelligence". This naturally tends towards data collection (surveillance) about external factors and data validation (auditing) about internal factors.
But in those efforts:
- surveillance of emergent conditons rests on access, intervention and persistence. These are opportunities that may be highly dissimilar in external versus internal environments;
- meanwhile, the auditing of programmed conditions requires authority, methods and testing -- concerns which have resolutions that are typically unlike across external versus internal environments.
Although these differences are not insurmountable, such inherent limitations of business intelligence reflect the essential difficulty of comparing apples to oranges. Alternative knowledge processing is thus critically appropriate for relating the various areas of alignment. In a sense, solving integration issues with business intelligence is like making a fruit salad that is easier to consume, instead of finding the underlying principle that will make both apples and oranges grow better in the same climate. For the latter solution, knowledge management is better.
Along with the correlation of different competencies, an operational strategy for coordinating effects amongst the different areas must be selected. For any area, this will generally involve calibrating the area amongst the others, through one of four modes:
- waiting (to shrink scope and complexity)
- repositioning (to increase leverage)
- renovating ( to manage change in demand), or
- innovating (to create a new type of relationship).
While pursuing an operational strategy for each alignment area, the group of four strategies must also be co-ordinated with each other and over time.
Overall Alignment should therefore be modelled so that coordinated operational strategies (or "modes") for addressing the four flavors of alignment are visible for all operations to explicitly engage -- making alignment manageable. Effectively, that model of coordination is a portfolio.
Posted by Malcolm Ryder at 1:15 PM | Comments (0) | TrackBack
February 23, 2005
Change and Management
Managing change is always a critical capability, yet is it always an important practice? Consider the idea that things can have a distinction without a difference. For example, if moving to a point two steps to the left gives no "better" point of view, then a distinction without a difference has been achieved. This helps to point out that if there is no point to the difference, then there may be no need to manage the change that creates the difference.
The punchline is that managing difference , as opposed to just managing distinctions, is the essential purpose of managing change. Put differently, change management manages for value -- meaning, the significance of the difference.
For example, pursuit of an opportunity or avoidance of a risk represents basic motives for change management. In practice, when "significant" transformations of a current state can be consistently anticipated and purposefully controlled, Change itself becomes "manageable".
In management terms, the value represented by the significance may be positive or negative, since the value is determined by comparing the result of the transformation to either the prior current state or a currently desired state. Generically, this value assessment identifies positions along three dimensions:
(a.) the intended/unintended;
(b.) the expected/unexpected; and
(c.) the planned/unplanned.
According to the locations foreseen or detectable within that 3-D space for any event, the practical roles of anticipation and control are defined, scoped and scheduled (thereby spawning requirements for related policies, processes, tools, and so on). But this organization of roles happens only because the various locations in that 3-D space are seen as being
(x.) preferable to some degree,
(y.) tolerable to some degree, or
(z.) inevitable to some degree.
Consequently, in acknowledging this second 3-D space that characterizes or "measures" the locations within the first space, we can see that change management is where value and risk are managed together -- making change management always essentially strategic -- whether it is being practiced at the level of operational commitments, or tactical selections, or strategic planning.
Posted by Malcolm Ryder at 8:42 AM | Comments (0) | TrackBack