« Governance: the Stakes | Main | Performance Analysis and the Six Types of Performance Management Information »

December 1, 2005

Swat versus Clobber: getting and using the Upper Hand

We track the ever-attending Bob Lewis of InfoWorld and IT Catalyst, Inc., because we can ask him anything and he'll figure out what it is in your question that is worth giving advice on. Clearly he should have been a doctor, but let's be selfish: he's here instead, so we win.

One of the best things he advised about is the strength/weakness/opportunity/threat analysis, or SWOT. Said Lewis, TOWS [not SWOT] is the logical order for a business that wants to win in the marketplace, for this simple reason: "Strength" and "Weakness" only have meaning in the context of what you're trying to accomplish in the marketplace. So for companies trying to win, looking first at threats and opportunities, then evaluating strengths and weaknesses in that context, provides a more intelligent way to decide what to focus on...

It's one of the key things in business, then, that winning means context and the idea of performance must not be separated from each other. As Bob's insight really points out, being pretty good at doing the wrong thing doesn't matter much.

So when you're measuring or managing your performance, doesn't it have to start with knowing what does matter? Then why do so many organizations try to define performance in ways that don't matter?

The classic example of this is the project that survives the pre-start justification phase by promising "ROI" but then generally gets operated only in terms of being "correctly" executed instead of "valuably" executed. Time and time again, projects get nailed by evaluators who conclude that the project didn't deliver the right thing at the right time and cost -- even though the management discipline applied to the conduct of the project has been able to fully account for its correctness, which of course it absolutely had to do. So the party in control of the project "ensured" that "performance" was good, but to no avail.

Having looked at things that way, it seems clear that there are two kinds of value to the organization. Usually, it's the question of how appropriately things were conducted (execution), versus how compatible the output (deliverable) is with the prevailing need (impact).

Indeed, using Bob's advice, we see impact (compatible output) in terms of Threats and Opportunities, with execution (appropriate conduct) in terms of Strengths and Weaknesses. But once we recognize that there are two ways to evaluate -- per effort and per result -- then it doesn't make sense to do the usual -- namely, evaluate one thing only one way and not the other way too -- for example, only execution per effort, and only impact per result.

Instead, execution has both an effort component and a result component; and likewise, impact has both components. This makes sense not in terms of actual functional tasks but rather in terms of operational context.

Keeping that in mind, here's how the work scenario lays out:

The quadrants of this picture identify the categories of terms needed for a complete evaluation, and the outer labels show how these terms were surmised and how the terms relate to each other. Execution and Impact represent the perspectives for the operations managers. But critical to this picture is the addition of the two ways that the business assigns responsibility for the business management of the conditions that the project involves.
- A "production" perspective attends to the business-appropriate conduct of the operation.
- A "product" perspective attends to the business-appropriate purpose of the operation.

The biggest problem with projects is not that the execution fails to generate significant impact, but rather that the production goes off track from the purpose that will be setting the final criteria for evaluation. If the top two quadrants are usually where Threats and Opportunities are assessed, and the bottom two where Strengths and Weaknesses are seen -- then given their alignment as we discussed earlier, this discussion now poses the problem differently: that production strengths and opportunities (as perceived by operators) don't preclude product threats and weaknesses (as perceived by customers).

Put in terms of management issues, this is really a difference between performance management (capability) and value management (competency). It is a failure to translate capablity into competency.

What clobbers capability on the way to competency? We take it for granted now that projects must have sponsors who are high enough in the food chain to provide the proper environment for project completion against other potential inhibitors from the ongoing (and competing) business concerns. These sponsors must be able to exercise value management as a way to provide the necessary "customer context" for the performance management of the production.

Value Management issues are not the SWOT we all study, but instead the CLBR -- credit, liability, benefits, and risks.

Arranged in the most effective way, risks and liabilities are considered first. The reason for this is that a new initiative, almost regardess of scale, is an attempt to produce something that will have to fit into a dynamic system of existing commitments and options. Risks and liabilities describe the potential of the current state to support the transformation to the future state. Usually, assessments should take the responsibility to account for risks and liabilities.

Credits and benefits further reflect the business's investment perspective on incorporating the initiative. Credits and benefits are more realistically defined and agreed when the risks and liabilities have already been set. This rationally divides responsibilities and authorities so that producers are not working against undefined expectations.

Production should be aware of needs and aim to satisfy them, but needs must be specfied. Specification defines expectations. The specification progressively translates needs into demand and then into requirements.

If "demand" is not treated this way, then expectations are actually left unmanaged. Meanwhile, if demand changes, requirements must be revisited. This problem pattern is already familiar, but the point is that if it is handled responsibly then the ultimate evaluation of the production effort will allow performance (capability) and value (competency) to remain linked.

In the Archestra collection of content, this link will be explored from numerous angles. Along the way, we'll make a general effort to describe the motives and behaviors that distinguish performance and value but that also suggest the linkages between them. As an example of the effort, the table below catalogs and contrasts concepts distinctively associated with performance and value. The distinctions intend to isolate the context and expectations that typify relevant evaluations.

Posted by Malcolm Ryder at December 1, 2005 6:41 PM

Trackback Pings

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

Comments

Post a comment