« Performance, Success, and Strategy | Main | Driving Strategy to Success »

May 1, 2005

When is a Model not a model?

Usually we develop a "strategy" based on other ways of organizing our observations. But this gets tricky. We are all the time seeing things called models that are not models. Likewise, we see so-called frameworks that are not frameworks, and so-called processes that are not processes.

Two other typical confusions compare models against frameworks (apples vs. oranges), or offer a hybrid of a model and a framework, to provide "valid" grounds for the strategy.

The toughest test of a framework, model or process is its ability to tell you how to make something that works the one chance you have to make it.

With that in mind, navigating through the variety of misnomers and mismatches is a prerequisite for developing strategy and for managing performance.

Here's the basic lay of the land:
- The Framework is where the value system for construction is defined.
- The Model is simply an application of the value system to a proposed circumstance.
- Plans then translate the model into an actual circumstance.
- Programming is like planning. Programs create and relate functions.
- Functions are executed by processes using instructions.
- Following instructions is when the rubber meets the road.

The whole point of applying a strategy is to logically drive results of intended value, but the intended impact of the strategy arrives only as the payoff of other underlyng levels of success. Although frameworks and models are offered to guide construction of strategic solutions or improvements, strategy is more like programming than it is like frameworks or models. Essentially, the guidance supplied by frameworks and models promises the effectiveness of the programming in the context that the framework or model inhabits. But the faithfulness of the program's processes to its instructions, which greatly depends on the run-time environment of the processes, will always be challenged by some degree of risk, so the design of the process must make risk management an integral part of its quality.

A key point to sign off with here is that processes must negotiate with their environments, consequently they really only "interpret" instructions. However, depending on the circustances, that interpretation might be quite literal or might range to the very improvisational. The difference is meaningful in terms of control, cost, repeatability and other aspects, but the process always finally has one main responsibility: to produce the targeted output. Organizational tolerance for the methods of the particular process may allow or disallow the use of that process, but this is what process management is for.

Posted by Malcolm Ryder at May 1, 2005 8:35 AM

Trackback Pings

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

Comments

Post a comment