« February 2005 | Main | April 2005 »
March 21, 2005
Policy-driven Performance
In common language, "performance" represents the degree of correspondence achieved between actual execution and planned execution. Managing performance means managing this correspondence, from its inception to its realization. Too often, that is interpreted merely as "command and control" -- with the result being that both the business motivation and the business impact of the execution can get lost in the shuffle. Among other problems, this disconnects competencies from strategy, and it disconnects investments (resources,costs) from value.
Whereas control often relies on a prescription of procedures, what is needed to ensure that motivation and impact are kept in the picture is a prescription of priorities -- or in other words, policy.
Embedding policy into the organizational structure allows operations to be driven on the basis of motivation and impact. This embedding takes place in several steps.
First, companies need to base planning on a picture of the future, and that picture must be predicted from facts (i.e., conditions having a persistent predictability of occurence).
But how does the planning use the picture? Normally, plans describe activities that are goal-oriented, and the role of the future picture is to describe those goals.
Through analysis, Business Intelligence (BI) helps to discover goals that are both plausible and valuable. For that reason, BI continues to stake and even expand its claims in performance management. BI is usually thought of as decision-support, but here it is more precisely selection support. Goals discovered through BI are plausible because, as BI analyses show, they are likely circumstances. And they are valuable because they represent a circumstance that, as evidence has shown, relates to benefits for the company.
Thus armed with expectations that are backed by analysis, plans describe a model of the future in terms of a proactive organization.
But once those plans are in place, the effort begins to translate them into reality. This translation has two key aspects: authorizations, and operations.
Historically, authorization has meant executives granting permissions to operations, giving operations approval and responsibility for certain actions. But today's business finds that capturing value from the marketplace increasingly calls for allowing wisely chosen customers and partners to set requirements that represent defacto permissions.
To translate these requirements into real and enabling approval and responsibility, the business must categorize, prioritize and rationally delegate the requirements, stating and communicating them to activity centers throughout the organization.
Each center of activity must be able to interpret a requirement as a combination of a goal and a priority.
Meanwhile, to make the delegation of the requirement rational for the given activity center, a cause-effect relationship must be known or established, between:
- (on the one hand) the center's activity and the goal, and
- (on the other) between the center's opportunity and the priority.
The scope and scale of the activity center usually define its breadth of activity and opportunity but usually cannot drive its performance; whereas the goal-priority package of a requirement determines what the center will actually try to do.
Overall, in making requirements the direct catalyst of operational decisions, the responsiveness of the organization becomes oriented towards policy whereas previously it had been oriented towards command. Managers then harness that responsiveness as the essential resource and capacity for realizing plans.
Posted by Malcolm Ryder at 1:29 AM | Comments (0) | TrackBack
March 16, 2005
The Nature of Management
Management likes control. In most business organizations, operational control is a packaged deal - a bundle consisting of a core uncertainty, wrapped in tolerances, wrapped in procedure. Because control is established that way, whether the wrappings are looser or tighter, it is often only the procedure that is detectable evidence of control.
What's more, procedure is often the only evidence of operational consistency -- that is, something that managers want to be accused of when things do work, and want to not be hostage to when things don't. But managers should not -- must not -- mistake procedure (nor superficial consistency) for management.
A business likes to take it for granted that certain things are possible because managers have other things under control. This is similar to assuming that you can get to work in the car even on a pretty stormy day. To dramatize this assumption, imagine an angry person driving a powerful car on a bumpy road in the rain -- altogether an operating environment of at least four pretty major forces interacting: temper, motor, surface variation, and weather. We might even think of each force as a "system".
But first facing facts, the commute is all predicated on the notion that these four forces will interact within a usable range of uncertainty, otherwise the deal is off. The combination of forces may at any time become fundamentally unsound for the purpose of completing the travel. Each system is capable of independently excelling at what it does but likewise interactively throwing the overall driving "environment" out of whack for the intended purpose.
All environments have a deep structure that is simply:
- whatever forces are in the environment;
- whatever types of dynamics are generated by those forces;
- whatever types of regularity there are to the dynamics; and
- whatever interactions between those dynamics is likely to be generated by their regularities.
And then there's management. Basically, management brings interventions to the "natural" scenario that develops from the existing forces. The most useful way to account for these interventions is to simply call them tasks.
Broadly speaking, tasks either help to navigate the environment or help to reengineer it, usually by acting on the dynamics. Introducing counterforces that redirect extant dynamics is always popular; changing the systems that generate the forces that create the dynamics is also a well-worn path. On the other hand, anticipating their patterns and threading through them or leveraging them is the minimum requirement.
To more fully imagine those options, think of any operating environment as a pool of magnetic syrup, in which the manager can introduce fences and gates; steps, pits or inclines; heat or cold; and of course, more magnets. Performing tasks that distribute these interventions in one way or another, managers get the environment to more or less take a desired shape with a desired level (or degree)of stability. The logic of the tasks and distributions is the design. The purpose and duration of the shape is what lets the business do what it is trying to do -- or stops it. The manager's responsibility is to keep conforming the shape and duration to the real-time needs of the business, in effect, to exercise continuous deployment of productive interventions. Because of the frequency of business change, uncertainty is always a given whereas procedure is not. And this is why, in management, design is both more powerful and more essential than procedure.
Posted by Malcolm Ryder at 4:37 PM | Comments (0) | TrackBack
March 14, 2005
Measurement and the mythology of Execution
"Mythology" is when prescription substitutes for description. On a day to day basis in the operating environment, we see it frequently, when, due to past experience, something we thought should "be there" is presumed to be there - setting an expectation that is basically an emotionally charged exaggeration.
Such expectations challenge measurement's role as the basis of management. Often measurement devolves into looking for what we want to find instead of for what is there - that is, prescribing instead of describing, and making the facts fit the expectation. In management-by-mythology, wishful thinking rules even more than measurement.
But recently, a new standard of advice has swept business management communities, advising that the way to restore objectively meaningful measurement is to focus on "execution" and measure execution. For a business, this might actually help things by further emphasizing the discovery of "causes" for the effects that the business wants from its activity. After all, desirable effects are the business's most important wishful thinking, although made significant only by the means and motivation applied to pursuing it. The new management focus is mainly one of correlating defined action ("inputs") with defined consequences ("outcomes") instead of with products ("outputs").
The likely point of failure in this attention to "execution" will be an urge to think of execution as activity instead of as result. Execution is what is achieved by activity, whereas the activity itself is operation. Managers who optimize operational consequences will be working on the realities of execution; managers who optimize action efficiency may only be working on quality and must commit that quality to a cause.
Posted by Malcolm Ryder at 6:35 AM | Comments (0) | TrackBack
March 12, 2005
Business Alignment in ITSM
Much of what can be figured out about aligning the impacts of IT with the objectives of the business requires the willingness to understand IT as a business. This helps to bring a vocabulary into play that is less technical yet entirely pertinent to the problems at hand. But IT disciplines still need not be forced to resemble non-IT affairs; instead, their business context and direction is what makes them valuable where otherwise they might have just been forceful.
With the business seen as a customer, it is easier to accept that IT impacts should be "productized", and that evaluating IT should happen from the perspective of whether the business is getting a good deal for what it asks for when it orders what IT can offer. The general story is one about the product provided for the payment made. The more specific story is told in terms of how IT takes responsibility for what the business experiences. The following illustrates this story.
Service Availability & Capacity features the management of engineering, configuration and utilization.
Investment Protection features the management of procedures, resources and demand.
Both revolve around “quality”, which is essentially the perceived difference between the provider’s delivery and the receiver’s expectation.
Quality issues pertaining to business reliance on the IT infrastructure most readily surface in three types of events: incidents, problems and changes.
The language required for understanding this perspective on quality needs to be generic, but it mainly points at risks:
- Incidents refer to interruptions of normal user activity.
- Problems refer to defects or errors in intended product makeup.
- Changes refer to alterations of authorized standard provision.
In all cases, the biggest issue is that they occur unexpectedly and compromise the value to be delivered from their respective subjects (i.e., from user activity, product makeup, and authorized standard provision). Timing can make things better or worse.
Against those uncertainties, control is sought. A “control” should be understood generically – as an instance of formally combining a responsibility and authority within a supervisory activity.
Investment Protection works against the erosions of optimal value by proactively instituting “controls” on how:
- the availability and capacity of the infrastructure (as established through engineering, configuration and utilization)…
- … is maintained against the essential business requirements – which are, namely, the pressures of compliance (specifications), cost, and supply levels.
This table generally shows how, from bottom left to upper right, controls for maintenance of service against the business pressures follows suit. For example, at their respective points, managing certifications directly acts on compliance to specifications, while managing orders directly works on levels of supply.
Meanwhile, the connections of one set of controls to another is conversational:
- from left to right, or from bottom to top, the dialog is mainly about assuring response capability;
- from right to left, or from top to bottom, the dialog is about enforcing current priorities.
Business-oriented IT solutions naturally look at integration across IT and business disciplines, by emphasizing attention to these conversations.
Posted by Malcolm Ryder at 7:29 PM | Comments (0) | TrackBack