« How Not To K.O. KM | Main | Finding the "Enterprise" in IT »

March 13, 2006

Aligning Strategy and Production

In management conversations, the vocabulary uses ideas like value, performance, and success in urgent and motivational ways. But their usage is too often so flexible that it is nearly impossible to be sure whether the means of achieving them are being sorted out for better manipulation, or instead just all lumped together (where measurements start to lose their meaning as well). In general, less definition brings less likelihood of predictably gaining necessary effects.

To begin the more detailed look into definitions, the following line of thought offers a point of view about how -- in a context of marketed deliverables -- execution turns intentions into realities that matter.

The home base of this point of view is a significant simplification in identifying the key objectives associated with execution. That is, what does "execution" mean in the value systems of its stakeholders? It's not just about going through the motions. What is needed from execution?

As shown in the first picture below, there is a demand perspective and a supply perspective -- which are important to compare because they are basically independent of each other and yet, in order to create the value sought by stakeholders, must come to correspond and agree with each other.

- Demand asks for something, and the provider gives it through two main features: implementation that creates the factual difference between "requested" and "realized"; and, specification that ensures the right thing was realized.
- Supply offers something. Correspondingly, it promotes availability as the difference between requested and realized; and it offers quality as the assurance of the rightness of the realization.

By describing supply and demand in terms of effects, this viewpoint also allows us to include an initial mapping of the execution-related ideas called "support" and "delivery" as values. With this mapping's cross-reference, it is more evident what it is about demand and supply that stakeholders feel execution needs to accomplish. In this view, Support represents the activity in demand and supply, while Delivery represents the item in demand and supply. We understand that the intended support or delivery has measurable practical significance that from one instance to the next may differ in level while not in type.

The next key idea is that all stakeholders, despite their different roles or positions, actually have the same goal -- which is that the execution linking supply and demand will be successful in negotiating a viable relationship of offers to requests. At any given time, a particular stakeholder may have more or less interest in detailed visibility on the mechanism; but everyone wants the same overall success and can appreciate that overall execution may be a highly collaborative multi-party effort.

All the more reason to stress that everyone should be able to see themselves from a common point of view. That, in turn, is what allows a shared appreciation of the three basic elements defining the execution's success: the design, the plan, and the ultimate output or product.

Each of those elements represents a set of definitions and decisions that are made within the execution, promoting the realization of the request. Each represents an area that contains many options, making the particular decisions as important for what was not chosen as for what was. The decisions represent the actual propagation of potential value throughout the effort to realize the request.

Typically, we expect the translation of intent to reality to be captured in a plan. The following picture generically identifies and arranges the major points of reference within the plan definition that characterizes the before-to-after execution.

From the bottom up through "Workflow", we see the buildup of activity that will ultimately transform the current conditions or state (need) into the targeted later state (satisfaction). What happens above Workflow establishes the mechanism by which we can assume the right thing is actually achieved from that base of activity.

But in actual practice, the definitions of design and product, not just plan, must all be attended to in detail. Like the plan, the design and product aspects each have a hierarchy of key decision-levels that are execution components. The following picture identifies the components of the design and product definitions, along with how the key details of the plan components pertain to them.

This full articulation of the execution effort shows a series of decision interdependencies that, followed from the bottom up, chart the generation of an eventual "Production" as an accurate, reliable and safe instrument for fulfillment. The point of having and using this big picture is to create, before execution, the logical alignment of an end-to-end system for fulfillment.

Going from the bottom up, what we see about the "Plan" group of execution components (middle column) is that each of them allows a "Design" execution component to generate a "Product" execution component, or vice-versa. For example, Strategy uses Modeling to generate an appropriate Architecture; and through Resourcing, a related Organization (i.e., functional unit) is generated from Architecture; and so forth. Furthermore, the details of those Plan components reveal issues in which decisions drive the design component towards the product component. For example, the Organization will use Development to generate an Infrastructure; and in that Development there are issues about standards, methods and schedules that get decided and shape the actual path to Infrastructure. Higher up, decisions about Change issues including authority, scope and risk likewise channel requirements into Production.

In that sense, the zig-zagging between design definition and product definition is controlled by Plan items. Control is, of course, a basic management concern. Everyone wants to get all the way to the finish line. But as the saying goes, if it doesn't matter where you're going, then it doesn't much matter how you get there. Tthe most important aspect of this control is the value problem -- that is, how the control links the values in Supply and Demand.

Looking at the big picture, the intuitive expectation is usually that, Supply is "pushing" from the bottom of the arrangement, tempered by management controls -- while Demand is "pulling" from the top. But in terms of validating stakeholder value, the dynamic is different than that. We spot it in terms of support and delivery.

Given the big picture, the expectation should be that Design will build up the offer of availability that is eventually substantiated in the facilities underlying (i.e., supporting) the Product. Meanwhile, those Product facilities, through prioritization, will promote the request for implementation that is represented by the intentions defined throughout the Design.

In other words, it is not Supply that pushes upward, but instead Support.

Meanwhile, "Delivery" -- featuring an assured ability to provide the correct thing -- should be able to "poll" an auditable trail, down through all levels of decision-making. Because recipients hunt for a provider of what they specifically want and will consider more than one provider, real-time polling would be the ideal, verifying the character of current options. In other words, Design will drill-down into how the provision of the Product specification will be logically assured, and the Product must be able to track down its characteristic quality to Design origins.

That is, Delivery, not demand, is pulling from the top.

The summary of all the above is that in execution there are generally three different arenas -- the sets of definitions driving decisions in Design, Plans and Products -- within which one might track critical success factors and/or points of critical failure. By parsing those numerous issues according to a value orientation on achievement, opportunities that are relevant to stakeholders for linking supply and demand can be anticipated or detected more consistently and thus better managed. This aids fulfillment by way of enhancing problem resolution, optimization and agility -- respectively reducing risk, securing effectiveness, and cultivating advantage.

Posted by Malcolm Ryder at March 13, 2006 1:20 PM

Trackback Pings

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

Comments

Post a comment