« What Matters versus What Counts, Encore | Main | Notes 1.0 about Web 3.0 »

November 16, 2008

Control: Got, or Not?

Execution means operations, and whoever is behind the wheel must have control; otherwise we can pretty much anticipate that things won't predictably get where they are supposed to be, and/or that there will be a crash.

Control of operations, by definition, means controlling the range of effects produced by driving a collection of interactions. The usual approach to tracking degrees of control is to put gauges on each one of the smallest number of critical states (conditions) produced within operations -- and to use real-time gauges as continuously as possible. The correlation of the information from the various gauges tells whether overall operations are proceeding within an acceptable range of behaviors.

The collection of gauges is readily recognized as a dashboard. But the correlation of them is where the actual control begins. The diagram above shows the Archestra model for this correlation.

The model shows how to avoid non-sense metrics and focus on essential observations and connections. For example, there is a shared boundary between Priority and Plan, where the sharing indicates the need for an instrument that coordinates the priority and the plan. The instrument is Policy. Meanwhile, the primary rational coordinator of  Priority and Quality is a Standard. And for example, the primary rational coordinator of Accounting and Reporting is Rules.

Each part of the model is a part that has an independent definition and can be independently produced, implemented, tracked and changed. In putting all the parts to use, procurement and architecture and engineering are required to assure that they can interact in an appropriate way; while management controls assure that they probably will interact appropriately.

The explanation so far leaves two areas for further clarification.

First, the model shows four "parts" that are more like regions: Priority, Plan, Activity, and Quality. Many people may detect some similarity in this quadruplet to earlier models such as the "Deming cycle", so it is important to note that the terms in the Archestra model do not attempt to share the Deming vocabulary or any other. In the Archestra model here, 

- Priority refers to identifying and grading preferences, which logically precedes the other three terms as a management or "controls" concern.

- Plan is seen as step two, by which priorities are organized to be actionable with presumed resources.

- Activity then logically follows the plans.

- And Quality -- although it is always a target and likely referenced in both prioritizing and planning -- is not actually in the sequence until Activity has caused some output or outcome that must be held against the need for quality.  In a control model, the place of this last step is important because quality must practically pertain to all actuals, not hypothetically pertain to all possibles. In fact, a major intent of building controls to this model would  be to achieve streamlining and transparency of observations about each part, so that as little time as possible is required to get awareness of whether priorities and quality are aligned. Misalignment is dealt with by corrections.

Second, let's take one of the four main items just discussed, for example Quality: the model shows that two of its shared boundaries are Standard and Process. But what about the other two apparent boundaries -- Practices and Goals? Frankly, this may be a flaw in the visual representation offered. However, the intent here is not that the Practices and Goals arrows connecting Monitoring, Modeling and Accounting are boundaries. Instead, using Quality again as the example, Modeling is the primary referent for Quality, and if Modeling is to be able to succeed as the referent for Quality, then Modeling must be logically complemented by the definitions of Monitoring and Accounting. Likewise, Reporting (aligned with defined Rules and defined Events) is the primary referent for Plans. And so on.

Customarily, Archestra models offer "maps" to use for identifying defects, discontinuities, or other problems that exist in an already active environment. The model is an abstraction and can be taken prescriptively, but it does not assume that the actual environment is already organized as illustrated. The argument of the model is that its illustrated organization can comparatively expose an important disorganization in an existing actual environment, and help to promote the source of the disorganization to a high level of corrective attention.

 

Posted by Malcolm Ryder at November 16, 2008 8:56 AM