« The Business Optimization of IT | Main | Archestra Topical Framework »

June 12, 2005

Authorizations: The Logic behind the logic of Performance

Performance planning.

For actually getting desired performance, it's one of those things so automatically expected that we excuse ourselves for not even especially bringing it up -- AND we also excuse ourselves for obsessing about it.

Of course, in both cases there's the issue of who you trust to do the plan, but otherwise the main risk has typically been from head-in-the-sand neglect or denial of how the plan affects you. Often, the big picture plan has seemed too distant or fuzzy to be relevant to making the decisions that really count locally.

Now, with the return of accountability beyond accounting, we're more often forced to take a conscious stand about the plan. That is, even when we aren't the planner, we want to know how we are affecting the plan instead of affecting just the assignment in front of us.

On a personal level, this newly heightened sensitivity might be experienced in concerns about job security or advancement. We want to know "what it takes", and because companies are now so much less loyal to employees, it's more important than ever to know what the company is "really up to." That's one place where knowing the plan comes in, big time. Staying out of jail also counts, ya think? What's worth new attention on our part is whether the terms of performance evaluation are different from the plan!

On an organizational level, the performance evaluation issue is different. Organizational units are increasingly subject to cross-functional, integrated, partnered and/or "matrixed" lines of ability, permission and responsibility. Consequently, organizational operation and execution is more often a pressing issue of negotiating an output from the immediate environment, with the plan lurking somewhere nearby in the background.

That raises a question about whether the greatest practical value of the plan is to direct manipulations of the environment for action or instead to manipulate direction of the activity itself.

Rather than risk a contradiction or competition between the two, a good plan should explicitly configure the organization for the necessary functions. Multiple levels of planning detail should ensure that the configuration has some structural integrity, by offering the blueprint for linking things together. Usually that turns into process flows -- a concentration on the action and on resources for the action. But that is only half of the story.

Getting from plans to results

As demonstrated in accountability, the interplay of environment and activity makes for interesting and complex twists in the plots -- the same plots that accounting detects and documents regarding how we wind up wherever we do. Accountability for performance has to track through cascades and intersections of more than one way to be "planful." This exposes the corresponding difficulty of promoting planned action appropriately in the first place. Question: how do you know when it's not all just voodoo?

If "performance" is the name for the relative level of success achieved in meeting planned objectives, then performance planning should be the name of the process that designs the logic of the activity behind meeting objectives.

Of course, what most often distinguishes such an actual plan (before the actions) from just an accounting (a description after the actions) is that the plan's logic proposes the activity whereas an accounting confirms activity.

This is interesting because it helps to remind us that once everything has been cranked up and let out of the gates, there is a difference between describing what is evidently working and describing what is supposed to be working.

To consistently organize and share that description, imagine being able to simply stay on top of the following, less evaluating it:
- Planned cause, versus actual cause
- Planned effect, versus actual effect

And further, as if completing the visual aid above, imagine that you had a reliable way of:
- knowing what all four things were,
- knowing who else knew which of them, and
- knowing when that knowledge was really driving activities. It's enough to make you feel discretionary, or even in charge.

It further shows that, rationally, real performance management has to make decisions about when reality is posing more of a problem than it is offering a benefit, and vice-versa...

Either way, that means considering whether an actual diversion from the plan is, perhaps, a really good clue that the plan should be changed.

But managers have to earn the privilege to make that change. How?

The performance environment

If the plan's logic is not being demonstrated, but instead the logic of the actual events is either compelling or unavoidable, then performance management must first determine whether realizing the plan logic was prevented or whether things just worked around it for their own reasons.

Why? Because presumably, the plan's performance logic was also about a good shot at reaching necessary performance levels repeatedly and predictably for the duration of a designated time period.

So, either the alternatives to the plan need to similarly measure up, or the quality of the plan's logic needs to be re-evaluated. The performance manager should cover this. Of course, the result, which is a revised or reiterated proposal, will face the same potential challenges as its predecessor: the organization must have both a reason and the ability to run with the plan. That is, it must conform to the plan.

The part of the logic that configures (i.e., conforms) the organization includes the rules and priorities that authorize the organization to set in place "these" ways of doing things instead of "those" ways -- in real-time or "runtime". As a result, it turns out that authorization, by organizationally instituting proposals, is the crux of performance management.

(What! Let me see that plan again.)

Posted by Malcolm Ryder at June 12, 2005 11:57 AM

Trackback Pings

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

Comments

Post a comment