« Justifying Performance - Ambition versus Reality | Main | IT Economic Impact Management »

September 18, 2005

Aligning Execution and Performance, with Process

Recently the difference between "outputs" and "outcomes" has been a major topic in maturing the management of performance. It is becoming clearer that performance pertains to outcomes while execution pertains to outputs. But if performance depends on execution, then the key question is, how do outputs drive outcomes?

When we say "performance", what differs it from our idea of execution is our intent to talk about how close the impact of execution came to what we wanted and/or expected.

When we say "execution", we're trying to point at the way that things got done on the way to that impact.

But noting the difference, we should also add that explaining the output doesn't explain why it has the impact that it does. We should also ask what makes the impact a probable companion of the output. What we'll find is that the role of a process is to make that probability as high as necessary.

I.

Our most typical perspective on performance assumes that outcomes have prerequisite underlying outputs -- and thus that missing, defective, or incorrect outputs "account for" poor performance.

Solving those problems of omissions, defects and errors takes us to investigating whether the means of execution are properly coordinated. But beyond that, we also need to know whether the conducted execution was aimed in the right direction.

Consequently, solving performance problems, there are two major areas of solution investigation -- both falling under the heading of alignment:

1. Quality: of actual procedural integrations
2. Effectiveness: of actual influence on conditions

II.

Take the "quality" area first. Following the typical advice, procedure investigations would look into the connections between people, processes and technology. In one way, this is intuitively correct thinking; an organization can almost always be described in terms of the way it designs, selects and deploys those three fundamental "resources" for execution. But in more than one way this is a fairly awkward approach unlikely to lead to proper solutions.

One problem is that the three items -- people, process and technology -- are not defined on the same logical "plane". If we were instead to normalize the way they are managed, we would have at least a two-tier set of items with the lower tier being people-events-tools and the upper tier being workgroup-process-system.

The second problem is that execution requires not only "resources" in the sense of items that can be cataloged as assets and "qualified" for duty; rather, execution requires a configuration of resources, which creates the functional environment for execution called infrastructure.

Simply described, infrastructure includes facilities and services for operations. What we've been learning more and more is that infrastructure is an idea that must both shape and accomodate the dynamics of the operating environment, and thus become less exclusively a set of fixed objects and more inclusively a set of controls that direct access and navigation to and amongst facilities and services.

The overview of necessary connections within the infrastructure means that we look at the following configuration and control-related issues:
- people-to-people connections: including workflow and communications
- people-to-systems connections: including applications
- system-to-system connections: including platforms

What this does is to indicate how procedural alignment (and its quality) must be composed for execution, meanwhile making it much more explicitly clear that two organizations with the same "resources" can get drastically different "results" (outputs) from their interconnection and utilization.

III.

Next take the "effectiveness" area. The influence of outputs on prevailing conditions largely depends on how the outputs are actually used. What this means is that it is most logical to understand execution as "production" and then understand the value of that production in terms of how management "markets and manages" the products. Since the value of the products comes mainly from their ability to satisfy important demands, the main perspective of practical use for solving the influence-oriented alignment problem is one of demand management.

What we've been learning about demand is that it must be seen in two ways -- as defined need, and also as defined requirements -- thus the fulfillment of demand is always subject to revision in two directions. The usual situation, though, is that a given party with one need might send that same need to two different parties, and find that each party will differently interpret the need into requirements.

Simply described, demand management by the receiving party defines or discovers demand, assesses it, prioritizes it, fulfills it, and tracks it. In support of that, it includes all the following mechanisms, each of which has an output:
- requests
- analysis
- policies
- routing
- assigning
- monitoring

With the key issue being how those mechanisms are all required to address the particular need, what this does is to indicate how directional alignment (and its effectiveness) must be composed for execution. Meanwhile, those mechanisms all rely on the infrastructure.

As a way of defining the mode of influence that outputs have on outcomes, a process states that "if the need is... then our response will be..." and it organizes the response according to requirements. Meanwhile, by putting that stake in the ground, the process challenges circumstances to prove that other requirements might be necessary or better than these in meeting the need.

IV.

By finding that resources and outputs per se do not determine outcomes, we find that "production" procedures and "product" direction must be managed both separately and together, because they can change independently but must be related for meeting demand. In focusing on their underlying dependencies for the sake of making improvements, we recognize "infrastructure" and "process" as areas in which management creates alignment between execution and performance.

Posted by Malcolm Ryder at September 18, 2005 8:00 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/131

Comments

Post a comment