" />

« October 2005 | Main | December 2005 »

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

When Rules are required, Requirements rule

Business has a history of asking for IT to enable new capabilities, and IT has a history of giving the business those things while falling behind itself in the same progression of operational management improvements. So when the "non-expert" business users establish the norms that are acceptable for these capabilities, it is ironic that IT has to learn the capabilities from business.

For many years, consultants have had the capability of explaining the difference between business requirements, implementation requirements, and infrastructure requirements. This set the stage for also explaining the relationship of the three sets of requirements.

But the value of that capability would simply shift around according to who was the most influential sponsor (aka, the client) of the development project the consultant was working on. Meanwhile, the importance of aligning the different requirements was too difficult to prove except where enterprise architecture was taken seriously.

Now, as provided by today's IT, the visibility and control of operations is giving the business experiences and awarenesses that extend more "democratically", enterprise-wide.

As part of this awareness and experience, rules are much more in the foreground as stabilizers and optimizers for decision-making. Basically, rules describe the decisions that have been made and approved about how responsiveness to demand is to be implemented with risk and efficiency already factored in.

But because they are ultimately aimed at demand, rules derive their real significance from how they relate to requirements. So in fact it is requirements management that establishes the environment for effective rules management. Requirements will drive the need for aligning rules, but it will also drive the need to change them. Decisions about requirements themselves are always the most important issues to get right, while technology becomes a critical tactical factor in whether those decisions are actionable and thereby practically meaningful for business value.

Thus, because technology is "globally" increasing direct awareness and the ability to do something about it within the organization, it almost automatically becomes necessary, instead of optional, to manage rules strategically.

Michael Voelker, writing in the November 1, 2005 issue of Intelligent Enterprise, discusses Business-IT alignment in terms of how responsibility for managing business rules is balanced across the organization.

Such responsibility may be presumed even before the capabiity exists to live up to it. But with IT, the business can best help itself by ensuring proper support for IT production.

So, two key thoughts follow on that story. One is about management maturing from a special professional function into a general organizational competency, thanks to IT distributing the opportunity to decide effectively.

The other thought is about how increasing experience, enabled by IT, becomes expertise that loops back to the conception of what IT ought to be doing. When business uses IT to drive "better IT", both parties win.

In the case where IT allows the business to more freely allocate responsibility, the business gets something new, but the business viewpoint on what should be possible then feeds back to IT in ways that will change IT by making it more like a business. What we're seeing, in effect, is a practical iteration of enterprise architecture, with enterprise-wide adoption finally possible through more tangible terms.

Posted by Malcolm Ryder at 7:19 PM | Comments (0) | TrackBack

Communications in Performance Management Pt. 2

"Performance" rates the value provided under demand.

With that working definition, it's easy to see why modelling processes is so important: the process model is expected to account for how the organization successfully and predictably handles the stress of the demand and allows "performance" to be engineered.

That is, process modelling interprets performance in an explicit operational language that connects capabilities to requirements.

Process Management attends to those connections by maximizing the availability, economy and efficiency of the connections. To leverage potential connections, the management effort carefully but quickly associates the model of a process with the requirements of a demand. The associations that prove to be the most frequently successful lead to two things: refinements of the models, and standardization of the selections made amongst potential connections. In that way, we decide that the reliance on processes is improved according to the definition of "success". Net: we decide that "process improvement improves performance."

But the number one problem in managing performance is not a matter of correct processes; rather, it is a matter of knowing what is currently really going on. This knowledge is not simply a matter of timely fact-finding but instead of sophisticated interpretation of the state and trajectory of current conditions. Assuming that the right facts are discovered and studied, we rely on the analysis of facts to accomplish this interpretation. Properly done, the analysis must examine facts to determine their significance to the definition of success. So, given our working the definition of "performance", the analysis of facts is potentially critical, but it is irrelevant unless the current definition of success is well established.

In practice, success is generally identified as a "goal", but what practically matters are the characteristics of that goal. Whenever a goal has multiple stakeholders (which is, most of the time), it is necessary to not only "get there" but to get there "in the right way". The understanding of the right way to get there must drive management decisions about what processes are "best" against demand. The right way is defined through "terms" of success.

Meanwhile, the immediate priorities of the different stakeholders can and do change independently of each other, so in a given instance of demand the most proper (balanced) response may be very specific to the moment. Politics notwithstanding, this inherent complexity also means that the management effort itself may not be practical (towards high performance) except through on-the-fly collaboration that allows the true current terms of success to be properly recognized.

Net: modeling the collaboration is more important than modeling the process.

Collaborative management fundamentally acknowledges that different perspectives must be reconciled in a process, not just that the process should mechanize the stability of operations. As seen in the following picture, each stakeholder has a point of view offering at least two perspectives -- perspectives that can raise and evaluate issues, actions and likewise events.


Therefore, proper management calls for an integrated management communications platform that allows all members of the organization to:
- continuously observe and immediately understand the context and implications of operational events; and...
- communicate the issues pertinent to the observations and understanding, and...
- appropriately collaborate on timely follow-up decisions and actions that create or restore critical alignment of activities to the directions of strategic and tactical goals.

Observation becomes meaningful when the items within view have definition. In performance management, the importance of communications is to indicate the impact of events, but this cannot be done unless both events and impacts are specifically and suitably defined. The caveats are that Events are defined within the mode of monitoring, and Impacts are defined within the mode of interpretation. Consequently, the actual implementation of these management activities can be highly specific to time and place -- and for any given implementation, the modes of monitoring and interpretation must be logically related to each other. Thus, "one size does not fit all."

Understanding is accomplished when:
- those above-made definitions of events and impacts allow their associations to be determined and classified, and when...
- those classifications can be used to account for the status and dynamics of circumstances, both present and future.
In implementation, the degree of understanding achieved is usually represented in a level of compliance to rules and plans that are intended to control, by force of design, the status and dynamics of circumstances. These exert their influence as "requirements" for the processes that are ultimately selected to respond to demand.


To establish and maintain credibility as an agent of performance, management must be directly responsive to the implications of current circumstances. As shown in the diagram above, a performance management solution must bring practical visibility to the fact that any of the terms of the operations environment, and any of the values in the management context, may change at any time. Changes will affect both the events and the impacts observed, thus their relationship can change and take on a different meaning.

Ultimately, what the “business” must gain from performance management is the ability to better orchestrate the changes -- in order to direct affairs in a logically calculated way towards the meaning that the business desires.

Posted by Malcolm Ryder at 7:52 AM | Comments (0) | TrackBack

November 29, 2005

Smart vs. Dumb

Here's a thought: what's the difference between dumb and stupid? Dumb is when you're wrong and you don't know it. Stupid is when you're wrong and you do know it. If you're right and you don't know it, are you smart?

This looks like it leaves organizations with only one out of four options to deal with reality: when you're right and you do know it.

Managing knowledge has a lot of sex appeal now, but managing dumbness has been around for a while.

There's the infamous "Need to Know Basis" -- applied to the occasions where for the thinking done by the audience in question, more is less! It features the speech, "Take my word for it, you don't want to know!" This cool bit of judo, or Enlightened Dumbness, is a vital tool to have when the smart thing to do is to lower the risk of increasing the risk. How parental!

Back out on the streets, there's the ecstatic expletive "Stoopid!" -- applied to something so self-evidently excellent that in order to not notice, you'd have to be unconscious or ... stupid. (Although, you wouldn't be "Dope!" because when you're Dope you are pretty much Stoopid, only probably just for the moment instead of endlessly like Stoopid things are.) This is the label on that box that those "best practices" keep arriving in from all those other companies... The fine print says, "Take my word for it!" Admittedly a weak form of self-evidence, but what a great excuse to not have to know something else.

Enter "knowledge management." A discipline dedicated to the twin goals of enlightened dumbness and informed ecstacy. An environment where most of what gets known is the things that are the best to know. An important new model of organizational execution. A rave.

A rave? Spontaneous formations of virtual communities... built around certain ways of expressing or celebrating a theme, counting on targeted just-in-time communication of information from sources whose credibility is based on the channel they use to transmit -- but whose channels are spontaneously formed through the content itself.

Gossip.

This is a good thing?

The conventional organization is based on distributing (pushing) responsibility for what you're aware that you know. But how are you aware of what you know? Well, you're told.

Ironically, the knowledge-based organization is based on taking (pulling) responsibility for what you're aware that you don't know.

Oh! You mean Research.

Does this make an organization smarter?

It probably doesn't make the organization smarter unless the research itself is well organized.

A perfect example of what organizes research is requirements. As with a rave or a community of gossip, a knowledge-managed organization has a characteristic feature of the requirements already being globally acknowledged. The problem for most organizations is to communicate requirements globally without them losing their context. This communication often can be accomplished only just-in-time, so pending that the organization has only latent knowledge. In responding (with research) to requirements, the organization discovers what it knows.

In this way we can see that the distinctive contribution of KM to the organization is that is helps the conversion from being unaware of what you know to being aware of what you know. The key to making the organization smarter, though, is to have better requirements established.

The complementary problem to solve is the one of moving from being unaware of what you don't know to being aware of what you don't know. But assuming this is accomplished, ending with requirements being established, its value quickly drains away unless KM follows up by driving response to the requirements.

A final observation to make about knowledge management is this: management is a discipline that cycles attention to something from a concept and design (i.e., research) stage to development, deployment, control and assessment stages. Over extended periods of time, the most competitive advantage of leveraging knowledge progressively moves from the control point in the general management cycle of attention backwards towards the concept point.

(To be continued.)

Posted by Malcolm Ryder at 2:47 PM | Comments (0) | TrackBack

November 28, 2005

ITIL, Optimization, and the Performance Management Approach

Business derives value from the utilization of IT in the same way that it derives value from the use of money or people: the business applies the asset to enabling those events that have a designed ability to impact business conditions.

Assets may be applied directly or indirectly to the target event.
- Directly, the asset is deliberately "consumed" by the event itself. This involves using the asset as a material element of the event. The event may employ, transform or exchange the asset, in order to produce another output.
- Indirectly, the asset may be used to deliberately affect circumstances surrounding the target event. By "circumstances", we mean conditions surrounding the moment or location of an event.

Consumption and circumstances often develop independently, and they often coincide without much resistance on the way. But management's intent is to replace coincidence with planning, and move consumption and circumstances to co-operation .

If cooperation didn't need to be planned, we wouldn't need management. For this concern, the proper focal point is not the assets, but the events in which they are involved.

I.

In producing cooperation, one of management's primary responsibilities is to establish compatibility between the circumstances and the consumption. With assets at stake on both sides, competition for the supply and deployment of assets is an issue. Since no event goes unfollowed by others of equal importance, organizations need to know what will happen to their capacity as an aftereffect of the cooperation.

In effect, whatever requires the cooperation -- namely, the target event -- is seen as something that must either conserve or replenish assets, so that business will be continuous and ongoing instead of episodic or temporary.

Yet placing that restraint on the target event must not prevent the event from bringing the needed impact on business conditions.

This reflects a broader principle: environmental conditions are part of the "infrastructure" for business functions, and meanwhile, consumption (business function) has prerequisites (specifications). Circumstances (environmental conditions) have effects (states) that must productively correspond to those prerequisites.

This "productive correspondence" of current specifications and current states is exactly the compatibility being sought from management.

Consequently, it is evident that the key issue is not asset management; rather, it is event management driven by business requirements -- which is the ordinary description of business capability.

II.

The history of the business capability is largely recorded in the history of events that occurred under the pressure of demand. As pictured above, an "event" is the overall result of interacting capacities and requirements. Thus, we easily expect an event to vary widely as the number and strength of influences on its separate elements varies. The primary threat to manageability of events is the inability to control that variation and maintain a useful synchronization of the elements.

In periods where management efforts are successful, events are the normal focal point of attention to whether the business is getting what it desires from IT. The benefits of events are the most ordinary measure of success. When event benefits fall short of desires, then the typical approach is to look for what disabled the event from being beneficial. This disability will usually be found in either of two areas: one, the context of the event (as in time and place); and two, the makeup (causes) of the event.

In accordance with the "event model" discussed so far, we can especially appreciate thatprocesses are used to place controls on the makeup of an event, so that the event's final character is appropriate to desires.

Ideally, a process predictably selects and coordinates the event's elements, with as much aggressiveness and detail as necessary to assure the needed character of the event. By increasing the process's ability to reliably find and control necessary event elements, management can mature the process to a point where the timing and location of a certain type of event also becomes more and more predictable -- which is hugely valuable to selecting and organizing responses to demand.

Process-modeling (now evident as a form of "event-planning") usually seems highly convenient to management. Mmanagement readily adopts a "process" approach to designing and cultivating desirable events. And more maturity in the approach promises the business greater opportunity to create (or find) and leverage advantageous business conditions, strengthening the approach's justification.

But acquiring strength and quality of maturity cannot be taken for granted. This means, in turn, that the assumed benefits of processes are always to some degree uncertain to occur.

“Complexity is intrinsically predictable,” Wharton management professor Saikat Chaudhuri notes, with a very major caveat. “If one places sufficient resources and project management strategies in the right places, it’s possible to manage the complexity. You can learn how to do it. But uncertainty, by its very nature, requires constant adjustment. This type of flexibility is tough to achieve, especially in the middle of integration activity.”

Challenges to process maturity are a part of the uncertainty, affecting the makeup of anticipated events. Another big part is shifts in demand, which reflect changes in the context of events. This indicates a need for an alternative to process management to serve as the lynchpin of business value.

III.

In the discussion that is most interesting to business people, the working definitions of "performance" pertain to the generation of value versus demand. Business runs on competitively satisfying external party demands -- and it is constantly translating those external demands into demand on its internal constituent organization. In that light, maturing the management processes for events-- which links an organization and its environment -- is a critical aspect of managing improvement in performance.

Yet with management process maturity in place, the unpredictability of demand remains a highly significant type of uncertainty threatening management results. Because uncertainty is a fact of life; organizations must simply take a useful position against it.

Thus, complementing event management, the most critical aspect of deliberate performance improvement will be demand management.

Consider "benefit" in a general sense, as a constructive impact of an event. The effectiveness of management is measured by the benefits delivered, and events deliver the benefits; so we continuously scrutinize how we manage the enablement of the necessary events.

But without at least hypothesizing alignment of events to demand, it is difficult to foresee what "benefits" (if any) will likely be obtained -- thus leaving operations without a significant justification. Demand management represents the "business dimension" of overall operational alignment -- events are planned specifically against the known or expected range and scope of variability in demand.

This makes it clear that "performance" always presumes a capability with a justification -- and that is the most important slant that ITIL has on IT management.

IV.

Being able to foresee benefits is essential to executive responsibilities for planning. With planning, we chart the overall path from capacity to events to benefits to demand. The path must be accurately envisioned as management efforts.

The IT Infrastructure Library (ITIL) documents key principles and practices that organize the IT management path from capacity to demand. In describing how organizational resources are used to conduct the practices, time-tested examples of management processes are offered that show the coordination of distributed assets, utilization controls, and business requirements. Because processes are so important to implementing the management of these factors, process integrity and maturity are enormously important objectives of ITIL's information. Yet often the approach to understanding ITIL is too easily distorted by a competing perspective -- not the necessary one of "implementing management" but instead the habitual one of managing implementations.

The misfortune of this latter perspective is that it significantly discourages understanding and appreciation of ITIL at the organization's executive business level. The key to repairing or avoiding this situation is to understand how ITIL information helps to describe the management of events that characterize the business capability.

Performance Management is an evolving discipline that uses forms of communication and visualization that are strongly suited to mapping the origins of and connections between an organization's assets, functions, events and demand.

To maximize the positive influence of ITIL in the organization, performance management instrumentation can bring two things to executive attention:
- relevant business issues expressed in terms of the ability to impact events; and,
- the improvement of that ability as a consequence of pursuing compatibility with ITIL.

The target effect of the ability is to drive benefits that improve the infrastructure for business functions.

The key is to communicate this ability to drive benefits as more a cultural effect than a merely mechanical one.

With the more conventional "mechanical" view, the active drivers of business benefits (from events) are usually more about linear procedures, assignments, and accounting -- concepts that gain their meaning at deep levels of granularity and organizational segmentation. Their main objective is to establish compliance in the organizational activity, which fosters predictability (a lower risk) and scale (a benefit).

In contrast, by "cultural" we mean that the active drivers of business benefits (from events) are goals, priorities, and agreements -- concepts that need to be collectively meaningful across the organization. The main objective is to establish compatibility within organizational diversity, which fosters agility (a lower risk) and resourcefulness (a benefit) in the focus on demand and progress.

One thing we want to know is whether the two approaches shape different kinds of events in order to deliver benefits in their different ways.

V.

Rather than assume that a given business problem can be solved by differing benefits, we normally assume that the problem calls for a certain benefit and that we can get it, if necessary, from more than one kind of event.

But generally, events are cultivated not only to deliver certain benefits but also to do that with certain characteristics.
.
In driving the benefit, any advantage of the cultural approach over the mechanical would first be researched in how it addresses management's responsibilities for producing three critical delivery characteristics:
- functional excellence,
- quality, and
- economy.

Typically, each one of those characteristics can be framed as a measurable effect of premeditated standards, expertise and efficiency -- factors that go into shaping the events that are the source of benefits. So, what we can consider is how a cultural version of these factors differs from a mechanical version.

Standards, expertise and efficiency are all intended to maximize the stability and continuity of the health of the business by "optimizing" organizational responses (events) that generate benefits. Stability and continuity presume that the way the event occurs should leave the organization in the best shape to both use the benefits immediately and make additional future efforts. However, "management" brings intentional design to the way the event occurs. So, we look for the "optimal" outcome in the effect of the design.

- From a cultural standpoint, "optimal" means that risk and opportunity are in balance.
- From a mechanical standpoint, the "optimal" concern is the balance of cost versus output.

Within either case, the challenge to stability and continuity is fundamentally the same: despite the uncertainty of demand, which increases complexity, achieve an intended balance.

VI.

Optimization is the name of the effort to resolve the complexity. Optimization is not just opportunistic, but instead it follows a model, to logically pursue the highest priority outcomes. Here we have two models from which to choose -- a cultural approach and a mechanical one.

A cultural perspective on standards, expertise and efficiency does not exclude or contradict a mechanical one. Both perspectives emphasizes the idea that managing uncertainty in business is a critical success factor, and they both aim for stability and continuity of the business.

Instead, the cultural perspective argues that both stability and continuity are predicated on goals, priorities and agreements -- and that goals, priorities and agreement require dynamic and collaborative maintenance.

To associate either approach with the needed business benefits, we start by identifying and cataloging the functional expectations and targets that we attribute to them regarding:

Standards -- how they contribute to functional excellence,
Expertise -- how it contributes to quality
Efficiency -- how it contributes to economy

That is, we look at each of those as evaluated from the perspective of:
- business opportunity and risk (cultural)
- execution output and cost (mechanical)


The group of findings generated about the two approaches represent our expectations of them. Those are then immediately set against the logic for creating business benefit. That delivery logic will necessarily include these two components:
- The organization's availability of resources must be sufficient to realize the expectations.
- The combination of resources must amount to the "means" for generating the events that deliver the target business benefit.
Initially, the question is whether the necessary means are evidently "more likely" to be generated and sustained for the cultural or mechanical approach. But shifting demand changes the focus.

Understanding how to deal with demand means acknowledging the challenges of complexity. Complexity features a multitude of moving parts trying to come together to hit moving targets. Generating value from the complexity is tough:
- the organization must be resourceful enough in its diversity...
- to engineer appropriate events in real-time...
- from circumstances that have variability frequently exceeding "best case" or ideal formulas.

Dynamic, collaborative access and utilization of resources may be the only path to meeting a business need -- the path facilitated by the cultural approach.

The difficulty of the cultural approach is that it is more complex and thus is harder to organize and measure in a singular, objective way. Addressing that problem, the evolving discipline of performance management provides a solution that can consolidate these influences in a centrally manageable view.

Given that, the general importance and advantage of the cultural one is that it proves to explicitly relate to a wider range of demand on the business.

VII.

Demand management is staged as a shared responsibility of business and IT.

In planning, monitoring and measuring the coordination of resource diversity and demand variability, executives find that performance management can track and illuminate IT's contribution, position and progress.

In turn, leveraging ITIL should be done in ways that aim to maximize consistency and persistence in coordinating diversity with variability.

ITIL's guidance offers IT and business stakeholders a single way for both parties to see requirements and operations. The alignment cultivated through that common view reinforces expectations that consistency will increase in the Business-IT relationship.

The business intends for that consistency to translate into business capability, but the range of needed capabilities introduces more complexity against the intended operational effectiveness.

ITIL describes ways to resolve the complexity, towards consistency in the IT enablement of business capability.

With IT organizations expected to implement management that cultivates beneficial events, bringing ITIL to performance management helps the IT organization to describe the logic and importance of the difference that it makes -- i.e., "IT's value" against demand.

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

November 26, 2005

The Value of Performance

A key threat to an organization's effective capability stems from missing the distinction between managing performance and managing value.

Naturally managers are expected to manage both, and the methods used are expected to generate information on which decisions are made about how to structure and drive the organization. If the wrong information is used, the organization may needlessly change or may change unsuccessfully. Becoming misaligned with the business, or becoming disfunctional through structural flaws, will reduce the effective capability of the organization.

To avoid the misalignment or dysfunction, decisions that provoke change must cause change for the right reasons.

The significance of information taken as an indicator of a need for change derives from a model of progress or a model of success. The model is both a theory and a plan that logically accounts for how progress or success is generated.

In practice, Progress and Success are defined in certain terms for the record, and operational achievement towards meeting those definitions is considered valuable. To be relevant to the model, information must help to account for the generation of valuable achievements.

This viewpoint allows us to understand why value and performance seem synonymous, but the distinction that needs to be made and preserved is a critical one for the relationship of the organization to its clients and hosts.

The target beneficiary of an operation has a need, and the need generates demand. But needs get prioritized without necessarily going away, and demand is generated from the priority. This illustrates that demand is actually not the same thing as need.
Meanwhile, organizational operation is meaningful because it addresses demand, and the way it addresses demand is to satisfy requirements. But different demands can "call for" the same requirement, which illustrates that requirements are not the same thing as demand.

Seeing those facts, we can understand the essential difference that management decisions and their suporting information must recognize and relate:

- Value pertains to the generation of a difference versus needs.

- Performance pertains to the generation of value versus demand.

This establishes the basis for management decisioning: managers are charged with driving and protecting progress and success, and now we know the essential terms by which they recognize and communicate the effectiveness of the management effort.


This view on the general relationship of value to performance clarifies the proper meaning and charter of "performance management". This view emphasizes that the concept of "performance" doesn't really materialize meaningfully until reference points (a model) are provided that both precede any actual execution and that afterwards evaluate the execution. The main goal of performance management must be to synchronize the actual outputs of operations with demand.

In contrast, the concept of "value" doesn't really materialize meaningfully until need is defined and confirmed. This puts planning into proper perspective: since plans by definition commit the organization to one scenario by excluding others, the importance of the commitment must be in its relevance to needs. The main goal of value management must therefore be to synchronize the actual outcomes of operations with needs.

Overall, the challenge presented to management is clearly visible. Since the "operations" effort is built around requirements, it can faithfully address them while actually becoming largely irrelevant to emergent needs. The translations of need into demand and then into requirements must be continuous and as real-time and seamless as possible if the organization is to maximize the effectiveness of its capability.

Information management techniques are developed to provide the visibility necessary for doing, tracking and using the translations. But technical support is not effective if the information is used to solve the wrong problem. For example, confusing value and performance leads management to attempt to address needs with outputs, or to address demand with outcomes -- mismatches that (worst case) leave organizations and stakeholders with false impressions of control and ROI, and with unproductive management agendas that are dedicated to changing things for the wrong reasons.

Such errors might be attributed in a general way to failures in knowing how things actually work. To avoid this very problem, management is saturated with initiatives in "intelligence" and "analysis" but there is then the complication of figuring out whether the intelligence and analysis are of the right type and the right amount.


Management typically puts a lot of attention on monitoring the "components" of a plan. But there are two ways to conceive of components.

In one approach, the plan's assumption is that there are mechanical "parts" -- such as the steps in a procedure or the quality of a particular resource being used -- and that their use is specially necessary to the intended progress and success. It's safe to say that this level of thinking is mainly operational.

But a more critical aspect for management attention concerns the actual reasons why the usage of those components is necessary, and concerns the requirements for their usage in the planned way. These are the success "factors", as opposed to parts, and the attention primarily takes the perspective of demand, not of supply.

Together, the reasons and requirements would determine that the mechanical components are "appropriate" for the organization's attempts to execute its strategy. But the components still do not drive the intended progress or success.

As seen below, the reasons and requirements cross-reference to form a framework for understanding how the organization can operate for performance. In this example application of the framework, a new product is to be reliably supplied to a target customer group. Basic assumptions emerge in the framework, representing a set of defined operational parameters or conditions that are to be managed. These are the success factors.


Now, information management steps in for decision support.
Where intelligence is concerned, if current findings indicate that the framework's success factors are not being met or validated, then adjustments would be justified -- to protect the execution of the plan from any significant divergence from the operational goal of providing relevant outputs towards demand. This would mean that the right changes are being made for the right reasons.

As for determining the right success factors in the first place, analysis is usally the weapon of choice. The framework's dimensions direct analysis at conditions that have categorical relevance to implementing for demand and thus will be about performance.

Posted by Malcolm Ryder at 7:32 AM | Comments (0) | TrackBack

November 25, 2005

Optimization, Technique, and the Function of Form

At any given time, "performance" is dependent on execution and it assumes that execution will maximally realize a certain underlying functional design (unless prevented!).

This also dictates a basic truth about performance improvement: if performance is still predicated on a design that has not changed, performance improvement cannot exceed the maximum potential of the execution to realize the design. Improvement beyond that point must be based on the introduction of a superior design.

Ironically, a superior design can produce performance greater than an inferior design even when the execution of the superior design is not as great as the execution of the inferior one. In most forms of organized endeavor, this is the phenomenon of technique. Imagine yourself on the tennis court, where a player with good technique executing only moderately well to intentions will handily beat another player doing quite well at executing poor technique.

The triumph of form over execution is how we know that "optimization" belongs in the realm of execution but may not even be critical to performance improvement. Optimization improves execution by eliminating errors or waste in execution's compliance to the demands of the design. But the issue is that improved execution may not actually improve performance because it can pass the point of diminishing returns and because it does not correct flaws in the design itself.

The "returns" we're looking for are, specifically, the influences of the design on the conditions in which the execution occurs. For example, we may recognize that we want a fire and that we need a certain amount of heat to start a fire. The heat level for ignition is the design element. The execution is the steps we take to produce the heat. Not producing enough heat is poor execution and so poor execution depresses performance. But we might alternatively find a way to start a fire with less heat. This is not an execution change but instead a design change. The reasons why less heat can start a fire are not about how good we are at producing heat, but instead they are about how other conditions combined with heat lead to ignition. Continuous performance improvement would be represented by finding ways to increasingly lower the amount of heat needed for ignition, without introducing new counterbalancing deficiencies. Continuous execution improvement (optimization) would be represented by greater and greater ability to generate just the amount of heat necessary -- something that might even become obsolete if the design for ignition changes.

A designed form is a relationship of components in which the relationships, not the components, do the work of generating the necessary effects. In getting the three-legged stool to stand up, it's not the quality of the third leg that makes the significant difference, it's the relationship of the third leg to the other two that makes the significant difference.

In the June 2005 paper, "Systems Thinking and Performance Improvement", our colleague Olivia S. Herriford, D.M., president of Herriford Consulting, describes the need to rethink management of organizations along the lines distinguishing performance, execution, and the criticality of organizational form. Below, (copyright 2005, Olivia Herriford), Herriford herself discusses the issues.

Systems Thinking and Performance Improvement
Traditional thought regarding organizational performance improvement makes the assumption that the approach is the same for individuals and organizations – that enterprise-wide excellence is simply a matter of scale. If we improve the productivity and effectiveness of people and small teams, we can impact the larger entity by making sure our programs, training, and interventions cover all the bases at all levels. According to Robert Carlton (2005), a leader in the field of Human Performance Technology (HPT), performance improvement practitioners have perpetuated this linear, mechanistic view of organizational effectiveness by focusing on isolated elements of performance – people, jobs, and job groups (processes) – as the means to the end.

The shortfall of this approach is that it has not had the impact on the organizational competence necessary to sustain continuous improvement and high performance. Organizational competence is the degree of versatility in which an organization can carry out its collective activities (O'Connor & Quinn, 2004). An organization’s capacity for leadership and high-performance is strongly related to the patterns of connectivity resident within the organization – the relative interrelatedness of its members. Connectivity creates the means by which members can work together to collectively address the tasks required to meet or exceed goals. To develop this competency requires a fundamental shift in thinking about performance. Systems thinking is at the core of this shift.

Traditional thinking about performance improvement takes a linear, operations research approach.

• Identify the component parts of the performance problem.
• Once the elements are identified, analyze and explain what is occurring at each step of the performance being investigated.
• Take the various pieces that have been identified and analyzed and explain the problem and the solution.

Carlton reminds us that this approach is flawed in having long-term impact because it completely ignores the consequences of the organization’s behavior as a living system. When each part of a system, considered separately, is made to operate as efficiently as possible, the system will not operate as efficiently as possible. A system is a thing that must be dealt with as a whole, not its parts. It cannot be divided into independent parts and each part analyzed. It is a single entity and every part has properties that it loses when they are separated from the system. Therefore, it follows that when we take the approach to performance improvement outlined above, we are eliminating from our analysis the most critical aspects of the problem or opportunity – its systemic nature and its connectivity to everything else around it.

An organization has overall properties that none of its parts have which are its most essential elements. These elements are its competencies and they can not be developed or improved one part at a time without diminishing their capacities. In other words, maximizing the effectiveness of a single department as a separate and distinct project is actually detrimental to the total performance of the organization. Today’s complex situations and challenges call for tasks to be the shared responsibility of many people across multiple groups. Organizations must shift from exclusive reliance on individuals and teams toward a more inclusive focus on connections between these entities.

Making the shift requires synthesis instead of analysis as the initial process of improving performance. The steps of synthesis are:

• Identifying the containing whole of which the component in question is a part
• Explaining the behavior or properties of the containing whole
• Explaining the behavior or properties of the component in terms of its interdependencies within its containing whole.

Synthesis defines the connectivity that a component – an individual, a team, a job, or a process – has within the system. For example if we are concerned with managerial performance improvement, we must first identify and then define the system of interactions that comprise the inputs, processes, feedback, and outcomes of managerial performance. Finally, we describe how management behaves in relation to these stimuli and expectations. Going through this process keeps our efforts in alignment with the encompassing system because they are better informed and cognizant of the impacted relationships.

Taking the systems approach to performance improvement is effective and sustainable because it goes beyond individuals to collectives – interdependencies between individuals, between functions within the organization, between the organization and its external stakeholders (i.e. customers, partners and communities). Over time, systems thinking becomes imbedded in the culture because synthesis and a heightened awareness of organizational interdependencies creates and engages shared meaning – probably the most critical of an organization’s competencies and certainly the one reason why it thrives as a continuously effective and sustaining system.

Carlton, J. R. (2005). HPT: Focused on individuals or focused on the enterprise. Performance Improvement, 44(3), 5-11.
O'Connor, P. M. G., & Quinn, L. (2004). Organizational capacity for leadership. In C. D. McCauley & E. Van Velsor (Eds.), The center for creative leadership handbook of leadership development.San Francisco: Jossey-Bass.


Posted by Malcolm Ryder at 3:19 PM | Comments (0) | TrackBack

November 24, 2005

Getting the Net Value of the 'Net

The internet is a complex organization of systems and content that is already fully deployed in live productions. So what's new? It is also a laboratory for testing and studying how we balance open sources, standards and objectives -- converting innovation into a "common good" when material scarcity is not a dominant factor. Meanwhile, business organizations in general are being encouraged more and more to pursue their structure organically and systemically through web interactions. Thus, the issue of governing cyberspace versus development, as discussed below, is actually not just about the internet but as well about the nature of the modern self-organizing enterprise...

How much "internet" is there?

For many of us, the internet is already practically ubiquitous. But despite its existing pervasiveness and our familiarity with it, the internet is neither virtually nor otherwise a "natural" environment. It's an artificial environment -- one in which a diverse population is steadily learning how to create, find and deliver many kinds of value. Given that, although the environment is artificial and is still being deliberately invented, it would seem to be in the public's best interest if it was a "protected" environment.

But because this "public" has many different constitutencies with different interests, not everyone agrees on what exactly it is about the internet that should be protected -- just as is the case with markets and national parks.

Different parties in the environment implement "controls" there to protect their own interests, but when the type and impact of these controls follows an independent agenda of the implementer, and when many such parties are motivated mainly to protect their own, then most parties have uncertain futures regarding success with their own agendas in that same landscape.

So, enlightened regulation is the thought that comes to mind -- but on what basis is agreement to the rules established? This is definitely not self-evident.

For example, an approach bred from defending the "rights" of each party to maintain its interests can't be a surprising choice, but it relies on a flawed assumption -- namely, that the active parties are actually creating the internet's expanse and that there is no significant limitation on the future expanse, therefore making it unnecessary to negotiate cohabitation in it, but rather merely to stake claims in the frontier land rush. But what's the problem? Too many tortoises in a population that includes hares. How do the tortoises get a claim?

Or another approach assumes that in much of the extant internet, "there's no 'there' there..." In this view, the only part of the internet that is worth controlling is the part that is already valuable. This cultivates a confrontation of squatters' rights and developers' rights, while leaving open the question of when the remaining wilderness has stopped being just wild. Problem: imperialism (and larceny) is a major threat.

The examples merely illustrate that stakeholders vary by the location, type and level of their interest. However, this is the whole point. Through metaphor and empiricism, the definition of the internet morphs from one thing to another amongst different users' perspectives. None of the users wants their interests to be regulated; instead they want them to be protected. Their interests define the internet for them, and in that sense they all want "the environment" they call "the internet" to be protected.

Thus, universal protection has the built in challenge of finding a greatest common denominator. Case in point: because the internet is so easily seen as an extension of some other communications infrastructure (environment) such as for marketing, academia or news, those infrastructures present norms or expectations of practice that mean differing and possibly competing sets of requirements within the internet . But you can't protect something that is all things to all people. Before the internet can be universally protected as an environment, it first needs defining in terms of the basic characteristics that can distinguish it from other environments; and then an effort should aim to ensure that the interests of one user/party there do not arbitrarily eliminate realization of the interests of others there. The key part of that thought is the "not arbitrary" clause; this effort must happen according to a policy that already prioritizes the different types of interest before they get to exert themselves.

Naturally, we debate how to set those priorities... but we should not be looking for the perfect answer; instead, we need a consistently appropriate way of arriving at an answer.

Protection versus Regulation: Policy versus Rules

We start here with presenting the internet environment by a signature common denominator. The elementary presumption is that everyone should have the right to access and exploit this environment's inherent support for distributing and otherwise managing digital hyperlinked media. Yet our experience of this exploitation and this "everyone" is incredibly complex. The US vs. foreign countries, the government vs. large corporations, and the whole scene regarding industry vs. hackers/cybercriminals -- all of these confluences drive intense debate about how to govern the internet, and complicate our concerns with ensuring a universal right.

We know from such problems that you cannot actually regulate the environment any more than you can herd cats. Instead, you can do two things: you can "constrain" the environment by limiting how it affects you, and you can regulate the approach to interacting with the environment.

So for example, you can regulate services, a key instrument through which you approach the interactions. Regulated services gradually build up the environment into an infrastructure. We can presuppose that this infrastructure should be "open" or freely shared, but experience shows that this idea won't be accepted at face value, because infrastructures require investments and investments are, frankly, competitive choices made by parties who already have disposable assets.

The question is, what are the principles behind the investment in and regulation of the services, for the public interest? Principles representing the "public interest" in reality presuppose that the public itself can be distinguished as a special interest group. It follows that, practically, the public should have a pertinent governance policy about services. But what, then, is the public's investment that creates an entitlement to bring policy?

Whose internet is it?

Where rules are essentially about requirements, policies are essentially about priorities. This points at the difference between constraining (via policy) versus regulating (via rules), and again we note that the environment itself is not regulated -- rather, it is constrained, while the approach to interacting with it (e.g., services) is regulated. In short, services should support policy. But whose policy, and why?

The key feature of a typical public policy is "fairness". Regarding the internet through the logic above, the public viewpoint is that Fairness itself should be "protected" (not regulated), and in particular "rights to access". However, to do that, the means of protection should be regulated, so that they are consistent with public priorities.

But equal "rights to access" is not the same thing as having actual equal access. Case in point: currently, the lack of a standard public requirement to have a "personal use license" to the internet means that anyone merely capable of getting themselves on the "info superhighway" can drive there, at whatever risk this poses to everyone else and to the environment. This is not equality, it is indifference. Meanwhile, some people, even benignly, pose much greater risks to others, and some people get much more out of their activity than do others. Obviously, this is not necessarily "fair or unfair", but it is rather a difference that might be qualified in many ways.

Against those conditions, environmental protection addresses the issue of "fairness" by balancing the risks that the environment's inhabitants pose to each other by their pursuits. The intention of the balance is that for any inhabitant, the environment effectively offers what the inhabitant distinctively needs from this environment, which clearly must also include preserving the user's opportunity and thus means preserving the environment.

Yet, fairness in no way dictates that the inhabitant must use this particular environment to satisfy need. Merely showing up does not bestow any special rights. Meanwhile, an environment without barriers to entry can easily collect a population, but a population is not automatically a "public". In sum, the default situation is that there are no public rights. To get them and assert them means we have to argue for them successfully.

Development
For the idea of the "public" to be effective, it must intentionally qualify members of a population, with a notion of membership that assumes a desirable commonality of interest. "All Comers" and "Public" are not synonymous. Members of the public have obligations to each other. All comers don't.

But both groups show up in the internet of their own accord; and when they do, both groups encounter the same three general circumstances describing the environment. These three conditions simultaneously exist, and come to the foreground of the user's consciousness mainly according to what it is that the user is trying to do.
- In the first, voluntary use of the environment comes with an "as is, at your own risk" norm of support.
- In the second, operation within the environment is facilitated by agreements and development.
- In the third, synthetic engineering of the environment optimizes the facilities.

In fact, different users provide, enjoy or cultivate these conditions according to their own various agendas. Thus, in determining a universal policy for global usage, support, facilitation and engineering become the primary subjects of policy assessment -- as a user's activity in each subject area is examined for its impact on other users and assess those impacts in terms of fairness.

Defining the stakeholder
In this impact assessment, the normal presumption is that any given user's requirements can be adequately identified so that it can be determined how critical the environment is to the satisfaction of the user's needs. That criticality is one standard dimension by which a user population can be anticipated, segmented, triaged and prioritized. Users discovered having less critical dependency (current or future) on the environment might be assumed to have "lesser say" about how the environment is to be managed.

But there is a pre-qualifying issue, which is the question "Why are the user's requirements considered to be 'requirements'? Can we be sure that they are not simply options?" In short, how easily could the user get what they need from someplace else?

In that light, we logically look for the motivation behind the user's need, understanding that the motivation generates objectives that the user decides to meet -- objectives which in turn spawn the user's view of certain options being "requirements" instead of just alternatives.

The thing is, as a community of potential users or as a population in the environment, we are not obligated to agree with the particular other user's objective. Thus we are not necessarily in agreement with the related means, conditions and consequences of pursuing it. Nonetheless, at the ground level, the internet is actually developed, and still developing, mainly through the decisions made about executing these pursuits.

Assessing the stakes
Policy makes a difference by explicitly implementing key aspects of governance of the relationship with the environment. In the effort to establish policy, we cross-reference support, facilitation and engineering against means, conditions and consequences -- creating the basic framework for comparative assessment across different user objectives.


When we thus look within this framework at how means of support, conditions of facilitation, consequences of engineering, or other factors might develop or manifest themselves, we determine alternatives, risks, services, and other concepts that represent the interests of different stakeholders in the environment.

The translation of interests into rights is the logical imperative of the policy. The presumption of the public policy is that individual parties do not encounter or enter the environment with "inherent" rights -- but instead that the policy allows the public to grant rights according to "public interest". Without a policy, there is no common "granting" mechanism other than culture and power -- and those two mechanisms may be randomly at odds with each other even as they bilaterally shape and reshape each other. But characteristic of our times, we really can already take the use of the internet for granted. Thus, as a global device for real-time interaction, the internet begs for a cross-cultural "public" to arise -- making reconciliation not just important but urgent.

We have seen the Internet, and it is Us
In a given environment, potential users of the environment will gravitate towards less randomness as a matter of common sense. Their general modes for acquiring increased certainty span R&D (build), subscription (buy), and sheer hustle (borrow). All of these modes do present practical challenges to users, who consequently find themselves separating out according to their differing ability to effectively take advantage of each mode.

But while such segmentation naturally occurs, this observation in no way specifies the party's particular "use" in question. The attempted uses range freely across the segmentation -- and as uses are discovered and cataloged they represent objectives that must be assessed by policy. These objectives are the first order of policy business, with the opportunities for their satisfaction being a key topic of protections.

Meanwhile, the internet is -- almost by definition -- a network of networks. Standardization of the protocols for internetworking does not per se dictate that access to all networks should be a universal right. Any given network is greatly understood as an ecosystem, and not all ecosystems are compatible with each other. Extending the comparison, an ecosystem is like a subculture. Policies should constructively serve subcultures, but this raises the issue of when and how much the policy for one subculture should be required to support another subculture, so an assessment should tackle this too.

Commercial marketing, news journalism, and academic research are examples of distinct subcultures. Operating within the internet, under different dynamics and having different agendas, they co-exist without necessarily co-operating or collaborating. In exploiting the basic internet technical architecture to create operational infrastructures for themselves, they each present respectively different requirements, which are variously satisfied through built, bought or borrowed means.

As cohabitants of the internet environment, the different subcultures may actually share operational means, but the terms of the sharing are neither mandatory nor guaranteed. Rather, these interactions of different communities come with the same set (scope) of issues already identified in the above framework of policy assessment.

Our framework is portable; each different subculture may use it to assess and tailor its own policy. But the framework also searches for the same issues regardless of whether the scale of user comparison is personal (person-to-person), organizational (group-to-group), or greater. Policy can be assessed and set for the different scales.

Each subculture may have its optimal policy. This makes us wonder about the need for compromise, or in general the way to achieve reconciliations. But although multiple subcultures or ecosystems are present, and while many different levels of interaction are simultaneously active in an subculture, the framework's similarity of scope across the different groups and scales logically suggests that there is not a need for some superpolicy (or "policy of policies") to govern any given ecosystem -- nor the network of ecosystems.

Instead, it is more appropriate to move to strategy as the enabling and unifying discipline for public governance.

The internet calls for a strategy of environmental management, that states what kind of value is the goal of the public policy and thus directs all supporting logics used to reconcile the complexity of its population's diversity.

Growing and Harvesting the Net
In the political realm, global does not mean universal, and rules do not mean rights. Consequently, the ethics of environmental protection cannot be articulated as absolutes but only as motivated responsibilities towards goals.

What emerges from this perspective is that governance is likely to be ineffective without strategy, and that the translation of policy into rules is likely to be ineffective without strategic agreements amongst stakeholders.

Because our highest-level community perception of the internet is that it is a "resource", we attack the "environmental protection" issues from the viewpoint of "resource management and optimization."

But at the ground level, what complicates the issues in practice is that operations to often reduce the discipline of managing the resource into the management of artificially produced assets. In effect, asset management competes with strategy as the value system for governance.

Internet policy for the public interest cannot be rationally successful when dominated by asset management, because assets are essentially private and, aside from notions of quality, require no ethical influence at all to be successfully developed.

Whereas, (in the common parlance of Archestra research) a resource is "an asset with an assignment." iven that assignments would be to serve the public interest, managing the evolution of the internet on the basis of "resource" is a profoundly different objective than managing on the basis of assets.

Without at all confusing "global vs. universal" nor "rules vs. rights", the conversion of assets into resources can point at the key concepts of public interest and commonwealth. Management of the internet should be based on growing resources, not growing assets. In parallel, the translation of interests into rights, through the influence of policy, must be based on strategic management of resources -- judiciously cultivating a shield of protection for the environment and its inhabitants.

As we assume a nearly relentless further growth of the internet's pervasiveness, putting rules before strategy can stick a finger in the dike but it won't relieve the development pressure of asset management that breaks the dam. So our mandate is to create and adopt for the internet a resource-oriented universal strategy that can be globally executed.

Posted by Malcolm Ryder at 10:18 AM | Comments (0) | TrackBack

November 23, 2005

The Value Management of Change


Planned change most often performs the task of recovering, reallocating or reconfiguring assets such that they become currently viable resources.

Benefits from changes come in many flavors, as few as there are different stakeholders and as many as there are occasions of use.

A single change might affect different parties in different ways because those parties have different dependencies, maturities and positions from which they operate. Consequently, the change affects them differently.

Thus, the potential "scope" of a change reflects multiple points of view that can variously describe the same change. Successful changes are often described through a set of "cascading" points of view that show how different levels of execution (managerial, operational, technical, etc.) coordinate.

IMeanwhile, innovations, renovations, reengineerings, repairs... all are possible perceptions of both the intended and the actual objectives of a change.

What's interesting is that not only can a single change be characterized by these different perceptions, but also that the lifecycle of a change includes several phases that may each be characterized, by those same perceptual terms, differently from the others .

In the change lifecycle, a modification to an existing structure or state of affairs can be seen to have these general phases:
- conception
- selection
- development
- implementation
- utilization

Each phase creates conditions that stage the next, but there also may be significant conditional requirements and constraints that are different for one phase than for another. These can include things like information tools, methodology maturity, funding sources, standards, and approval process.

The various factors appear differently, blend differently and influence differently -- by timing, place and stakeholder -- and by phase.

This indicates that any given phase may be driven by certain preconceptions regarding what kind of difference that it achieves will be significant -- or in other words, what value is delivered. The value of one phase can be very different from the value of another.

For example, management can take into consideration the need or opportunity to renovate (upgrade) methodology used in the selection phase. The reason for renovation is ostensibly to realign the procedure to the current requirements of the organization when the requirements have evolved beyond the incumbent (legacy) procedure. While the legacy procedure might deliver an acceptable decision towards the next phase, it might fail to support learning, partnerships, or economies of practice that better promote the organization's overall productivity and agility. Exaggerating to dramatize the point, the old way might be built for a perfect choice in one thing, while a renovation might be calibrated to produce a good enough choice in ten things.

But along these lines, we can see potential unpredictability or lack of coordination that makes each phase a constraint on the overall target value "delivered" from the "chain" of the modification's lifecycle -- but we also see that the value from each phase can influence the environment of overall operations.

This means that the ultimate change-deliverable may or may not be adopted and assessed as a high-value output. The impact of the deliverable includes an outcome that should be measurable, but the impact of the production of the deliverable is more fundamental to the economics of the organization's performance.

We have an intuitive recognition of this fact. We all know what the phrase "at any cost" really means, and it is about sacrificing our enabling infrastructure designated for sustained production, in order to drive an urgent singular outcome. We know what an "environmental impact statement" means when large-scale projects must alter the environment in order to arrive at their destination state. And "economic impact statements" typically identify projected alterations of cost/benefit relationships in many ways other than by the terms of the target change state.

The issue that is raised is the relationship of the change process to the value management practices in the organization. This relationship stands in comparison to the cost-efficiency practices associated with execution.

- Cost management addresses the consumption of allocated assets in meeting requirements...
- but value management addresses the opportunity cost of pursuing advantage by exploiting resources.

Posted by Malcolm Ryder at 8:02 PM | Comments (0) | TrackBack

November 15, 2005

How to Recognize Performance

A generic definition of performance would be a concept that works across all types of situations. Example: performance is the measured level of achievement from execution versus a given target level.

And if performance can be managed, then there is a management process that can be improved to ensure its greater intended affect on performance.

But incorporating a definition of performance in business is not a one-size-fits all practice, because business achievement means different things to different organizations. For the given organization, the definition is usually most understandable when (a.) it is accompanied by a set of "drivers" that are critically consequential to what the organization wants to produce from its capabilities -- and (b.) the organization must respond to the influence of these drivers with what we would identify (for the organization) to be necessary and sufficient execution.

That is, typically, the organization's internal idea of performance is rooted in and controlled by its idea of what is most necessary to accomplish in order to succeed versus its constraints. The importance of that idea is that it is clearly different from defining performance in terms of the expectations of third parties. Managing performance is specifically not the same practice as managing expectations.

This also emphasizes a key distinction to note between drivers and goals. In managing performance, the execution is not necessarily about responding directy to the drivers, but instead about executing towards the performance target in certain ways, because of the drivers.

In the discussion below, we explore some of the ways that organizations elaborate and configure their current activities into performance management, particularly including the hierarchy of issues shown in this following illustration .

I.

Under the general umbrella of management, both Authority and Responsibility make the same assumption: that performance can be scientifically improved. This leads to the use of a management model to represent the approach for satisfying the goals as interpreted by Authority and Responsibility. Where the management model is goal-oriented, we see it as a strategic model -- or in other words, we understand the logic of asking, "what is our strategy for improving performance?" This is exactly how we arrive at the chance to say that we have a management strategy to address the business strategy that Authority and Responsibiity defend.

Assuming that there is a strategic approach to managing something, management information has a small number of essential and different purposes. We know the purposes well, but in the process of simply calling them all out to take their attendance, we often drift through numerous different membership rosters -- differing points of view and vocabularies that leave it finally unclear whether we've identified all (and only) necessary parties... Inconsistency in the vocabulary thus leads to unnecessary complexity and misdirection, causing errors of reasoning and planning that undermine the actual capability to manage strategically.

Since the use of available information is the primary differentiating labor that management brings to production, understanding the information itself is the first fundamental requirement for adding value through management and thereby improving performance.

The two main ways that management's difference adds value are:
- processing information most effectively, to drive production itself; and,
- producing the most relevant information, continuously, to address the organization's definition of performance.

These identify the two general concepts of strategy that are in play: a production approach, and a critical outcome (goal). But differently, as we'll further see, the one issue is about decisions, while the other is about content (ideas). Performance management cannot be organized around only one of the two, although depending on the organization, one or the other concept may be successfully adopted first.

II.

From the perspective of using information to produce decisions consistent with the strategic approach, the key purposes support activities needed to meet the standards and requirements of the approach. Those purposes, and the underlying supportive activities of their own, are:

Assessment -- Discovery, Measurement, Interpretation

Development -- Design, Proposition, Negotiation, Demonstration

Implementation -- Instruction, Scheduling, Monitoring

In the overall decisioning system, Assessment issues requirements for Development, and Development issues resources for Implementation. Then, since implementations are assessed just as initial circumstances are (largely for risk), this provides a closed-loop performance management lifecycle.

These purposes and their activities rely for their realization on "information tasks".
-Inspection
-Definition
-Description
-Categorization
-Validation
-Communication

The conduct of each task is extremely sensitive to three things: levels of experience; dependence on tools; and cultural norms. As a result, the tasks all have high potential variability. This can greatly predetermine the character, relevance and maturity of the (earlier above) activities that support the three key purposes of management's decision information. While not fully detailed here, the following image quickly suggests to most of us how (and why) such common and widespread variation is likely to be found if the organization were to be surveyed. This is the ground-level where we pragmatically struggle for alignment on a day-to-day basis, seeking to actually support higher-level decisioning...


III.

The above view is quite simply different from the perspective and challenge of being consistent with the strategic goal in front of the management. Assuming that management is goal-oriented, and that the goal is an outcome objective of the management process impact, we here think about management information in terms of what it contributes to the substantiation of the outcome - or in other words, we think about the value of the information as "content". Creating valuable content is a possible result or intent of a management process, but clearly it is different from the issue of using information specifically to drive the process of management.

The importance of the difference is that decisions often get evaluated based on content criteria rather than on whether they were more effective towards the management process strategy. Companies get caught in churning or in paralysis when they can't keep up with changes in what kind of content is currently deemed valuable, after literally organizing themselves around earlier but now obsolete content. The role of decisions is to assure that the production strategy is capable of addressing goals; the role of content is to be a resource to the production stakeholders and to the customers amongst the business goal's various beneficiaries.

Some key analysts have indicated needs, requirements and drivers for performance management in lists of recommendations that might be called an "executive agenda for performance management." Typically they highlight the most potentially challenging aspects to the new practitioner. As an example, Ventana Research outlined the following items, which are here very slightly edited and re-presented in a different arrangement, grouped and annotated to explain how they fit into the big picture. (See original here)

Structural issues: establish the target current state of operational efforts
-Process Improvement
-Assessment

Productivity issues: maximize the functional throughput of investments
-Cost Management
-Profitability Management

Opportunity issues: navigate efficiently to locations of maximum capability leverage
-Compliance Management
-Business Innovation

The discovery in the above regrouping is the three different perspectives it exposes on handling performance. In most organizations they translate into different ways of defining and prioritizing performance management within organizational change -- thus they become different ways of recognizing performance. These perspectives, definitions and priorities underlie the organization's recognition of content that addresses the business performance goals. While content quality should not be the key measure of improvement in the management strategy, it should be relied upon for improving the organization's understanding of the current business goals -- and thereby support the management initiatives.

IV.

One of the most interesting apects of performance management is that the pertinent content primarily expresses ideas, thus making content a resource in the feedback loop that formulates new propositions and, thereafter, new decisions.

By managing the content in the form of instruments -- maps, models, portfolios, schedules and scorecards -- the content can be dedicated to use by the information tasks supporting decisioning. This lays the ground work for specific processes to manage performance.

For example: procedural steps such as communication and categorization already cross the organization in the form of portfolios, schedules and scorecards. The key transformations from their present use to performance management use are:
- dedication to the initiatives in assessment, development and implementation, focused on business goals
- reconciliation of their taxonomies and ontologies within a given management model
- integration of their deployments principally for the purposes of analysis and collaboration

What is it that is important about these transformations? For example: whereas to date such instruments are typically really used for planning and accounting, analysis and collaboration represent the shift from the command-and-control posture to the guide-and-leverage posture that characterizes performance management.

Posted by Malcolm Ryder at 7:34 AM | Comments (0) | TrackBack

November 14, 2005

Game Theory and Alignment via Performance Logic

Susan Gilbert, an associate professor in the practice of finance and associate dean and director of the Evening MBA Program at Emory, gives this definition of game theory:

Game theory at its simplest level is just a way of representing all possible outcomes of one or more different actions,” explains Gilbert. “Rather than ignoring what your competitor is going to do or making a single assumption of what they’re going to do, you’re going to show all possible reactions and then reason what the most likely action will be.”

"...we try and teach them to think ahead and then reason backwards to what their first move should be based on what their last move should be,” Gilbert says.

This technique is especially pertinent to competitive situations where the uncertainty lies in the approaches of other parties. But for situations where the goal is already defined and the uncertainty is about the relative tolerance multiple stakeholders have for the ways to proceed, something else might be more appropriate.

This entry will be extended over time to explore the difference between the two situations.

Posted by Malcolm Ryder at 7:15 PM | Comments (0) | TrackBack

November 13, 2005

Defining Competency

This illustration shows the basis of an expanding framework that defines the concept of "competency" as the dynamic retrieval and application of developed, integrated and appropriate behaviors on demand.

Additional dimensions may be added to the framework in the future. Sections of the framework will be used to illustrate more specific issues within the general idea of competency.

Related problems such as "core" competency will be linked to the framework or to models drawn from the framework without imposing new dimensions. Meanwhile, the framework will help to link yet keep distinct the related concerns about competitive strategy enablement, business model performance, and change management.

Posted by Malcolm Ryder at 11:27 AM | Comments (0) | TrackBack

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

November 11, 2005

Needs Are Not Requirements - A Failed Romance

This week, as in many others, our customary readings intersected in a question of whether business is the best way for customers to get what they need. Answer: maybe not!

In a handy coincidence, Joshua Greenbaum wrote that customers hate their software vendors, while Richard Snow wrote that vendors don't understand their customers.

It might be said that customers pay for a satisfying relationship without having the wherewithal to manage the relationship successfully. Here we have to separate the idea that the customer gets what they demand from that of their getting what they want. A lack of customer satisfaction is about needs, while getting what they are entitled to is about requirements. Unfortunately, needs and requirements are two different things.

Posted by Malcolm Ryder at 8:15 AM | Comments (0)

The Architecture of a System

The State of New Mexico Office of the CIO looks at why a CMDB connects architecture to operations in an excellent graphic that is led off with the following statement:

"The architecture of an information technology (IT) system is the structures of the system, which comprise software and hardware, the externally visible properties of those components, and the relationships among them."

Posted by Malcolm Ryder at 7:52 AM | Comments (0) | TrackBack

November 10, 2005

Is ITIL "strategic"?

As the shared literature on ITIL seemingly moves into the billions of pages, organizations wonder simultaneously how to get a grip on it and what the real prospects are of getting more out of it than must be put in.

What's not in debate is ITIL's importance as a scientifically attractive set of practice guides, ones which can launch IT organizations up the stream of a business's progressively increasing ability to derive value through enhanced quality:

- Practices -> Standards -> Resources -> Investments

This way of describing ITIL's impact also shows that there is a significant distance to traverse between practice and strategy.

All strategies hypothesize a relationship between operational choices and the effectiveness of outcomes. In fact, while we tend to think of a strategy in terms of "cause-and-effect", it is more realistic and accurate to think in terms of choices-and-effectiveness.

Naturally this puts emphasis on being able to define the type of effectiveness that is targeted -- after which we make relevant enabling choices. On one level, business seeks to make itself more valuable through its operations. On another level, business seeks to make its operations more valuable through the use of IT. Since its investments in IT are fashioned after that intent, the quality of its IT investments is what the business wants to strategically enhance. ITIL offers abundant guidance to "the business strategy for IT."

ITIL's management points and goals can be summarized in a now-classic itemized fashion. But more importantly, they can be stated and grouped to reflect where key business intentions about enablement through IT are addressed to extract, drive or protect value.

Utilization
-Incidents: Restore normal service operations
-Availability: maximize effectiveness of real-time business function access to the IT infrastructure
-Continuity: control risks to availability

Control
-Problems: Manage infrastructure errors
-Changes: Maximize efficiency and minimize risk of infrastructure changes
-Capacity: cultivate and evolve the infrastructure to cost-effectively meet expected business needs

Environment
-Configuration: control and report the versions of all infrastructure components
-Release: plan and manage deployment of infrastructure components
-Service Levels: manage operational compliance to IT user agreements

Operations
Service Desk: maintain a single point of contact with business consumers of IT services
Financials: manage the economy of targeted service delivery and support
Business Advocacy: bilaterally manage the formal relationship between IT provider organizations and business IT customers

Since all of those management points and goals are desirable, the main adoption issue is to distinguish them by both importance and urgency. That will drive a prioritization of the many initiatives that would support adoption of ITIL guidance in the form of operational procedures.

Identifying importance and urgency in terms of "business needs" is where links between ITIL and strategy can get forged. In general, "important" means that something is a success factor towards the need, and "urgent" means that leveraging it must be pursued in an immediate window of opportunity if its benefit is to be assured.

Satisfying the need invokes activities that IT can or should support. The quality of that enablement is generated and fortified by the IT management practices, and improving the practices draws on ITIL. But the practices must focus on how to organizationally support the established urgency and importance. So, for example, this might translate into pressure for agility, scale, economy, or other qualities -- to be met and maintained by moves reflected in the framework below:


In this framework, IT's alignment with the needs of the business is seen from an ongoing performance perspective instead of just as an individual event. The business looks at alignment by assessing how key objectives representing "successful" IT responsiveness are handled in four significant areas of business requirements. Each area of requirements is a distinctive one that represents limits and expectations on business activity. ITIL offers guidance for improving capability in each of these objectives and areas. The business, however, must determine which objectives and areas are the ones most relevant to the current and imminent need.

Combining an objective with a requirements area is a way to describe the nature of the problem to be solved, and a capability is a key solution approach. While capabilities can combine for greater effect, as is shown in great detail in the ITIL guidebooks, their value should still remain visible in terms of success addressing discrete business problems.

Managers who are thinking in terms of scorecards should consider that any capability should be measured in three ways:
- the level of capability in terms of benchmarked comprehensiveness (as inherited or trained)
- the effect of the "as-is" capability level on the problem to which it is applied (as prescribed or designed)
- the capability's impact over time across the variety of circumstances presented by the operational lifecycles and evolutions of the business (as implemented or contracted)

Appreciating the noted capability status and history, managers should look into what requirements area of the framework most prominently features relevance to the business problem at hand, and gauge the match or mismatch of capabilities within the area. This will establish evidence that certain capabilities are logical starting points for systemically improving IT execution.

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

November 9, 2005

Organizing execution; Executing organization

Project news from industry observers like the Standish Group is riveting because we all look at projects as test cases for management practice. So when an annual survey shows even higher rates of "project failure" than were reported before our consciousness-raising, it makes us worry that our improvement efforts are not solving the right problem.

One especially acknowledged point of failure in projects is the condition of responsibility being separated from authority. Thanks to folks like Howard Fallon, we have pretty clear explanations of how organizational design is sensitive, both as cause and effect, to this problem. But what's even more interesting is the view of what a project really is, and the fact that this view is not standardized despite the exceptionally high level of disciplinary formality embedded in practice standards. The variety in the views is not within the standards, but instead in the arena where project success and failure is measured -- the business.

Illustrating the business view of "projects" starts with a shift in perspective from the project activity to the project outcome. With this business perspective, it starts to become clear that the umbrella of "projects" is much smaller than what gets evaluated.

To clarify this, first consider the semantics that should typically apply to business views of activity presumed to be flowing through projects:

Production: something produced; a work of art, etc.
Project: an organized undertaking; a special unit of work
Function: a special duty required in the course of work

Collaboration: activities interrelated for production
Coordination: activities balanced by intent
Cooperation: multiple compatible activities

Authority: ownership or control of decisions and expectations
Responsibility: ownership or control of accountability
Opportunity: ownership or control of the occasion

With that as background, consider the typical overview of the business engagement with projects.


What we know is that all major deliverables to the business are mounted within a set of "internal engineering" assumptions that have critical caveats. The management of the assumptions must recognize that just because something can happen doesn't mean that it should, and just because it should doesn't mean that it must. Seen as beneficial approaches, the assumptions must support each other through successfully balanced influences on factors they have in common, like agreements, controls and procedures. Imbalances disrupt the progress towards necessary outcomes. It's okay to see this imbalance as a description of a project failure, but what we're really looking at is a system of organizational dynamics. Within those dynamics, "projects" occupy only a certain part, as shown further below.

When a production has been ordered (requested), it issues requirements that cascade down through various levels of organization. In general, operational functions are organized into projects, and projects are organized into a production. The problem is that these elements are not self-organizing. Instead, management has to organize them end-to-end. To do this, the management levers are models and plans.


But so far this only stages the desired outcome. A crucial issue then kicks in regarding the business tolerance for accommodating the requirements, especially in light of competition from other opportunities or infirmities. Here, policies and roles express systemic management influence on eventual outcomes.


With the staging (proposal) and the tolerance (approval) established, actualization relies on sustainable commitments being made end-to-end. These commitments rely on explicit compatibilities being established with stakeholder interests. Management influence comes in the form of methods and purpose (e.g. competencies and goals) that motivate stakeholder participation:


The numerous management interventions, necessary to assure that requirements, risks and resources are aligned to the business outcome, are the critical points of success or failure and demonstrate that a project per se is largely dependent on the nurturing by its environment to survive.

Here is the overview of the prospective current state that management addresses in initially planning for progress to the business deliverables. The most important feature of this perspective is its attention to the different levels on which critical change can "naturally" occur as a result of normal everyday business activity.


In this overview, we can recognize that execution requires the alignment of requirements, risks and resources, and the adoption of that alignment shapes an organization that fosters sustainable progress.

To the extent that a project is a "micro-organization", the systemic infuences apply the same way on a smaller scale. But for the business, it is important to understand that larger scale efforts -- including initiatives, programs and strategies -- will create environments around projects that will nurture or inhibit them through the same dynamics.

For more examination of the local dynamics of execution, see our article: Why Projects Fail, in the Archestra archives.

Posted by Malcolm Ryder at 6:33 PM | Comments (0) | TrackBack

November 8, 2005

Competency as Advantage

Competition brings parties together in a certain way. Each party assumes that getting what it wants means that the other party won't get what the other party wants. Yet if one party does not get what it wants, it doesn't mean that the other party will. This is why competition can always have three outcomes: victory, defeat, or stalemate.

What we musn't forget, though, is that regardless of which outcome is obtained, we still have to determine whether the actual outcome is a win or a loss for us. Why is this important? Because it keeps us focused on whether we are actually competing to win, and whether our competitive moves are actually advantages or not in terms of winning.

A similar refinement in our thinking separates "offense and defense" from "aggression and resistance"... As shown in the illustration below, they have a straightforward relationship to each other but not the simple one of being synonymous:


The basic level of competitive thinking is about deciding how to generate a gain and how to keep current holdings. We can gain and hold metaphorical ground as well as literal ground; the difference is simply a matter of how the adversaries define "territory" -- be it influence, locations, or whatever. As shown here, the two basic modes of action are aggression and resistance -- but those modes are then organized as offense and defense.

The purpose of offense is to work on the gain, while the purpose of defense is to work on keeping one's holdings. This gives, as shown within the picture's matrix, four different objectives to which activity is dedicated for pursuing advantage. As an example of the way the matrix can describe our activity, resistance might be pursued through using offense to recover lost ground. And from sports, we're already accustomed to the idea of an attacking defense, the value of which is mainly in its discouragement of the adversary.

An equally important observation about the organization of our competitive activity regards strategy. Strategy looks for the difference that generates an advantage, and rallies action around achieving the difference. If we understand that activity revolves around the broad competencies for aggression and resistance, then what we want to know is how strategy finds the leverage that it is looking for in those competencies.

Strategy basically has two places to look: in the rules of competition and in the vision or perspective that the competitors bring to the situation. As the picture below shows, leverage can be built on the behavior around the rules, or on the knowledge around the perspective. Typically, if one party can develop superiority in behavior and/or knowledge, an advantage is likely to come up. What we see in the picture here, though, is that another consideration plays into what advantage may arise. The aggression and resistance that underly the competitive action can be harnessed strategically through decisions that exploit either change or mastery in the behaviors and knowledge.


This second matrix coughs up eight more specific objectives -- points of leverage that express the general requirement appropriate to building advantage in either the aggressive or resistive mode.

Much of what we hear about these days in commentary on the critical success factors of competing companies turns out to reflect these points of leverage, and now we can see why. For example, nearly all companies are urged to develop "agility" - and here we can see that it is about exploiting change aggressively, and that disruptive innovation of course features positioning tied to invention. Likewise, all companies are urged to develop into "intelligent enterprises" - and here we can see perspective and especially surveillance covering the hope that their cousins knowledge management and business intelligence will somehow together bear the unique trade secret that boosts the company to a win.

In the end, competitors usually engage in a situation where they are each bringing advantages, but their respective advantages are different. Given all that, the best competitive effort will still be most likely to succeed because the other party unwittingly cooperates with the mode and flavor of action we decide upon. The toughest competitor simply doesn't cooperate.

What are the five key characteristics of the toughest possible competitor? Listed in order of what makes them progressively and increasingly dangerous:
1 - Competent
2 - Secure
3 - Committed
4 - Unpredictable, and...
5 - Aware.

Thus, having a net competitive advantage must always come at least in part from identifying the weakness in the opposition, and through understanding if the competitor is organized well enough to make their weakness irrelevant to the competition. Our job, of course, is to make it relevant.

Naturally, we have to understand the same things about ourselves, and that should naturally prioritize our opportunities to mount a competition. Strategy does a lot to determine how we win; but readiness determines whether the strategy can be effective.

Posted by Malcolm Ryder at 1:39 PM | Comments (0) | TrackBack

November 2, 2005

Performance Management? Say as I Do, not Do as I Say

When something becomes all things to all people, it loses its meaning. what becomes necessary as a remedy is a restating of the reason why anyone should care at all. Such is the case with Performance Management.

To go after what performance management means, let's say we ask the question, "What causes revenue growth?"... The search for the answer will take us to an analysis of operational causes and economic effects. But it will also take us to an analysis of environmental causes and economic effects. There will then be discussions about how much the environment can be characterised as the impacts of operations, and how much the remaining characteristics are affected by operations. Or, another issue might be how much the environment affects operations.

All of these angles of attack eventually wind up with different names, but all are obviously related. With o many interconnected issues, the problem before us is to pick the right problem to work on, at the right time to produce necessary results.

I.

Distinguishing the "right" problem means describing it correctly, so we must start with language.

Although there is no distinctive idea of "performance" unless goals or objectives have first been set, understanding performance is often stymied by evaluations built on a language of expectations. This wouldn't be a problem if expectations were self-fulfiling; but since they aren't, performance must be understood in terms of the path to the goal.

In thinking about performance, we intend to study "effects" as presented and represented by objectives.

Then, when we ask, "How are Operations performing", we are invoking a set of organizational responsibilities that we want to study as "causes". The issues of Productivity and ROI have a natural home here and wind up being dealt with in performance management planning.

But there is a different take on the idea of operations. Here, we can ask "How is 'performance' on the 'operational' level?" We are invoking a certain mode of realization (of objectives) which is best described not as organizational responsibilities but instead as execution decisions that we want to study as "causes". In that, we are also distinguishing operations from tactics and strategies. If strategy specifies, and tactics implement, then operations conduct. The issue of Competency has a natural home here, and winds up being talked about in performance management planning.

II.

In that second sense, an important observation to make is about whether or not operations are conducting the realization of objectives in a way that influences functions to cause desired outcomes. What's tricky to see is that operations don't "use functions" to realize objectives, but rather that operations encourage or discourage functions to do so.

Restated as a key principle: operations associate functions with objectives. This respects the fact that both functions and objectives can (and do) change independently of operations and of each other.

As managers, what we want to understand is how that association is working out. If, according to given measures of success, it is working out well, we want to know if it is something we can produce and sustain at will going forward.

In fact, we want to understand the psychology of operations - whether it has and follows guiding principles, habits and practices for how it associates functions and objectives -- and where these guides come from if they are present. Again, this is not about functions but instead about decision-making.

We also want to understand tactics and strategy, but for operations we are looking to determine that the "guides to success" are agreed and adopted everywhere that matters for the objective. This becomes, under the banner of "alignment", the goal of management practice at the operational level.

III.

"Operational alignment" -- that is, managed alignment at the operational level -- might be a prerequisite for good business operations performance. As such it would be an area getting close attention from business performance management. But on its own it might not roll up to prove that an organizational function caused the desired business outcomes. Arguably, that is beyond its scope.

What is within its scope is a concentration on having decisions of all kinds be consistent with each other in terms of the expected impact on the effort to meet an objective. Like coaching, operational alignment makes different players, doing different things, work together.

This brings us to a clearer recognition of the phrase "Operational Performance Management" (OPM). OPM is really a contraction of two things:
- the quality and progress of operational-level alignment; and,
- the evident correlation of that alignment with successful outcomes that are believed to be causally linked to organizational (business) functions.

In many instances, OPM helps to clarify whether a business function that was involved with a business success was critical, supportive, or just coincidental to the success. With OPM, management decisions are more readily exposed as the element that makes the most difference in the function's role in the success.

Most organizations will experience the realities of operational performance management (OPM) in the following way:
- OPM does not cause increased business performance.
- But, a lack of OPM inhibits or even prevents increased business performance.

In sum, the net effect of OPM is to release the part of the organization's potential performance that is currently bottlenecked behind confusion and inconsistency in management decision-making.

IV.

To make the best use of OPM's possibiities, it is necessary to maintain a resolve to describe things as they actually occurred, rather than to describe them mainly as we want to see them.

This means that when we are setting expectations, it should be done in terms of things that are known to be actionable. And in evaluating progress, we need to be analyzing effects as opposed to analyzing expectations. What matters in managing performance is the value of the effects, not the value of the expectations.

In many organizations, this can be a quite different way of describing "performance" and therefore of managing it. For management to adopt this mode, managers must appreciate the risks (namely, lost and forfeited business potential) of not doing so, as well as the prevailing politics that will surround the necessary degrees and locations of the mode's accompanying changes to the organization.

Posted by Malcolm Ryder at 7:43 PM | Comments (0) | TrackBack