« Hey, What About Me? | Main | Recognizing Progress: Effects versus Results »

June 18, 2006

Operations Value versus Operations Performance

To say the least, operations are a lot of costly effort. Then, because we're concerned about what our expended effort is worth, everyone wants to measure value and measure performance.

But not many bother to distinguish the two well enough.

The point of measuring performance is to determine what one's effort is worth. In fact, we'll often think and say that if performance is good then the effort was "valuable". But it doesn't necessarily follow that the effort wasn't valuable if performance was not good. Why not?

Don't confuse "value" and worth: instead, think of worth as the target impact of the overall effort -- or in other words the goal.

Meanwhile:
- Performance indicates how close to the goal your effort got you;
- Value indicates what was effective about how the effort got you there.

The danger in confusing the two is that steps taken to "correct" or "enhance" previous results can too easily turn into solving the wrong problem. For example, in the name of getting better results, changing value doesn't necessarily change performance -- nor vice-versa.

To choose and make the right kind of change, and to know how it will finally help, each kind of change -- value or performance -- must be accurately conceived, and their relationship to each other must also be defined.

I.

First, consider value. Put simply, value within operations is identified in the production of a significant difference.

Ordinarily, we think that "significant" means that things didn't just get different but that they got closer to what is desired. But more strictly speaking, any difference that alters the dynamics of conditions from what they had previously been must be recognized as "significant". In that case, determining value means understanding the meaning of whatever actual difference has occurred -- whether the meaning is desirable or not.

One of the main reasons to recognize different roles in organizations is to be able to focus on different kinds of value being created. For example:
- Leaders see themselves as creating culture.
- Managers see themselves as creating viability.
- Implementers see themselves as creating capability.

So they each have different ideas about value -- and also possibly about performance. More importantly, these different approaches have to be leveraged in a way that actually does improve overall performance, which means there must be some model or "performance logic" that explains and reconciles how the various approaches get the job done.

Let's take the example of what a business wants from an IT organization. To understand this relationship properly, it must be recognized that a business person who has responsibility for leadership, management or implementation is in the role of a "leader", "manager" or "implementer". Where IT is concerned:
- Leaders want IT to provide advantages through innovation and cost-reduction.
- Managers, serving the leaders, want complexity and risk minimized, and availability maximized.
- Implementers want customizations and configurations to be prefigured and completed, not ad hoc and hurried.

And to fully understand that state of affairs, it must be recognized that ideally an IT person can take on all of these roles as well. What should happen is that in sharing a given role, the business person and the IT person should divide the labor called for within that role, and conduct the labor to make the appropriate kind of difference with that role.

The division of labors starts with clarity on what the issues are to which each role should be primarily attentive.
- Leaders see change in terms of Opportunities and Threats.
- Managers see change in terms of Strengths and Weaknesses.
- Implementers see change in terms of Norms and Exceptions.

With the issues distinguished by role, a given role's two main viewpoints on responding to them are as a Decider and as an Enabler.

II.

In the Business/IT example, it is common that the Business takes the Decider view and IT takes the Enabler view. But -- to cite an instructive case in cooperative role-fulfillment -- these days IT executives are usually strongly urged to acquire the ability to understand things from both points of view, and to exploit that ability within their responsibility and domain expertise for managing IT.

In pursuit of goals (i.e., worth), everyone wants change to be positively valuable instead of indifferent or destructive. In the normal business context, recognized value is associated with the ability to positively influence the customer's acceptance of what you want to offer. For this purpose, the roles align with each other to systemically (not systematically) address each other's requirements and leverage each other's contributions. Leaders look at the market and respond to it; but Managers respond to the leaders, and Implementers respond to the managers. In the flow of requirements from leaders to implementers, this alignment -- or better, coherence -- can draft progress towards the goal. The point is that each role makes a kind of difference that nurtures the effort of the role next in line. In the following illustration, we go further and argue for a fully interconnected set of relationships.

Given this "closed loop" view, the final link of alignment would appear to be that Leaders will also look to Implementers in some way, not just to the market. Superficially, it's hard to argue against that link being "evaluation" or "assessment" -- that is, leaders taking the time to decide whether the implementers (were able to ) have realized what is needed.

But based on long-standing arguments in the field, most organizations need a better understanding of what this last apparent link is really about. The starting point for clarification is simple: Leaders should not tell implementers what to do -- but instead tell implementers what is needed. The better Business gets at defining needs, the more likely it will wind up with something valuable that it wants -- so it falls to Leaders to assure that Business Needs are well defined and communicated. For example, in the classic case of trying to coordinate business and IT interests, leaders need to set the business agenda for IT -- but business should not set the technology agenda.

But how do they forge their cooperation?

III.

In general, agreement, not command, is the "constructive" mode for their coherence or alignment:
- The business agenda for IT is made up of objectives; it should be all about when and why. Leaders and managers should agree on that -- on when some condition should be developed or pursued, and why. This will be reflected in planning.
- The production agenda is made up of requirements; it should be all about which and how. Managers and implementers should agree on which activities should be executed and how. This will naturally be reflected in the choice of producers but will also be reflected even more basically in processes.
- The technology agenda is made up of resources; it should be all about what and who. Implementers and Leaders should agree on what gets used and who gets to use it. But that agreement will be based on business needs. Policies, especially, will hold this connection.

The set of agreements describes how the continuously interacting roles stay contained in the loop.

How does this model the logic of performance instead of just the range of value types?

Going back to the basic definition of "performance", the focus is on how far the effort has taken us towards the goal. The key idea of the performance logic is that certain types of value are created by the effort, and the value-types combine to foster progress towards the goal. The "logic" of the progress is in how the value-combinations create advantages for, or remove barriers to, progress -- and the punchline is that progress itself must be defined before it can be measured. In the model offered by the diagram above, performance is seen in the additional degree to which a goal-oriented change means capability (through implementers), viability (through managers), and acceptability (through leaders). Said differently: what can be done, how well can it be done, and how much will we support doing it? To the extent that those factors account for successes already noted, their combination may be used as a predicter of future success. For the most part, amongst roles that generate these "success factors", the coherence provided by plans, processes and policies mirrors and directs the logic and its re-use.

The table below pulls together the above thoughts in a representation of discovering and cataloging the generation of these success factors. It overlays the distinction of the key roles with the main viewpoints within each role. The table lays out the task of identifying what decisions and enablements can be associated with each role -- and from there, alignment would be tested or attempted in plans, processes and policies.

IV.

Postscript:
Because production flows from implementers to the leaders, Managers bear the responsibility for proving that implementations can be aligned sustainably with the business objectives. In effect, Managers act as the "agents" and "brokers" for Leaders.

Of particular note in the IT example scenario, change is the biggest problem in IT, because it challenges standards, forecasts, and budgets -- all the things that make it possible for managers to minimize complexity and risk. For that reason, Change Management must be something that Leaders are willing to be champions for, otherwise they should not expect managers to do well.

Posted by Malcolm Ryder at June 18, 2006 7:25 AM

Trackback Pings

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

Comments

Post a comment