September 21, 2007

CIO 2.0 part One

Faisal Hoque, father of the Business Technology Management Institute, talks about the issue of solving the right problem instead of the wrong one in the CIO Insight article "Convergence, Yes; Alignment, No." As CIO Insight put it, Hoque noted that "rather than a goal, alignment is a stage on a journey to a more complete merging of IT and business that he calls convergence." With convergence, Hoque explains, "The business model is so intertwined with IT that there's no separate orientation."

What are the key features of this view for the top IT manager, for the CIO of the future? The same as for the CIO of now.

The first is the working definition of IT, which must position IT as business technology. This means technology of the type of business, not technology owned by the corporation of business. Here is a brief primer on business technology:

The second key feature is the working definition of "management". In the abstract, this has to mean "drive and authorize all key decisions about the utility value of the phenomenon at hand throughout its lifecycle." Naturally, the scope of this responsibility may involve or even necessitate collaboration and power sharing, and this means that a model of value-generation must exist to which all can subscribe. If this is to occur with IT, the concept of "IT" must be "operationalized":

From there, the third key feature, the point of it all, is to apply the operational potential to the business needs: this is how the IT model becomes the "dynamic" of the business model.

dynamic

1817, as a term in philosophy; 1827 in the sense "force producing motion," from Fr. dynamique (1762), from Ger. dynamisch, introduced by Leibnitz 1691 from Gk. dynamikos "powerful," from dynamis "power," from dynasthai "be able to have power," of unknown origin. The fig. sense of "active, potent, energetic" is from 1856. Dynamics as a branch of physics was in use from 1788.

Online Etymology Dictionary, © 2001 Douglas Harper

Given the numerous points at which IT could be mapped to needs, it isn't hard to appreciate that the current state of a business operation may have to go through significant re-modeling (transformation) to base the business model itself on the influences of IT. Speaking of that, the evolution of IT's realization as a business enabler actually is a goal, not just a stage. But the sneaky punchline to this is that the business may not need to be its own "IT-enablement" provider. Fusing the IT model and the business model (value management) is not the same problem to solve as the problem of establishing competency in the role of IT provider (performance management).

(This discussion continues in the follow-on article CIO 2.0 part Two.)

Image credits:
http://www.how-to-draw-and-paint.com/images/BasicHorse3.jpg
http://www.chss.montclair.edu/~pererat/7751.jpg
http://www.tsc-global.com/index1.html

Posted by Malcolm Ryder at 5:29 AM | Comments (0) | TrackBack

July 9, 2006

Driving Action with "Values"

In most conversations about how to properly focus an organization for success, the prescription calls for the organization to leverage its identity as a source of performance strength. For doing that, the notion of "values" is promoted as a major success factor.

What makes "values" so important? The key ideas are that it is typically easier to maintain effort for what one believes in, and that not knowing what matters the most "internally" leads to an inability to sort out and navigate through what matters the most "externally".

In trying to make "values" an integral part of operations, the organization will typically develop priorities; then it will group and cascade the priorities into policies -- ones that can be applied as instructions accompanying activies that the organization anticipates it should conduct or host.

While policies provide the practical expression of the priorities, many organizations are only partially successful at providing them and even creating them. The initial challenge in developing the priorities is usually to decide not just what is considered to be a representative "value" but also to get agreement on why it is necessary to hold onto it. The challenge is made tougher by the fact that the circumstances surrounding the organization may be constantly changing in important ways demanding direct attention. Further, the identified priorities may seem to compete with or even contradict each other.

Consequently, this period of investigation and definition takes many forms and often must be repeated -- but while no two organizations may arrive at the same conclusions, they all try to arrive at them through what will be called a "value system" -- some model for evaluation that is persistent above and beyond the level of ordinary circumstantial change. This sytem will then govern, more or less, the ongoing refinement and validation of priorities and policy -- at least until again too many new occasions prove to be irreconcilable within that system.

When this roadblock occurs, individuals or organizations experience conflicted priorities as indicators of a defect or breakdown of the value system. But in this experience, it can be unclear as to whether the apparent conflict is really due to the system or instead due to a lack of rigor or understanding within its use. For example, rules are often seen as the specific expression of a priority. Sometimes in using them, there may be confusion about whether an undesirable situation -- meaning, one in which prior action has turned things sour or subsequent action will likely do so -- has been forced by "a bad rule", or whether instead a good rule has been inappropriately applied. The conflict stems from uncertainty about the correctness of what was done or of what to do.

This example is notable because the action that makes the situation "undesirable" normally derives its justification from the presumed value system. When the undesirability of the situation makes us debate the system's own correctness, we tend to wonder if the system is unfairly "skewed" one way or the other. Meanwhile, the conflicted priorities that come with the undesirable situation may be a disagreement between two or more parties, but the conflict can also be a disagreement that one party feels within itself.

An important part of a value system's responsibility is to provide a means of distinguishing the character of one action from another. A critical understanding of the importance attached to "value systems" is that they are focused on why things should or should not be done a certain way -- not on what the actual results are. But perhaps most important of all is that a value system's force comes first from its ability to identify and describe things, not from asking it to measure things. That is, a value system is a perspective, not a set of scales.

With that in mind, the discussion below takes a look at how the essential form of a "value system" works to provide critically distinctive identification (not measurement) in a "situation at hand".

To begin with an example, the following picture shows a highly generic framework, intended to more precisely declare the main factors that go into the often fuzzy notion of "values". These factors are what goes into actual decision-making in "real time".

In an ideal situation, this framework would represent an organization's or individual's "mindset" -- one with consistent awareness across all of the framework's factors. That is, there would be an equal and simultaneous grasp of what is "responsible" or not, and what is "right" or not. Armed with that awareness, the character of the action that is possible at any moment could be evaluated as one of a few basic types -- for example as being "virtuous" or being a "gamble".

The framework identifies these basic types by introducing and cross-referencing a major distinction between acts and beliefs -- which respectively translate into the corresponding difference between ethics and morals.

This framework can offer the terms that it uses without the burden of emotional and philosophical histories, because it is not concerned with persuasion but rather with description. All descriptive systems have built-in assumptions, and this framework is not an exception; however the purpose of the framework is completely explicit, with no ulterior motive -- and therefore it can easily be used or ignored according to the practical interest of the observer. It's not that one must compare acts and beliefs, but rather that one usually can.

Two important assumptions in the framework are indicated by the lower left and upper right tags added to the central 4x4 grid. (Arrows are also supplied to signify these assumptions in the diagram.)

The first assumption is that Laws are primarily concerned with enforcing behavior away from transgression and towards virtue. (Moving behavior both higher and towards the right eventually would converge in virtue.)

The second assumption is that Principles are primarily concerned with defining and promoting behaviors that meet acceptable standards. Principles "pull" behavior towards them.

The lower left and upper right regions in this framework are readily comparable. But what is among the most interesting experiences of our society and social value systems is that we are constantly bumping into behaviors that occupy the "middle zone" of sacrifice and gambling.

For example, with sacrifice, a person discovers, perhaps unexpectedly, that they feel an innate (not externally imposed) responsibility to do something that they actually did not otherwise believe was "right". The very occasion itself exposes the difference between what they recognize as acceptable from the standpoint of need, versus from the standpoint of preference. As very dramatic samples, commiting a mercy killing or submitting oneself to bullying in order to protect someone else both fall into this category. As a very mundane sample, giving up properly ("rightfully") earned profit in order to placate a confused customer falls into this category.

In the case of gambling, circumstances are such that the gambler (the actor) often knows a gamble is being taken when others cannot tell. TV shows regularly feature examples of this, where with the best intentions detectives search crime scenes without a warrant, or prosecutors try to use the "fruit of the poisoned tree". Yet sometimes the actor is doing something with self assuredness about rightness, while unaware of how it might be irresponsible. This latter case is accounted for by the framework, but in our discussion the framework is primarily interested in the awareness that motivates the actor. How does the actor decide to do something "irresponsible" in order to do something "right"?

The thinking behind this framework additionally assumes that the actor chooses to gamble -- to take an irresponsible action -- due to his perception of need, while the preference to cause something "desirable" is normally what actually provides the actor with his "justification". Clearly, this is the formula for pragmatism, or the idea that the ends justify the means. The problem lies in whether the "desirable" is also what's "right".

On the other corner, back to sacrifice, actors and their critics often mistakenly judge sacrifice as pragmatism. The judgement error lies in not realizing that sacrifice is not about the ends but instead about the means. Compared to gambling, sacrifice is about not having a choice in how to proceed and doing what is possible instead of doing nothing. This is why "heroes" are not always seen as "the good guys", even though they are usually distinguishable from anyone who is not heroic. Heroism is a way of being that is actually not defined by results. A sad and common example of this is the case of dysfunctional personal relationships wherein one party is routinely heroic but with only the effect of propagating a bad relationship. Likewise, heroic corporate leaders can quickly take the company to ruin. By the way, these examples only reinforce that the actor's overall frame of reference is the dominant one behind the activity. Meanwhile, external observers might readily conclude that the heroism was "noble" but still "not right". (Gambling is generally not seen as being noble.)

The above comments tend to suggest that action is based on needs while beliefs are based on preference -- and that suggestion is intentional even if conceptually experimental. Assuming the suggestion is valid, there is notably still no reason why both need and preference would be unaltered over time by experience and education, or by each other. So it is not a simple opposition of "needs vs. preference" that is unlikely to be valid -- rather, it is the actor's sophistication about the two of them that will make their opposition more or less complex and reconcilable.

We see this continuing dialog between them on a grand scale in the court system, where laws and principles tussle with each other for control of the interpretation to be applied to sacrifices and gambling -- to idiosyncratic heroism and to pragmatism. In light of the framework's clinical terms, the history is saturated with debates over things that seemed ethical but immoral, and things that seemed moral but unethical. Often, the challenge is to "unload" the labels of their psychological baggage, so that the important contrasts and comparisons can be made between the context that declares "right/wrong" (correct/incorrect) and the context that declares "responsible/irresponsible" (proper/improper).

On a corporate scale (i.e., a microsociety), requirements wrestle with policies to control the interpretation (and exploitation) of "opportunities". A company will agree that a lucrative and reasonable proposal should be accepted, but it will disagree that a non-executive should make the deal. The idea and goal of the deal might be right, but the non-executive taking charge of the transaction is irresponsible.

On a personal and private scale, roles wrestle with desires and wind up shaping personalities and relationships. In this discussion, the personal level is really not intended to be directly explored any further, but the recognition of the dynamic is not difficult on a personal level, so the discussion has leveraged this fact to help reinforce support of the framework's idea at other levels of organization or influence.

What clarification does the framework present, finally, about the notion of "values" ? The main clarification is that "values" are an idealized way of pointing at something more specific -- namely, the prescription for the balancing of beliefs and acts. But the framework shows that values come in a range from unambiguously good to unambiguously bad. Naturally we promote the "good", but this doesn't logically eliminate the others nor their actual practice.

The other key clarification is that the influence of values on action is by will of the actor -- meaning that values are not inherently compelling. Instead, the value system has to propose definitions of right and wrong, and propose definitions of responsible and irresponsible -- and the acting party (individual or organization) still has to find reasons to position itself within the range of values generated.

Posted by Malcolm Ryder at 10:22 AM | Comments (0) | TrackBack

April 16, 2006

This Just In

The Washington Post's Mensa Invitational once again asked readers to take any word from the dictionary, alter it by adding, subtracting, or changing of one letter, and supply a new definition.

Here are the 2005 winners:

1. Cashtration (n.): The act of buying a house, which renders the subject financially impotent for an indefinite period.

2. Ignoranus: A person who's both stupid and an asshole.

3. Intaxication: Euphoria at getting a tax refund, which lasts until you realize it was your money to start with.

4. Reintarnation: Coming back to life as a hillbilly.

5. Bozone (n.): The substance surrounding stupid people that stops bright ideas from penetrating. The bozone layer, unfortunately, shows little sign of breaking down in the near future.

6. Foreploy: Any misrepresentation about yourself for the purpose of getting laid.

7. Giraffiti: Vandalism spray-painted very, very high.

8. Sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.

9. Inoculatte: To take coffee intravenously when you are running late.

10. Hipatitis: Terminal coolness.

11. Osteopornosis: A degenerate disease. (This one got extra credit.)

12. Karmageddon: It's like, when everybody is sending off all these really bad vibes, right? And then, like, the Earth explodes and it's like, a serious bummer.

13. Decafalon (n.): The grueling event of getting through the day consuming only things that are good for you.

14. Glibido: All talk and no action.

15. Dopeler effect: The tendency of stupid ideas to seem smarter when they come at you rapidly.

16. Arachnoleptic fit (n.): The frantic dance performed just after you've accidentally walked through a spider web.

17. Beelzebug (n.): Satan in the form of a mosquito, that gets into your bedroom at three in the morning and cannot be cast out.

18. Caterpallor (n.): The color you turn after finding half a worm in the fruit you're eating.

Posted by Malcolm Ryder at 12:13 PM | Comments (0) | TrackBack

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 1:20 PM | Comments (0) | TrackBack

February 20, 2006

A Comprehensive Governance Framework

Why Governance?

Institutional control is a matter not only of doing things "correctly" but doing the proper things correctly. And, we want to control the institution in a way that is itself institutionalized -- just as a mature person would normally control themselves in accordance with appropriate principles of behavior that should be habits of character.

But what is it about an organization that particularly needs governing?

If the organization is a "business", then the motives of a business will drive organizational activity and the point is to steer those activities in principled ways that actually help the business.

The framework below sets the high-level business motives (across the top) as the outlook on key focal-points of the organization's management.

One set of points -- competency, policy, and strategy -- together describe the organization's makeup stretching from what it knows how to do on over to what it should do and finally what it has decided to do. In effect, this describes the current predisposition that the organization brings to its work every day.

The other set of points -- strategic development, operational availability, and transactional consistency -- summarize the organization's major proactive mechanisms for generating "delivery of value" to stakeholders. This is more like the organization's position (not to be confused with positioning).

The balancing act between the organization's predisposition and its position can be seen as a basic behavioral phenomenon demonstrating what the organization knows about how to translate its potential into reality. (Of course, this should include some consideration of whether the current potential is desirable and/or needs changing.)

Given those two axes, the framework looks at the internal structure of the organization for the key contributors that govern relevant business activities -- that is, what it actually winds up doing.

A key observationof the framework is that the organization's capacity to respond to opportunity and demand is hugely shaped by the coherence of its governance. While a lack of governance does not preclude notable capacity, the exact lesson learned in business between 2001 and 2006 is that risk factors in responsiveness can make existing capacity more of a liability (dot.bombs, Enron, etc.) than a benefit. This makes the influence of governance a major force to be leveraged in value management.

At the high level, this is referenced through the framework by its correspondence of the organization's processes, services and portfolios to the goals for progress, production, and achievement.

Naturally, real organizations are not governed only in terms of the intersecting issues presented here. However, governance must attempt to identify the most critical types of decisions to attend to at the various locations and levels of the organizational structure. A primary objective of the framework is to describe the sources and flow of information that can sufficiently account for the effectiveness of the organizational structure.

In that regard, a management ability (BPM) to associate competency and policy exploits certain types of information that can organize appropriate behavior. In like fashion, an ability (BI) to discover and exploit value-laden opportunities for that type of behavior keeps the governance in service to the goals of the business.

The final note for this introductory discussion is that the framework is intentionally abstract so as to allow it to be applied to organizational units of widely differing scale and flavor. There is no reason why a small business unit would have less of a need for governance, and no logical reason why the essential points of governance would be different. Instead, the most likely difference is in the level of awareness that the business unit has about what kind of opportunity governance would bring to the unit if successfully instituted. This is not intended to make any point about the intricacy of particular best practices in governance applied and distinguished between "corporate" or "IT", "profit" or "non-profit", and so forth. Those practices are rightfully derived from the communications needs held by stakeholders in the responsibilities that distinguish their domains from each other. Yet the framework presented above argues for the similarity of management across those domains, and calls out for a certain breadth of awareness that is about explaining why control becomes valuable.

For a related discussion of IT Governance in particular, see the article Surveying IT Governance by clicking here.

For an in-depth discussion of related value-creation issues, click here to see the article, The Business Creation of IT Value, which looks at how business management takes the organizationof IT and develops it to support the business position. While this is not strictly an example of implementing governance in IT, as a followup to the discussion here it illustrates how the problem of "Business-IT alignment" works out in overlapping areas of governance and resource optimization.

Indeed, if we look at coordinating the issues of managing organizational behaviors and resources, we return to the earlier observation that there is a correspondence of the organization's processes, services and portfolios to the (governed) goals for progress, production, and achievement. Seeing "IT" as a corporate resource, the correspondence might be articulated (see illustration here) as an allocation of IT organization responsibilities to those three aspects of the business position.

The thought it leaves us with is the question of how running IT "for" the Business relates to running IT "as" a business, and how business governance and business strategy connects to IT governance and IT strategy. From the framework introduced in this discussion, the indication is that strategy is an area in which governance has an influence -- and that influence is likely to shape Business objectives in ways that IT's influence will have to respect. Thus, IT's own governance will have to establish IT's business-like predisposition and position for compatibility with the way the Business's objectives are meant to be addressed.

Posted by Malcolm Ryder at 1:27 PM | Comments (0) | TrackBack

Alignment, Coordination, Integration and Lifecycle

Business presumes that relevant achievements on a sustained basis will bring success.

Relevance is often a matter of timing as well as being very sensitive to the periods and duration of elapsed time. Without changing anything about itself, an organization's achievements may change in relevance simply because of who is paying attention from outside of the organization.

Sustainability is different. Functional organizations can be distinguished from dysfunctional ones in ways that do not begin with measuring their outcomes. Functional organizations are not always successful performers, but good performance itself is not a guarantee that the organization has avoided being dysfunctional.

Performance is part of relevance; targets or goals are provided as the perspective from which achievement is interpreted, so a suitable level of ability to achieve is as wide ranging as is the "stretch" of the targets from easy to hard. The big issue is about who sets the targets. As we say, "who's calling the shots"...

But as we know, just setting targets doesn't cause success. Our attention invariably dwells on what mechanisms we need for reaching the target.

Discussions about alignment therefore have two flavors.
- One considers issues from a design perspective: should a certain arrangement of elements and components logically suffice for the desired purpose?
- The other considers execution: should the typical activity of the mechanism likely meet the requirements

The second consideration, execution, itself has two flavors. One considers whether the mechanism is "keeping the target in its sights"; the other considers whether the mechanism, composed of many parts, is structurally sound enough in the real-time of effort (that is, actually constructed well enough) to get the job done. Today, these are both usually referred to as Alignment.

Although it is strangely rare these days to hear it called otherwise, both flavors of "alignment" are simply the issue of co-operation.

In the execution sense, which is essentially about quality, the combination of technique and management coordinates the parts for a unified, systematic cooperation. By coordination, it's meant that all parts conform their availability and output to the pertinent requirements of a common objective. No two parts need to be similar, but all must be explicitly assigned to the operation that meets the objective. Coordination is the most actively managed form of cooperation, and it is the form that is easiest to change.

The efficiency and security of that coordination is largely dependent on what level of readiness the coordinator finds the elements or components to have for the sake of their being combined. Combination unifies separate parts, but again for the sake of real-time confidence in the effort we normally see integration employed. Integration prefabricates the readiness of the parts, establishing their suitable availability independently of the actual frequency of demand or use.

Integration makes a big assumption, however, which is that the condition of each of the parts stays within a range of tolerances that allow the integration to persist. Managing the condition of the parts means attending to their lifecycles of arrival, interaction, ageing, and replacement or removal. Essentially, this lifecycle management is strategic to the maintenance of integrations that optimize coordination -- resulting in alignment.

But what about ad hoc coordination that does not rely on integration?

Lifecycle management prepares for ad hoc coordination by managing changes within a part's lifecycle according to predictions about future coordinations and the utilization that those predictions suggest. For each predicted use of the part, its degree of usability is certifiable at each of its lifecycle stages.

An architecture typically contains a documentation of the predictions and can produce part specifications that identify the quality tolerances for the anticipated use.

Lifecycle Management's benefit flows through architecture and integrations into real-time coordination.

Posted by Malcolm Ryder at 5:00 AM | Comments (0) | TrackBack

February 3, 2006

Decide, Design, Deploy -- Then Assess

More than any other role in the enterprise, managers are the focal point for accountability of execution results. On the one hand, this means that the organization's overall visibility of its progress is created by managers. On the other hand, it means that poor visibility is attributable to the way managers view things. It therefore becomes crucial for management and the organization's other stakeholders to have a given view that they both understand the same way.

Evaluations and assessments strive to create that shared view. But while most organizations mandate evaluations, many use them without any strategic impact on the direction of change or the continuity of improvement. Confusion is easy when the effort is to describe comprehensive responsibility for consequences. Managers sit at the center of this disappointment, but they need not. The solution is to be sure that all parties know beforehand what it is that the evaluation can really explain. For managers, evaluations should explain not just a nebulous idea of "results", but a specific idea -- progress. And for all parties, it is necessary to understand that evaluations and assesments are not the same; without this understanding it is far more likely that one or both of them will be ineffective or mis-used. Too much effort will be spent boiling an ocean or too much spent looking in the wrong place for answers.

I.

Three kinds of issues dominate visibility of progress.

One: "performance" must have the same definition for everyone. The generic definition would be "the degree of achievement towards a set goal, as generated by execution under demand." This is the context within which "progress" makes sense. The equation must be that the results of execution must amount to achievement, not just difference.

Two: a consistent understanding must be established of what is meant by "results". Here, the relationship between execution goals and impact goals is the subject. That is, since execution adds, moves, and/or changes things, one result is about whether those differences work out just as prescribed; but another result is that the influence they have works out as is needed. Progress is really the direct measure of whether the prescribed differences were obtained. The equation is that change equals requirements.

Three: the ability must be developed and used to accurately identify both what is "necessary" and what is "sufficient" -- and distinguish them! This subject is often complicated by confusion over where it is in the realm of execution that "needs" ought to hold top sway. This is not so much a debate about whether satisfying needs should be the driving purpose, but instead about who gets to declare the needs to which all production should align.

For those three interlocking reasons, the idea of evaluating performance is inherently a complex one. All organizations do a number of things that they call "performance evaluation" -- but the huge variety in how one outfit does them versus another is exactly why there is an industry for "best-practice" advice on the matter instead of only for precision techniques.

II.

Given the above, any organization could likely find significant differences in its view of achievement, progress and production -- once it knew to look for differences. This is one practice-level aspect of evaluations.

That said, two different organizations using the same practices should be able to understand things the same way, albeit this makes sense only to the extent that they both ought to -- and a given practice still allows wide differences in technique. So why bother with evaluating things on the practice level?

Answer: a "practice" is not mainly about "the right way to do something". Instead, it is really about associating ways of doing things with value. In this case, the point is to get value from the evaluation effort, instead of just going through the motions of supervisory responsibility.

Typically, organizations have a lot more familiarity and experience with the technical aspects of evaluation -- while not necessarily knowing where their technique fits into general best practice. This might signal a situation where there is ambiguity about whether the evaluation is actually solving the right problem (or any problem at all.) What issue is the examination really expected to resolve, and why?

An important starting point in clearing that up is to apply not only the above distinctions about "results" but also -- and even more importantly -- the following ones that reflect the difference between the beneficiary's stakes and the provider's stakes.

III.

What do organizations want "good performance" to mean? Essentially, it should mean that the organization's target stakeholder agrees that the organization's activity has created value for the stakeholder. The stakeholder's sense of received value can be quite varied -- ranging from relief to opportunity, and from intangibles to tangibles. From the provider's viewpoint, this extrinsic value is a goal of the provider's intrinsic performance.

Unfortunately, it is very common for external measures of an organization to be called "performance measures" -- but most often what is really being measured there is the extrinsic value of the organization's effort. Properly recognized intrinsic performance, which is an internal goal of the organization, is essentially a characteristic that the organization wants to acquire.

To be specific, the desired characteristic is the ability to produce an extrinsically valuable achievement. To get that characteristic, the organization has to get internal progress from its execution.

That gets us back to the issue of accountability and progress. The general question that performance evaluations try to answer is, "Did the way we do things get us the results we wanted?" If the answer is yes, management should be able to take the credit. But if the answer is no, then management could likewise take the blame.

In the credit and blame game, it's easy to react to a broad range of direct and indirect consequences, and lose focus on what should be specifically discussed about management -- namely, progress. Evaluations that seek to show comprehensive "responsibility for consequences" are too often boiling an ocean or looking too much in the wrong places for answers. Avoiding those problems is easier when we stay focused on accountability for progress.

IV.

How do we describe "the way we do things" and begin to account for progress? Most management activity can account for eventual progress in the way the management activity affected things at three different phases:
- decisions;
- designs; and,
- deployment.

In "making" progress, management has a short list of essentials to worry about -- all fitting under the umbrella concern of "can we do well what we are required to do?" Requirements generally come from:
- the dynamics of prevailing circumstances that are creating opportunity or risk,
- from formal restraints or orders, and
- from literal limitations of resources.

Correspondingly, the essential elements of execution that are to be managed are:
- Awareness (appropriateness of choice of response)
- Competency (effectiveness of response versus demand)
- Discipline (behavior or application consistency versus rules)
- Capability (the inherent functionality of a resource)

Managers "make" progress by cultivating and coordinating those elements -- through decisions, designs and deployments -- in ways that are specifically compatible with the terms on which activity is approved, by the organization, for responding to designated circumstances. As a final concern of management, the approval of the actual activity may come before the action or afterwards. While the terms of approval may be constant, the action may be prescribed beforehand, or justified afterwards -- reflecting the existence of some range for management discretion. Use of that discretion may become a particular point of evaluation -- one that questions the skill of the manager or the logic of the terms of approval, or both.

Taking progress as the subject, an evaluation is not really a "performance" evaluation except in terms of the performance of the manager who is responsible because of his or her presumed capability to manage.

Instead, regarding the measured execution results, the evaluation is a progress evaluation and what that evaluation is trying to explain is how the actual execution relates to the actual differences made towards meeting requirements.

V.

One of the profound realizations from that clarification is that execution always points in the direction of requirements. Wherever the requirements go, execution is responsible for meeting them. In real life, this means that the "fallout" of proper execution can easily feature enormous amounts of change, cost and discontinuity, because it was unavoidable as a consequence of the requirements. Therefore, if an evaluation of execution seeks to judge it by how much it was able to rein in change, cost, and discontinuity, then the evaluation itself is not measuring progress -- thus it is not measuring the intrinsic worth (the logical benefit) of execution. In such a case it is easy to see that execution might get modified as a reaction to factors that have not actually been linked to enabling the execution to better contribute to intrinsic performance. Anyone preparing or reviewing a business case will wrestle with this threat.

Clearly, however, factors such as change, cost and discontinuity are necessary to factor into the big picture -- the one shared by multiple stakeholders. After all, if execution is not sustainable, or if the side-effects of progress are corrosive to the organization's stability, then fundamental rethinking should be taking place. The difference between an evaluation and an assessment lies exactly here -- an assessment explains how the subject's results relate to the larger sphere of enterprise influence.

An evaluation can explain whether a job was really well done. But an assessment can explain what an evaluation cannot: namely, whether the job was the best "right" thing to do.

Posted by Malcolm Ryder at 5:35 AM | Comments (0) | TrackBack

January 14, 2006

"Effectiveness" -- the essence of Operational Performance

As with so many "enterprise" issues, whether you're an executive or a manager, sorting out the messiness of your performance management options probably means first checking to see if you're sure they are solving the right problem.

Executives and Managers don't see things the same way. But they do look for the same thing: "high performance".

Sadly, too much of the time they don't know when they're seeing the same thing until it's after-the-fact, so it's difficult to coordinate their decisions along the way.

This obscurity of view can be resolved, but today the solutions themselves are often confused about what parts of the problem to solve -- because the stakeholders aren't sure themselves.

At the heart of the uncertainty is a lack of understanding, or agreement, about where one stakeholder's authority of (which establishes a scope of influence) should exploit another stakeholder's responsibility (a degree of accountability). "I have a right to protect my accountability, no matter what you order!"

Research departments of consulting firms discuss this difficult situation, such as in Booz Allen Hamilton's take regarding a need for determining "decision rights" -- but there is also a more basic cultural aspect to consider: what everyone refers to as "being on the same page". This unanimity is not just about naming a common goal, but instead about whether everyone understands, to some reliable level of generality, the logic of how to make things work. In action, the key complication here is the variety of practical and political predispositions found within the organization, despite decision-making rules. Predispositions generate expectations that give "reality" its appearance and thus present what looks like moments needing decisions. Different realities offer different moments...

A pretty good way to start resolving the confusion is therefore with a globally coherent picture of what the decisions ought to be made about.

I.

The underlying logic of what gets called "high performance" aims for advantageous on-demand results, which calls for alignment of three key elements:
- clarity of intent
- realtime responsiveness
- agile navigation of capacity

Linking those three things allows for "executing" (as it is usually called) with the right thing at the right time for the right reason. But what must also happen is to have all three things simultaneously.

Clarity about "reasons" is the most important challenge. Setting aside the specifics of any given business, two major classes of reasons usually steer the management of the execution.

- One class focuses on the worth of the designated objective. (This is about the kind of advantage that the achieved objective offers. )

- The other focuses on the value of the execution. (This is about the importance of the difference made by the execution.)

Often the difference between this pair is referred to as the "gap" between strategy and execution -- implying a causal but dysfunctional relationship that somehow has escaped management's influence. That clearly oversimplifies the matter, except by assuming that management has to be "fixed", which is not a simple matter. Popular cited examples of management's problems include this: so many definitions of strategy are presented that strategy becomes a moving target; meanwhile a culture of short-term gains increases skepticism about whether strategy is pragmatically important anyway.

Yet stepping away from that suspicion begins with a related observation: the direction [verb] provided to execution by management is precisely where the accountability for "performance" lies. Most decisions about execution are made under the pressure of accountability.

When we're worrying about management accountability, we'll call our real subject something other than "performance".

II.

In practice, the highest-level concerns of accountability are two expectations.
- One is that the designated objective should be logically critical to creating the conditions necessary for business functions to matter.
- The other is that execution should be logically critical to creating states at which the objective is achieved.

These "functional-conditions" and "objective-states" are thresholds. The chemistry of what occurs when the thresholds have finally been reached or crossed is described in the business model (of conditions) and the business plan (of objectives).

Given that, the essential significance of execution seen is its role as an enabler (of hitting the thresholds).

However, both executives and managers persistently but incorrectly treat execution as a cause. Correctly seen, execution dwells on necessity but it is production that dwells on the ability that gets the job done.

Nearly all parties acknowledge the reliance on programmed production. Production is a designed activity, the place for which is set as follows:
- execution, meaning the decision to act and the followup, should itself be "caused by" explicit intent to reach thresholds; and...
- the activity-design of the followup focuses exclusively on realizing the intent.

This clarification of the notion of "execution" versus "production" is complemented by similarly distinguishing the idea of operation (the chemistry beyond the threshold). All together, they describe the functional depths of the organization:

Operation refers to an intentional activity that distinguishes the purpose of the organization in a situation. Here, the key concerns are quality issues, about targeted "impacts and reach".

Execution refers to the explicit and controlled pursuit of meeting requirements for successful operations. Here the key quality issues are about "options and decisions".

Production refers to the mechanism used to realize and sustain execution from current circumstances. Here the key quality issues are about "cause and effect".

Executives and Managers must have a common (shared) way to see and understand the alignment of these three layers of organizational functionality. The key is to grasp the systemic nature of production's influence on execution, and likewise execution's on operations. Optimizing this systemic influence is the management goal called effectiveness.

When executives and managers agree about "effectiveness":
- They more rationally exercise the "throttles" that change the levels of throughput and output that they interpret as "performance".
- Their efforts, even independently of each other, are then truly more akin to driving, in which they both use the same logic of inputs for moving the vehicle in the right direction at the right speed at the right time. The specific point of any moment's maneuver may be quite different from another moment's, but the overall navigation weds all the real-time changes to the purpose of crossing the terrain.
- Most of all, the participants' recognition of when it is important to change an input is based on the same (shared) ideas about alignment.

The support of this alignment is two-fold: it must span attention to issues that are peculiar to each element, and to issues that determine the success of their linkage.

III.

In understanding and maintaining effectiveness, correctly addressing its specific elements involves using the right mindsets for staging and conducting their evaluations.

These mindsets -- which show up in their semantics -- prescribe the basic types of awareness needed to communicate whether a given element needs to be changed.
- Measurement uses the most granular set of standards, to specify the difference between fixed requirements and current reality. (Correct vs. Incorrect)
- Rating uses a less granular scale of difference to compare a current position against a range of possible positions. (Better vs. Worse)
- Confirmation uses a definition to test for the actual existence of something versus a plan (Yes vs. No)

But the full description of the mindsets includes sensitivity of another kind: an organizational effort meets its purpose with competency built on capabilities. This awareness overlays the layers of functionality from production up to operation.

The table below illustrates this overlay. For example, in representing the high-level top-down view from the perspective of purposein an organization's effort :
- Operations are best "measured", while...
- Execution is "rated" and ...
- Production is "confirmed"

This describes the immediate "surface" visibility needed for an evaluation in terms of purpose, and it de-emphasizes other background levels of elemental visibility unless the immediate visibility is unclear. This means that to understand efforts against purpose, "measurement" of execution is not automatically necessary, but we want it to be possible if execution's ratings are unclear.

IV.

Further support of alignment includes the design and maintenance of linkage mechanisms for the layers of functionality. Both static (preconfigured) and dynamic (ad hoc) linkage must be arranged.

Executives and Managers often try to do this symbolically, by defining and then "rolling up" or "cascading" measurements across the functional depths of the organizational effort. This typically involves translations from one depth to the other, and it has been historically maddening and insecure. The chosen problem has usually been to determine what the measurements at one depth mean "at another depth".

Sometimes in the hoped-for translation of measures, the semantics involved are "codified" by process designs that link (i.e., integrate) events at one depth to events at another. The hope is that the process design is valid, so that measuring just the integrity of the active process can provide a suitable proxy for a much larger set of discrete observations. This approach of "automating alignment" is not unimportant, but it confuses the "systematic" for the "systemic" -- that is, it risks that executives and managers will mistake the description of the process for a description of the current conditions. The problem with that, as has been historically borne out, is that improving process may not cause conditions to improve, even if it allows the conditions to improve -- and processes continuously proliferate their complexity and variety. (This is why process management is not the same as performance management but instead is only an aspect of it. Process, although likely necessary, cannot be a sufficient translator.)

Instead of all that, as the table above suggests, measurements at one depth establish facts that are likely important to the next depth only as they relate through the virtue of commitments made (i.e., assignments) and through the likelihood of positions established (ratings). Thus, with much more generic linkage involved, as we move up from production to operations we see the subject of "measurement" moving from capabilities to purposes, telling just a part of the story.

For example: let's say that we're driving, and as an execution matter we've decided to "go left".
- We produce this turn by assigning (committing) a selected turning radius and selected velocity. We may find out only later, through measurement, whether those specific selections should have been allowed. The results of our production effort leave us more or less satisfactorily turned to the left; that is, we retrospectively evaluate the production with a rating.
- But how useful is the turn that we produced? Is the precise "leftwardness" of our resulting achieved position suitable for the need at hand? Does it matter which lane we have gone into, and how far we are from other vehicles, at our post-turn speed? Did we hit anything during the turn? Are we about to, afterwards? All of these issues carry potential requirements that we address throughmeasures reflecting our competency with the turn (i.e., our execution).
- Our demonstrated production capability will strongly suggest whether in the future we should consider a decision to turn left to be a "good" decision -- but meanwhile a recurring need to turn left may insist on efforts to improve our production capability for the future.

V.

The bigger message from this situation is that "measurement" per se is an incomplete understanding of conditions, which needs to be supplemented by additional means of understanding. We cannot manage what we don't understand.

When we look at achievements against targets, the matter is about "performance". But sustained or recurring achievement is the whole point of management, and awareness doesn't cause that.

So, more to the point, when we have a supervisory understanding of functionality against goals, we work on managing their alignment as a matter of managing "effectiveness".

The next table below again elaborates the "effectiveness mindsets" -- except in more colloquial or "ordinary" language. This set of semantics illustrates how terms of alignment range in a general progression of influence from "optional" to "critical" as we go from (bottom left) production capability to (top right) operational purpose. For each intersection of functional depth or change level in the table, the provided term points at the notion of "in what sense does this matter?"... For example, an assessment of Capability is important, but it is important in different ways depending on what functional depth is being considered. In this version of the table, each term represents a distinctive expectation that executives and managers can always initially share as the default question of interest or comparison about each issue.

Overall, a baseline is established for discussing the "role" of each functional depth (row) or change level (column) in terms of effectiveness. It's not difficult to envision a series of conversations that explore progress and effectiveness, consistently using the language presented here, in mixed audiences, without confusion about how things are expected to influence each other.

VI.

The semantic resolution doesn't stop there, but since management tends to institutionalize its solutions, our various expectations of the management effort should be conceptually distinguished -- in a general way that clearly indicates what their evaluations will really care about and how they relate.

The conversation with our mixed audience should be able to cover the two broad reasons that usually steer the management of execution. Most organizations bring their concerns about achievement to the table in two flavors: financial and operational. If we cross-reference those against the worth of designated objectives and the value of execution, then we get guidance as in the table below.

Financial and operational concerns represent the two main ways that the organization keeps track of why any other party would want to have a relationship with the organization. Generally, the assets and trust that an organization has to offer are its main attractors. Management looks for, and distinguishes, related outcomes from its activity as follows:

Posted by Malcolm Ryder at 7:04 AM | Comments (0)

December 13, 2005

The Value of Being In the Know

Imagine trying to create value without being knowledgeable. Not good. But how do we know what value the knowledge creates?

I.

FIrst let's go to a working definition of "value", to tell us how to consistently recognize when value, instead of something else, has been created.

- value: the significant difference that is made by a distinction.

This generic definition is important because it is portable and unchanging across different kinds of situations. However...

In any particular situation, value might be created in a variety of ways. Its two key parts -- significance, and distinction -- can exist independently of, and prior to, each other. This allows some complexity:

- a single distinction can be significant in multiple ways, but not all of those ways are necessarily relevant to a given stakeholder. And...

- there can be more than one way to get to the given significant difference; not all ways are necessarily tolerable or practical at a given time and place.

Thus, the two parts can have a many-to-many relationship with each other, which means their combinations can vary and thus generate value in many diferent ways.

We'll have to sort through that variety when assessments roll around. We should objectively identify different kinds of values. Then, based on relevance and practicality, we can determine what kind of value might be most within our grasp, but finally we also have to decide how much that kind of value means to us and why. This separation of "value" from "worth" is the precision awareness provided by an assessment. The assessment helps us think through potential values in terms of worth, and ultimately we'll commit to the most worthy values.

As an example of concern about "what value is meaningful", companies considering taking on knowledge management (KM) are commonly concerned about the economic impact of KM's value. If KM is valuable, they want to know how and why, with regard to that specific impact.

In figuring it out, we have to start with "how" the value of knowledge can be recognized.

II.

One approach to identifying what value knowledge creates is to first state the desired type of value and then apply knowledge in situations that logically should drive that type of value creation. If applying knowledge produces a measurable change towards the desired value then we attribute that value to that knowledge. An example situation would be "problem-solving". Here, we know that we want a solution and that getting to a solution is a multi-faceted issue. Measuring the effects of applying knowledge might yield findings such as:
- solution obtained much sooner than otherwise has been the case
- solution obtained with greater efficiency of required resource consumption
- solution obtained where previously there hadn't been one obtainable

In fact, "faster, cheaper, and prettier" are very reasonable terms by which to measure the effects of applying knowledge. They typify agreed notions of value (i.e., significant difference) that people already know what to do with.

This is an approach that is compatible with "accounting" -- at least in the sense that it describes tangible results correlated with the level of effort invested and consumed in the situation.

An approach wholly different from that, however, is from the other direction -- where applying knowledge appears to predictably, and even reliably, cause changes, but the significance of the changes is undetermined. Here, the problem lies in not understanding what to (literally) "make of the change"...

When applying knowledge has effects of indeterminate usefulness, the accounting perspective does not help to identify and manage a recognizable value. Accordingly, we need another view -- one that perhaps introduces previously unseen useful effects to accounting, but at minimum discovers the usefulness of previously unobserved effects.

III.

In the latter case above of knowledge-driven changes, management has a special problem: we need to determine whether applied knowledge has re-organized conditions in a way that provides a different set of opportunities and risks than what had previously been established -- not just a different level of preconceived value. The more important the new opportunities and risks are, the more valuable we can say was the knowledge involved. But as with any change management, we need to determine whether the knowledge-driven changes are the "right" ones -- and whether the value is a kind that we really want.

One practical way to recognize this issue of reorganization is through the idea of "technique". Technique organizes the way things are used in action. In practice, acquiring good technique is the same issue as being "trained" (reorganized) to a point of better functional capability. The two most important aspects of technique, making it a target for adoption and improvement, are that (1) it provides an operational advantage against stress, and (2) the means of that provision are sustainable. These are compelling differences to attribute as value.

Technique organizes the way things are used in action -- but so does a "process". So what's the distinction there?

Technique is to "process" as Policy is to "approvals". Approvals define the selection of permissions, but policy defines the logic of permissions according to prevailing conditions. Likewise, where process defines the selection of connecting actions, technique defines the logic of actions according to prevailing conditions. A process that amounts to bad technique is no more tolerable than approvals that amount to bad policy.

Most oganizations today can think about technique by thinking about "best practices", contrasting that against what might be considered the "best procedures" world of processes and rules.

But if we take the example of best practices and investigate it for its contribution to value, much of what immediately comes to mind is the view from the opposite direction -- that is, practices which are not "best" are inhibitors or liabilities that we want to remove. This helps to focus our attention more on the aspect of protecting "opportunity" and on how opportunity is maximized or minimized under the pressure of demand.

Now, we see that Opportunity can be set alongside Operation as a second critical perspective in assessment. Where assessment of operations deals with progress, assessment of opportunity deals with potential.

- Potential represents the degree of protection provided for an opportunity to obtain the desired impact.
- Progress represents the degree of achievement in realizing the potential.

Accounting typically examines Operations for progress; but value assessment also needs a mechanism that examines Opportunity for potential.

IV.

Before beginning that opportunity examination, we must be careful to furthermore separate "opportunity" from "objective"...

In practice, objectives are usually identified and promoted specifically to represent the perceived or desired endpoints of paths -- paths seen as "opportunities" that describe the potential for reaching a goal. The paths have been conceived for the purpose of meeting the objectives.

Managing operations focuses on moving things along those paths; but covering the known paths is more about performance than it is about value. Meanwhile, accounting is heavily performance-oriented. It wants to discover and explain "progress." It expects knowledge to stage and promote progress by changing operations to realize the potential.

In contrast, managing opportunity means path-finding and path-determination, which comes from strategy. Strategy is heavily value-oriented. It is mainly about finding and validating the paths where potential is first created. It expects knowledge to stage and promote potential by changing opportunities to realize the desired impacts.

Thus, in the defined opportunity produced by the strategy, we see the definition itself as the "significant difference" and therefore attach value to it (separately from any pursuit). Then, we have to weigh the opportunity's significance to the objective, independently of weighing the importance of the objective itself.

For example, we may see the strategy as the map to success. Following the map will still be a critical constraint on achieving the goal, but the requirements for following it (i.e., progress) should not be mistaken as the criteria for weighing the importance of the strategy's value (i.e., potential).
- Instead, the strategic opportunity must be relevant and viable, and considered against alternatives.
- Meanwhile, regardless of the importance of the objective itself, if the opportunity is critical to the objective then by definition the opportunity has great weight.

V.

The map that strategy creates is a highly valuable asset even before we start to actually follow it. We want knowledge to do two things: to make us better map-makers; and, to help us make better maps.

Those differences indicate yet another key to assessing the value of knowledge -- namely, to distinguish "intellectual assets" from intellectual behavior. Knowledge changes both things, so they each are dimensions of knowledge influence, affecting both operaions and opportunity. Additionally, they affect each other.

Managing assets and managing behavior are not the same activity, but with valuable assets such as distinctive ideas (like strategy or procedure), we naturally also want behavior that improves and leverages their value.

For example, we want high performance in compliance to a valuable procedure -- which makes that behavior itself valuable. But that sense of behavior should be understood as "skill".

Intellectual behaviors such as analysis, decision-making, and invention are also coveted skills -- but they make their distinction, and ultimately their value, in their ability to create and modify important circumstances and intellectual assets.

If we say that we can apply intellectual behaviors and intellectual assets to a situation, have we covered the bases for saying that we have applied "knowledge"? Not quite.

Under the pressures of demand, an organization's assets primarily represent its capacity while its behaviors represent its competency. But in our overview of knowledge, a third and final dimension, joining intellectual assets and intellectual behaviors, is what we might call "intellectual predispositions" -- which brings preferences to join capacity and competency.

Now, with those three dimensions of knowledge influence, we can begin to catalog the types of differences that we want assets, behaviors and predispositions to make, and in that way list key terms of assessment. We can cover opportunity comprehensively, and we can also "backfill" issues frequently ignored about operations.

Amongst our catalog of differences, we must also have clarity and confidence about what final impacts we really need, and then about whether the contributions of the assets and behaviors (capacity and competency) are actually supporting both the progress and potential towards the target impact.

If our key objective is maximum positive economic impact, the challenge will be to distinguish how knowledge drives economically significant progress, and how it drives economically significant potentials, related to the desired ultimate impact.

We'll especially want to understand how knowledge helps our progress, potential and desired impact to align with each other. Or else!

The fact is, we could do a bang-up job of executing on differences that don't really matter amongst our goals and priorities, yet still affects our economies -- for example, perfecting compliance to standards that don't solve our problems.

And highly potent value can be created that doesn't have much economic impact -- for example, a well-executed product perfect for only a very tiny market.

What will emerge, though, is that the interrelationship of these issues is not strictly linear but instead is interwoven -- more of a network of influences than of a chain. Managing assets, managing behaviors and managing predispositions each have their own way of affecting progress, potential and desired impacts. But the way that knowledge affects one dimension also affects the others, which changes their alignment. In that way, managing knowledge value is a lot like managing a network.

VI.

To envision the scope of interrelationships in the alignment, consider the following.

This matrix is one way to describe how knowledge influences alignment. Here we see the representations of numerous familiar business instruments that are directly related to knowledge and that in turn are distributed to shape operations, opportunity and objectives. Our familiarity with the items in this view also lets us see more readily that changes in one place can alter the support, status or direction of another place in the picture.

Managing knowledge will include managing the making, certification and purposeful utilization of it at each point in the matrix. But through our familiarity with these instruments, we already recognize that the point-to-point connections are vital to the health of the business effort. Given that, managing knowledge value comes in when we know what difference we want the knowledge to make at each point, and how those differences relate to each other.

With things put that way, it's easy to say that at all points we just want knowledge to make things "better".

But better should mean that they become more reflective of the target impact while improving the way they interrelate. For example, a faster, cheaper or prettier way to do something is better if it keeps or increases the level of support it offers to other factors that depend on it. Otherwise, diminished support can easily make the other factors riskier and likely more costly. The sensitivity to this is typical of taking a portfolio management approach rather than an accounting approach. What we're working with is the "knowledge portfolio"...

VII.
From here we can begin to sum up how knowledge is valuable.

Our matrix has a left-to-right connection of three perspectives: operations, opportunity and objectives. As management modes, what forwards knowledge influences from operations through to objectives and beyond is technique, strategy and purpose. We readily recognize this in certain management artifacts:

- Earlier, Best Practices (through technique) was an example in which the influence of knowledge on operations was directed in support of opportunity.

- In like manner, Planning represents strategy's bringing knowledge influence on opportunity, with which we would likely support objectives.

- To that, we can add that an organization's Positioning represents the knowledge influence that purpose has on objectives, which we use for supporting stakeholders.

Together, the three things illustrate the organization's competency, capacity and preferences systemically establishing themselves -- three characteristics that we already know are criteria in economic justifications. These characteristics are also recognizable thematically as in the examples within the picture below:

Meanwhile, vertical linkage in the matrix connects the three knowledge dimensions. Looking back at the cycle of leveraging knowledge value under demand, we saw a picture that corresponds to these dimensional links: predispositions should direct appropriate behaviors; and in turn, behaviors should produce relevant assets that communicate and transport capacity from one time and place to another in the organization's experience.

In that picture:
- intent is a source of conditions;
- form is a source of content; and
- function is a source of capability.

Knowledge affects the measurable conditions, content and capability of the organization -- characteristics that we already know are monitored for the economic impact of their use. Overall, the cycle addresses the question, "of the things that we want to do, how do we get them done?" This explains why improvement initiatives focus on investment, refinement, and redeployment in those three areas. While those initiatives typically look to business "intelligence" as a primary means of gauging the importance and progress of the efforts, we saw that "knowledge" is more instrumental to shaping the actual changes that the efforts make. In other words, that is why knowledge is valuable.

VIII.

One of the key challenges to working on improving the value of knowledge is to assure visibility of why certain kinds of knowledge is appropriate in given situations. In general this is thought about as "expertise", but in an important way that misses the point. Along with information overload, an organization also has a degree of complexity that often obscures the reasons why knowledge is available or not in given circumstances. Automation certainly tries to address this problem by minimizing it risks. But behind that automation should be a visible logic of knowledge management that corresponds with the assessment matrix and alignment cycle we have now seen.

As a closing explanation, but one that is a work in progress, the following picture identifies that knowledge is more likely manageable when its form and function aspects are more visible. This visibility helps to begin the process of optimizing the current knowledge deployments into a configuration that, as outlined by the discussion above, will more systematically support programs for increasing their value.

Posted by Malcolm Ryder at 12:18 PM | Comments (0) | TrackBack

November 28, 2005

ITIL, Optimization, and the Performance Management Approach

Business derives value from the utilization of IT in the same way that it derives value from the use of money or people: the business applies the asset to enabling those events that have a designed ability to impact business conditions.

Assets may be applied directly or indirectly to the target event.
- Directly, the asset is deliberately "consumed" by the event itself. This involves using the asset as a material element of the event. The event may employ, transform or exchange the asset, in order to produce another output.
- Indirectly, the asset may be used to deliberately affect circumstances surrounding the target event. By "circumstances", we mean conditions surrounding the moment or location of an event.

Consumption and circumstances often develop independently, and they often coincide without much resistance on the way. But management's intent is to replace coincidence with planning, and move consumption and circumstances to co-operation .

If cooperation didn't need to be planned, we wouldn't need management. For this concern, the proper focal point is not the assets, but the events in which they are involved.

I.

In producing cooperation, one of management's primary responsibilities is to establish compatibility between the circumstances and the consumption. With assets at stake on both sides, competition for the supply and deployment of assets is an issue. Since no event goes unfollowed by others of equal importance, organizations need to know what will happen to their capacity as an aftereffect of the cooperation.

In effect, whatever requires the cooperation -- namely, the target event -- is seen as something that must either conserve or replenish assets, so that business will be continuous and ongoing instead of episodic or temporary.

Yet placing that restraint on the target event must not prevent the event from bringing the needed impact on business conditions.

This reflects a broader principle: environmental conditions are part of the "infrastructure" for business functions, and meanwhile, consumption (business function) has prerequisites (specifications). Circumstances (environmental conditions) have effects (states) that must productively correspond to those prerequisites.

This "productive correspondence" of current specifications and current states is exactly the compatibility being sought from management.

Consequently, it is evident that the key issue is not asset management; rather, it is event management driven by business requirements -- which is the ordinary description of business capability.

II.

The history of the business capability is largely recorded in the history of events that occurred under the pressure of demand. As pictured above, an "event" is the overall result of interacting capacities and requirements. Thus, we easily expect an event to vary widely as the number and strength of influences on its separate elements varies. The primary threat to manageability of events is the inability to control that variation and maintain a useful synchronization of the elements.

In periods where management efforts are successful, events are the normal focal point of attention to whether the business is getting what it desires from IT. The benefits of events are the most ordinary measure of success. When event benefits fall short of desires, then the typical approach is to look for what disabled the event from being beneficial. This disability will usually be found in either of two areas: one, the context of the event (as in time and place); and two, the makeup (causes) of the event.

In accordance with the "event model" discussed so far, we can especially appreciate thatprocesses are used to place controls on the makeup of an event, so that the event's final character is appropriate to desires.

Ideally, a process predictably selects and coordinates the event's elements, with as much aggressiveness and detail as necessary to assure the needed character of the event. By increasing the process's ability to reliably find and control necessary event elements, management can mature the process to a point where the timing and location of a certain type of event also becomes more and more predictable -- which is hugely valuable to selecting and organizing responses to demand.

Process-modeling (now evident as a form of "event-planning") usually seems highly convenient to management. Mmanagement readily adopts a "process" approach to designing and cultivating desirable events. And more maturity in the approach promises the business greater opportunity to create (or find) and leverage advantageous business conditions, strengthening the approach's justification.

But acquiring strength and quality of maturity cannot be taken for granted. This means, in turn, that the assumed benefits of processes are always to some degree uncertain to occur.

“Complexity is intrinsically predictable,” Wharton management professor Saikat Chaudhuri notes, with a very major caveat. “If one places sufficient resources and project management strategies in the right places, it’s possible to manage the complexity. You can learn how to do it. But uncertainty, by its very nature, requires constant adjustment. This type of flexibility is tough to achieve, especially in the middle of integration activity.”

Challenges to process maturity are a part of the uncertainty, affecting the makeup of anticipated events. Another big part is shifts in demand, which reflect changes in the context of events. This indicates a need for an alternative to process management to serve as the lynchpin of business value.

III.

In the discussion that is most interesting to business people, the working definitions of "performance" pertain to the generation of value versus demand. Business runs on competitively satisfying external party demands -- and it is constantly translating those external demands into demand on its internal constituent organization. In that light, maturing the management processes for events-- which links an organization and its environment -- is a critical aspect of managing improvement in performance.

Yet with management process maturity in place, the unpredictability of demand remains a highly significant type of uncertainty threatening management results. Because uncertainty is a fact of life; organizations must simply take a useful position against it.

Thus, complementing event management, the most critical aspect of deliberate performance improvement will be demand management.

Consider "benefit" in a general sense, as a constructive impact of an event. The effectiveness of management is measured by the benefits delivered, and events deliver the benefits; so we continuously scrutinize how we manage the enablement of the necessary events.

But without at least hypothesizing alignment of events to demand, it is difficult to foresee what "benefits" (if any) will likely be obtained -- thus leaving operations without a significant justification. Demand management represents the "business dimension" of overall operational alignment -- events are planned specifically against the known or expected range and scope of variability in demand.

This makes it clear that "performance" always presumes a capability with a justification -- and that is the most important slant that ITIL has on IT management.

IV.

Being able to foresee benefits is essential to executive responsibilities for planning. With planning, we chart the overall path from capacity to events to benefits to demand. The path must be accurately envisioned as management efforts.

The IT Infrastructure Library (ITIL) documents key principles and practices that organize the IT management path from capacity to demand. In describing how organizational resources are used to conduct the practices, time-tested examples of management processes are offered that show the coordination of distributed assets, utilization controls, and business requirements. Because processes are so important to implementing the management of these factors, process integrity and maturity are enormously important objectives of ITIL's information. Yet often the approach to understanding ITIL is too easily distorted by a competing perspective -- not the necessary one of "implementing management" but instead the habitual one of managing implementations.

The misfortune of this latter perspective is that it significantly discourages understanding and appreciation of ITIL at the organization's executive business level. The key to repairing or avoiding this situation is to understand how ITIL information helps to describe the management of events that characterize the business capability.

Performance Management is an evolving discipline that uses forms of communication and visualization that are strongly suited to mapping the origins of and connections between an organization's assets, functions, events and demand.

To maximize the positive influence of ITIL in the organization, performance management instrumentation can bring two things to executive attention:
- relevant business issues expressed in terms of the ability to impact events; and,
- the improvement of that ability as a consequence of pursuing compatibility with ITIL.

The target effect of the ability is to drive benefits that improve the infrastructure for business functions.

The key is to communicate this ability to drive benefits as more a cultural effect than a merely mechanical one.

With the more conventional "mechanical" view, the active drivers of business benefits (from events) are usually more about linear procedures, assignments, and accounting -- concepts that gain their meaning at deep levels of granularity and organizational segmentation. Their main objective is to establish compliance in the organizational activity, which fosters predictability (a lower risk) and scale (a benefit).

In contrast, by "cultural" we mean that the active drivers of business benefits (from events) are goals, priorities, and agreements -- concepts that need to be collectively meaningful across the organization. The main objective is to establish compatibility within organizational diversity, which fosters agility (a lower risk) and resourcefulness (a benefit) in the focus on demand and progress.

One thing we want to know is whether the two approaches shape different kinds of events in order to deliver benefits in their different ways.

V.

Rather than assume that a given business problem can be solved by differing benefits, we normally assume that the problem calls for a certain benefit and that we can get it, if necessary, from more than one kind of event.

But generally, events are cultivated not only to deliver certain benefits but also to do that with certain characteristics.
.
In driving the benefit, any advantage of the cultural approach over the mechanical would first be researched in how it addresses management's responsibilities for producing three critical delivery characteristics:
- functional excellence,
- quality, and
- economy.

Typically, each one of those characteristics can be framed as a measurable effect of premeditated standards, expertise and efficiency -- factors that go into shaping the events that are the source of benefits. So, what we can consider is how a cultural version of these factors differs from a mechanical version.

Standards, expertise and efficiency are all intended to maximize the stability and continuity of the health of the business by "optimizing" organizational responses (events) that generate benefits. Stability and continuity presume that the way the event occurs should leave the organization in the best shape to both use the benefits immediately and make additional future efforts. However, "management" brings intentional design to the way the event occurs. So, we look for the "optimal" outcome in the effect of the design.

- From a cultural standpoint, "optimal" means that risk and opportunity are in balance.
- From a mechanical standpoint, the "optimal" concern is the balance of cost versus output.

Within either case, the challenge to stability and continuity is fundamentally the same: despite the uncertainty of demand, which increases complexity, achieve an intended balance.

VI.

Optimization is the name of the effort to resolve the complexity. Optimization is not just opportunistic, but instead it follows a model, to logically pursue the highest priority outcomes. Here we have two models from which to choose -- a cultural approach and a mechanical one.

A cultural perspective on standards, expertise and efficiency does not exclude or contradict a mechanical one. Both perspectives emphasizes the idea that managing uncertainty in business is a critical success factor, and they both aim for stability and continuity of the business.

Instead, the cultural perspective argues that both stability and continuity are predicated on goals, priorities and agreements -- and that goals, priorities and agreement require dynamic and collaborative maintenance.

To associate either approach with the needed business benefits, we start by identifying and cataloging the functional expectations and targets that we attribute to them regarding:

Standards -- how they contribute to functional excellence,
Expertise -- how it contributes to quality
Efficiency -- how it contributes to economy

That is, we look at each of those as evaluated from the perspective of:
- business opportunity and risk (cultural)
- execution output and cost (mechanical)

The group of findings generated about the two approaches represent our expectations of them. Those are then immediately set against the logic for creating business benefit. That delivery logic will necessarily include these two components:
- The organization's availability of resources must be sufficient to realize the expectations.
- The combination of resources must amount to the "means" for generating the events that deliver the target business benefit.
Initially, the question is whether the necessary means are evidently "more likely" to be generated and sustained for the cultural or mechanical approach. But shifting demand changes the focus.

Understanding how to deal with demand means acknowledging the challenges of complexity. Complexity features a multitude of moving parts trying to come together to hit moving targets. Generating value from the complexity is tough:
- the organization must be resourceful enough in its diversity...
- to engineer appropriate events in real-time...
- from circumstances that have variability frequently exceeding "best case" or ideal formulas.

Dynamic, collaborative access and utilization of resources may be the only path to meeting a business need -- the path facilitated by the cultural approach.

The difficulty of the cultural approach is that it is more complex and thus is harder to organize and measure in a singular, objective way. Addressing that problem, the evolving discipline of performance management provides a solution that can consolidate these influences in a centrally manageable view.

Given that, the general importance and advantage of the cultural one is that it proves to explicitly relate to a wider range of demand on the business.

VII.

Demand management is staged as a shared responsibility of business and IT.

In planning, monitoring and measuring the coordination of resource diversity and demand variability, executives find that performance management can track and illuminate IT's contribution, position and progress.

In turn, leveraging ITIL should be done in ways that aim to maximize consistency and persistence in coordinating diversity with variability.

ITIL's guidance offers IT and business stakeholders a single way for both parties to see requirements and operations. The alignment cultivated through that common view reinforces expectations that consistency will increase in the Business-IT relationship.

The business intends for that consistency to translate into business capability, but the range of needed capabilities introduces more complexity against the intended operational effectiveness.

ITIL describes ways to resolve the complexity, towards consistency in the IT enablement of business capability.

With IT organizations expected to implement management that cultivates beneficial events, bringing ITIL to performance management helps the IT organization to describe the logic and importance of the difference that it makes -- i.e., "IT's value" against demand.

Posted by Malcolm Ryder at 12:11 PM | Comments (0) | TrackBack

November 26, 2005

The Value of Performance

A key threat to an organization's effective capability stems from missing the distinction between managing performance and managing value.

Naturally managers are expected to manage both, and the methods used are expected to generate information on which decisions are made about how to structure and drive the organization. If the wrong information is used, the organization may needlessly change or may change unsuccessfully. Becoming misaligned with the business, or becoming disfunctional through structural flaws, will reduce the effective capability of the organization.

To avoid the misalignment or dysfunction, decisions that provoke change must cause change for the right reasons.

The significance of information taken as an indicator of a need for change derives from a model of progress or a model of success. The model is both a theory and a plan that logically accounts for how progress or success is generated.

In practice, Progress and Success are defined in certain terms for the record, and operational achievement towards meeting those definitions is considered valuable. To be relevant to the model, information must help to account for the generation of valuable achievements.

This viewpoint allows us to understand why value and performance seem synonymous, but the distinction that needs to be made and preserved is a critical one for the relationship of the organization to its clients and hosts.

The target beneficiary of an operation has a need, and the need generates demand. But needs get prioritized without necessarily going away, and demand is generated from the priority. This illustrates that demand is actually not the same thing as need.
Meanwhile, organizational operation is meaningful because it addresses demand, and the way it addresses demand is to satisfy requirements. But different demands can "call for" the same requirement, which illustrates that requirements are not the same thing as demand.

Seeing those facts, we can understand the essential difference that management decisions and their suporting information must recognize and relate:

- Value pertains to the generation of a difference versus needs.

- Performance pertains to the generation of value versus demand.

This establishes the basis for management decisioning: managers are charged with driving and protecting progress and success, and now we know the essential terms by which they recognize and communicate the effectiveness of the management effort.

This view on the general relationship of value to performance clarifies the proper meaning and charter of "performance management". This view emphasizes that the concept of "performance" doesn't really materialize meaningfully until reference points (a model) are provided that both precede any actual execution and that afterwards evaluate the execution. The main goal of performance management must be to synchronize the actual outputs of operations with demand.

In contrast, the concept of "value" doesn't really materialize meaningfully until need is defined and confirmed. This puts planning into proper perspective: since plans by definition commit the organization to one scenario by excluding others, the importance of the commitment must be in its relevance to needs. The main goal of value management must therefore be to synchronize the actual outcomes of operations with needs.

Overall, the challenge presented to management is clearly visible. Since the "operations" effort is built around requirements, it can faithfully address them while actually becoming largely irrelevant to emergent needs. The translations of need into demand and then into requirements must be continuous and as real-time and seamless as possible if the organization is to maximize the effectiveness of its capability.

Information management techniques are developed to provide the visibility necessary for doing, tracking and using the translations. But technical support is not effective if the information is used to solve the wrong problem. For example, confusing value and performance leads management to attempt to address needs with outputs, or to address demand with outcomes -- mismatches that (worst case) leave organizations and stakeholders with false impressions of control and ROI, and with unproductive management agendas that are dedicated to changing things for the wrong reasons.

Such errors might be attributed in a general way to failures in knowing how things actually work. To avoid this very problem, management is saturated with initiatives in "intelligence" and "analysis" but there is then the complication of figuring out whether the intelligence and analysis are of the right type and the right amount.

Management typically puts a lot of attention on monitoring the "components" of a plan. But there are two ways to conceive of components.

In one approach, the plan's assumption is that there are mechanical "parts" -- such as the steps in a procedure or the quality of a particular resource being used -- and that their use is specially necessary to the intended progress and success. It's safe to say that this level of thinking is mainly operational.

But a more critical aspect for management attention concerns the actual reasons why the usage of those components is necessary, and concerns the requirements for their usage in the planned way. These are the success "factors", as opposed to parts, and the attention primarily takes the perspective of demand, not of supply.

Together, the reasons and requirements would determine that the mechanical components are "appropriate" for the organization's attempts to execute its strategy. But the components still do not drive the intended progress or success.

As seen below, the reasons and requirements cross-reference to form a framework for understanding how the organization can operate for performance. In this example application of the framework, a new product is to be reliably supplied to a target customer group. Basic assumptions emerge in the framework, representing a set of defined operational parameters or conditions that are to be managed. These are the success factors.

Now, information management steps in for decision support.
Where intelligence is concerned, if current findings indicate that the framework's success factors are not being met or validated, then adjustments would be justified -- to protect the execution of the plan from any significant divergence from the operational goal of providing relevant outputs towards demand. This would mean that the right changes are being made for the right reasons.

As for determining the right success factors in the first place, analysis is usally the weapon of choice. The framework's dimensions direct analysis at conditions that have categorical relevance to implementing for demand and thus will be about performance.

Posted by Malcolm Ryder at 7:32 AM | Comments (0) | TrackBack

November 13, 2005

Competency: the Organization's Inner Self

We know a lot about automating processes, and we do it to improve performance. But performance is all about behavior, the best of which is the competency that drives performance. While processes represent ideal behaviors, do we really expect to automate behavior?

The painful lessons learned from earlier efforts such as "sales force automation" may never be appreciated by today's innovators in knowledge management, operational performance management and social networking -- business's new power rock trio -- unless they recognize the secret: technology works when people want to work, and it doesn't when people don't. This gives technology two jobs: one, make people want to work; and two, make the work fit the people.

That looks like something automation can do. The easiest and most prominent example is found in great automobiles. And amazingly, a lot of great automobiles are now fairly cheap. Yes, mileage may vary with the driver, but the drivers nonetheless do what they intend to do more confidently, as they interact with the car, the road, and other drivers.

In the particular context of improving an organization's performance, this precedent tells us how to open and unpack the phrase "automating behavior", sidestepping its hype. Expanded, it means, "automating the support of desirable dynamics." Usually there are two ways of doing this, used in combination. One is to implement design-level support (of behavior) as "structure". The other is to implement design-level support as "programming". Both efforts are aimed at injecting "regularity" (predictability) into the dynamics -- which is why in both the structural and programming designs we tend to search for, or even create, "rules".

Example: while trying to assess organizations in a "performance" perspective, the notion of "behavior patterns" becomes critical. A behavior pattern is at minimum taken as a symptom of the underlying structure and programming in the behavior. Discovering the pattern, especially an unexpected one, is exciting because it gives a persistent reference point for deciding what (if anything) to change. Basically, we want either more of the symptom, or less. For undesirable aspects, we refer to the pattern for exploring underlying modifications; with desirable aspects, we refer to it for exploring underlying automation. Either way, we expect to find that general rules underlie the occurrence of the pattern. We'll then have our "improvement" programming use (i.e. exploit) the rules.

Because of that, the most critical issue is whether we have discovered the rules or merely invented them. The importance of the rules is to set priorities and consistency to the actual activity. In supporting improvement with rules, programming holds our attention first and longer, perhaps because it is easier to manipulate than structure. But the specific importance of programming is to set limits and methods to the potential activity otherwise inherent in the dynamics.

In that approach, automation is just a programming alternative. Normally, maximizing and fortifying the persistence of desirable behavior is covered by training. Still, in large or decentralized organizations there's the idea that process automation somehow directly manipulates what otherwise would have been unmanaged behavior, and that it does so more certainly for our outward intentions.

In fact, thinking in terms of behavior versus process, the typical expectations are as if behavior's "innate" programming and structure is natural, while process is synthetic on both counts. But then, if we see behavior exhibiting the characteristics of processes, we think we can manage behavior through automation just as we would improve a process.

What competes with this is the idea of self-organization -- of behavior that, without other programming, manages itself.

As the pattern that is discovered, self-organization seems to be the tacit or latent organization. Managers are cautioned about it, about the "shadow enterprise" or the "backchannel organization" stealthily constraining or dictating success or change... Predictably, our new performance improvement frontier is in using programming to manage that -- to manage the inner organization towards the outward performance intentions. If this is going to pan out at all, the first thing to attend to is ensuring that we don't set out to solve the wrong problem.

Accordingly, there needs to be a way to distinguish the key components of the organization's performance make-up -- the "what is" of the organization that builds up the "how to" that it exhibits...

So, you're sitting in the coaches office, looking at the videos of the team that just beat your pants off. You're trying to codify what they do, and you're trying to figure out what makes them tick. Play by play, you can see how they do something, but you're seeing it after the fact... You struggle to come to grips with the apparent spontaneity that they used to beat you -- the stuff you didn't see coming. You keep asking yourself, how did they know, during the play, to do that, then?

Deconstructing the opponent's execution requires understanding how their organization gets its capability both from its formations (structure) and from its routines (programming). But no less important is understanding the real difference between what seems to be ad hoc or natural, versus what is planned or synthetic. This much segmentation pulls up discrete factors that are clearly subject to independent changes but will continually interact to produce the observed results. They're the same factors that will describe the organization you are or want to be.

In attending to those factors, improving and leveraging them towards more effectiveness in their interactions, the definitive programming approach emerges -- that we should think first of cultivation, not automation.

Overall, that target effectiveness is, in real-time demand, the competency of the organization. Cultivating competency becomes the label for an objective that might otherwise be presented as "maturing capability" or "automating process".

In general, these different efforts should be complementary, as seen below.

But this model clearly allows for three ways to tackle a single thing. That is, the whole model could be applied to improving a capability in three ways, or a process in three ways, etc. This leaves us to think about why, for example, a process is different enough from a capability or from a competency to result in them being usually associated with different parts of the improvement model.

Meanwhle, as companies begin to look at social networking to discover and leverage their "inner organization", these companies will need to temper their excitement at the discovery of those behavior patterns with a reasoned approach to making use of them. The most obvious challenge is to first understand the communications protocol that is embedded in the social network, which is of course a behavior issue. Moves from behavior to process may or may not prove to be actual, agreed, consistent or preferred. Additionally, exposing a network may provoke it to change or discontinue before it can be engaged in any pragmatic fashion or agenda other than its own. It is therefore very unclear as to whether automation or maturity are even relevant formal management concerns until after cultivation of the network has been identified as a desirable opportunity.

Posted by Malcolm Ryder at 8:02 AM | Comments (0) | TrackBack

November 11, 2005

The Architecture of a System

The State of New Mexico Office of the CIO looks at why a CMDB connects architecture to operations in an excellent graphic that is led off with the following statement:

"The architecture of an information technology (IT) system is the structures of the system, which comprise software and hardware, the externally visible properties of those components, and the relationships among them."

Posted by Malcolm Ryder at 7:52 AM | Comments (0) | TrackBack

September 23, 2005

When is a system not a system?

Peter Senge kept coming to mind after a handful of exchanges with some colleagues about organizations being systems.

To grab a really crisp definition of systems that I knew I'd seen from him, I checked in at Frank Patrick's blog Focused Performance where lots of crisp things get presented in great context.

Frank quoted Peter:
A system...is anything that takes its integrity and form from the ongoing interactions of its parts...Systems are defined by the fact that their elements have a common purpose and behave in a common way, precisely because they are interrelated toward that purpose. - Peter Senge

What's tricky about this definition is the ease with which it's clarity seems self-evident. I can run with the statement up to a point, but only through another point first. Let's be sure we know that when Peter says "interrelated", he's giving us a verb and not an adjective. The elements of a system don't inherently know that they have a common purpose. That is, they have to be "told" about their commonality somehow. The telling involves a lot of things like engineering, configuration, assignment, regulation, and so forth. In other words, we "define" a system by deciding what purpose and behavior it is that the elements have in common. What Peter is really indicating is that if we see a bunch of "elements" and can't decide what is common in purpose and behavior, then we haven't identified a system. In another case, though, we might recognize what we'll call a "natural" system -- in which case we're just saying that the force dictating the system is not our willful invention.

Which brings up another question: how do we know something is an element before we have actually "created" the system by defining it? Usually this puzzle can be solved by taking what we can readily detect, and imagining it as a component that has the potential to be an "element". Once we give the component a job, it can become (or at least contribute to) an element of a system. Even if the inherent capabilities of the component is what gives us an idea for a system, the job actually comes from our idea of the system and may not even ask the component to do what it otherwise might do best. (I really ought to get that PC monitor off of those old phone books, but you know the monitor height is just perfect with them...)

Something related to this is that the more parts the system has, the more chance there is that a subset of the system's parts can develop a new interrelationship and behavior, diverging from the overall system model. So even when we know what components "belong to" a system, we might find that the elements are not sufficiently available.

This gets to the other important thing to think about: the system might be invented or it might be discovered. When it is discovered, it might not be the system that we wanted to find. Then there is the challenge of what to do about the difference. The reason why this is finally so important is that we often invent and activate systems that develop unanticipated dynamics and become different systems from the one we thought we invented. In effect, the system might "find" its own purpose. When that happens, how quick are we to detect it? Just because something's parts are "interrelated toward a purpose" doesn't mean it is cooperating with us.

This reminds me of my working definition of "mythology", which is "occasions when prescription substitutes for description." And therein lies the wariness I have about Senge's definition of a system. I don't disagree with the definition, but I worry about it's use. We should all be careful to find the system that is really there, and not just the one we expected or wanted to see.

The usual practical interest in systems comes from an interest in control. But between engineering a system versus training or coaching one, and between discovering a system versus synthesizing one, the variability in what we should do about systems is pretty vast; thinking in terms of systems gives a distinctive point of view but it's probably the view from the tip of an iceberg. We can be pretty sure that controlling an organization is an iceberg.

Posted by Malcolm Ryder at 7:37 AM | Comments (0) | TrackBack

September 9, 2005

Roles, Jobs and Self-Organization

Organizations increasingly seek agility as a target characteristic of their capabilities.

The value of this characteristic is usually measured at the level of change in external requirements on operations; but meanwhile, agility is really dependent on the ability to re-align the underlying internal functions on demand.

This is borne out by a view of operations over time.

For example, some external requirements do not mean that the type or strength of underlying functions must be changed, but instead merely their deployment; while others call for functions that are not yet executable in the current operations.

Re-organizing implementation might be approached through various steps that add, move, modify or remove functions, and more than one pattern of implementation may satisfy the requirements.

But typically, as the number of functions and the frequency of changes increases, it becomes increasingly difficult to effectively supervise the re-organization of their implementation.

And within the class of patterns that prove to be viable, the first concern is feasibility. Some patterns of implementation are preferable to others due to timing, durability, efficiency, cost, or other matters.

The supervisory perspective becomes the source of rules reflecting any policies and objectives that prioritize implementation preferences. But even assuming that funtional agents can keep up with the rules, can the rules keep up with requirements?

Because change and complexity run fiercely both through and around organizations, an alternative to elaborating rules endlessly is probably more important now than ever before. Organizational performance will depend on whether functional agents meet demand, moreso than whether they meet rules.

The two main ways of looking at functional agents are "jobs" and "roles". This determination can be applied -- as is the tradition to point out -- to technology, processes, or people alike.

We know that jobs are classically defined in a way that anticipates their consulting and following rules. But roles are different. Whereas a job "packages" a set of responsibilities into an assignment, a role distinguishes a contribution and benefit of involvement, without specifying the responsibilities in advance.

Logically, many different jobs can address a role, and in fact it makes sense to see a job as a particular implementation of a role. But while it's important for assignees to know their job, the dynamics of the organization are not revealed at the job level. Instead, describing the interaction of roles is a basic way of identifying how an organization works.

This role-perspective offers a profound potential benefit to agility: when awareness of roles is high, members of the organization can more readily recognize when alternatives at a functional level might still work. This allows them to change within and across the roles -- a behavior that can be called "self-organizing".

One of the most evident drivers of role-behavior is the "self-interest" or stake in the dynamics. Self-organization can be seen as a case of the participants seeking to optimize the investment of their involvement in the organization. Whether this is a survival tactic or a value-enhancement tactic is not irrelevant, but the two possibilities reflect the same essential behavior.

Below, the schematic picture shows a role model in a way that identifies the terms important to the flexibility of the role. The main importance of the terms is that they indicate where the role may coordinate with others (for example, by sharing or complementing) and with other managerial aspects (e.g. as compliance or protection) of the organization.
- Because the many elements of a role are independently variable, a role is inherently flexible, but its flexibility is constrained primarily by management standards and expectations.
- At the same time, adoption of a role by a member of the organization can be spontaneous if the role appears to offer a better "stake" in the organization.

Posted by Malcolm Ryder at 7:21 AM | Comments (0) | TrackBack

September 3, 2005

Optimization - the Effectiveness of Efficiency

optimize

v 1: make optimal; get the most out of; use best; "optimize your resources" [syn: optimise] 2: modify to achieve maximum efficiency in storage capacity or time or cost; "optimize a computer program" [syn: optimise] 3: act as an optimist and take a sunny view of the world [syn: optimise] -- Source: WordNet ® 2.0, © 2003 Princeton University

"Doing More With Less" actually has some competition these days (!), in the call for Optimization.

I toyed with the idea of demonstrating this by citing the number of search engine hits for "optimization", but of course the results of the search would be highly dependent on how many sites have been optimized for search engines -- probably the reason (or at least, a great reason) why the idea of doing optimization has become so widely propagated.

Leaving out the number of site hits, it still seems that almost anything can be "optimized", if you can believe everything you read. The problem is that the point of it usually appears to be to maximize something - so what's the big deal about using the word "optimize" ?

I.

Getting the most out of something really is the main idea of optimization. But while we naturally crave the "most" part of the offer, the lion's share of the practical attention to optimization goes to the "getting" part.

To the point and in summary, in optimization the usual assumption is that something we own or use has a less-than-maximum effectiveness because of some underlying inefficiency.

It helps to know that the final point of optimization is always really about "effectiveness" -- it means that the starting point of optimization efforts is always a determination of what effect the owned or used item is supposed to have. After all, as they say, if you don't know where you're going, then it doesn't matter how you get there...

Then, looking into the dependencies and causes for generating that effect, we'll see opportunities to solve problems, make enhancements, or innovate -- in order to increase the item's effectiveness that we need.

But that is why a problem arises with the popular conception that optimization is synonymous with "efficiency". There might not be a problem if the efficiency issue was always driven by an explicit objective defined by effectiveness. But, unfortunately, by analogy, while a square is always a rectangle a rectangle is not always a square. That is, optimization can be an outcome of efficiency, but "efficiency" does not always produce optimization. The problem arises in the ideas about efficiency and especially in myopia about optimization needing efficiency.

For example, getting further into that point, how would we understand activities like corrections, enhancements and innovations to be "efficiency" techniques?

The answer of course must be that "it depends on what is being changed." This realization breaks the myopia and helps solve the problem.

II.

If being effective means "having an intended or expected effect" while being efficient means "being effective without wasting time or effort or expense" then we know we're looking at whether the underlying mechanism of the intended effect is functioning in a way that includes unnecessary waste.

The challenge is to define the waste, confirm that it is unnecessary to the intended effect, and validate that the technique for its removal is not just going to replace one kind of problem with another kind that is equally undesirable.

But let's get a gut-level grip on this matter of what to change. Suppose that you are on a solo hiking trip, not anyplace too obscure or remote, but you get a bit lost or significantly delayed. You pull out your cell phone, but the transmission connection in the area is very marginal and very unreliable. On the one hand, during this attempted use of the phone, all parts of the communication system might be working exactly as intended, perfectly. We generally know that the parts are not malfunctioning. There may be no "efficiencies" to add to the components. But on the other hand, the combination of these components -- that is, the underlying mechanism for connection -- is not up to the task of producing the intended effect. In what sense(s) is the combination "inefficient"? What is being wasted?

This points up some fundamental considerations of "optimization"...

For one thing, when effectiveness is lacking, a major possibility is that the design of the underlying mechanism might be inappropriate, not inefficient. We wouldn't normally use a shopping cart to move a baby grand piano. Bulking up the shopping cart would be solving the wrong problem.

However, inappropriateness can be expressed as "an inefficient relationship" because, due to the intended effect, the tasks that are imposed on the underlying mechanism have performance requirements attached to them that the mechanism only inconsistently meets. These inconsistent support results mean that the opportunity is being wasted compared to what would be obtained from consistent support.

For another thing, it often goes overlooked that the situations we care about optimizing are ones that extend over time -- typically because some kind of action is recurring in order to produce what we want. Over a stretch of time, the recurring action may encounter significant differences in the surrounding circumstances from one point to another. The challenge is for the action to succeed at each point despite the differences in conditions. In fact, it's reasonable to expect that if the action itself doesn't change then its level of success may vary significantly from one point to the next.

If the conditions that are expected during the time period include significant variation, then getting the most out of the action must first be measured not on a point by point basis but on an overall basis for the period. A major characteristic of an optimized mechanism is that because it can make intelligent trade-offs it can persist over time within tolerances: it won't exhaust itself at every single moment if the price of doing that is inability to handle the long run. Resilience and agility is actually a hallmark of a mechanism geared for effectiveness.

III.

The focus on opportunity waste as opposed to production waste is what basically distinguishes optimization projects from mere efficiency projects. Eliminating waste must first be understood at the level of the opportunity, because that understanding will indicate what aspect (if any) of production should be changed and (with the benefit of relevant knowledge) how it should be changed.

At the underlying production level of waste, we deal essentially with the problem of the production mechanism's suitability to task -- both at the overall mechanism level and at the component level. Changes to the mechanism can be technical, logical, or whatever -- but the reason we deal with it is because of the appropriateness of the mechanism to the intended effect. If we live on a cowboy ranch and we have only a minivan, regardless of the condition of the minivan we're not so much concerned with changing the van as we are with getting a jeep.

But once we have a jeep, the issue becomes, "is the jeep good enough?"

While optimization is inextricably tied to issues of efficiency, the "elephant in the room" in discussions of optimization is "quality"...

Raising the effectiveness of a resource, within the tolerances of its assigned circumstances and intent, is actually about Quality. If efficiency is a path to higher quality, then efficiency should be leveraged but with a priority that also recognizes other paths.

But when we hit the limits of efficiency, if we also hit related but unintended consequences -- such as brittle processes, siloed operations, funding shortages, and rigidity against future change -- the net is not more effectiveness. We'll have wound up with something that is very very good at doing something we don't need or causing something that we don't want.

IV.

Optimization efforts should never be considered strictly in the context of efficiency -- because the necessary outcome of changes is always fitness-to-purpose, or quality, and only sometimes fit-to-capacity. We only ever put five players on the basketball court at one time -- but the key to winning (being effective) with those five is not the player-by-player tuneup but instead the organization of all five players in the tasks of the game.

The essence of optimization calls for a broader perspective that most highly prioritizes relevance to objectives -- followed by a range of options for changing the design of the support including corrections, enhancements and innovations. Efficiency, then, should be understood in terms of how to best execute the changes that improve the design.

Posted by Malcolm Ryder at 6:05 AM | Comments (0) | TrackBack

August 20, 2005

Invention, Improvisation and Innovation

I.

Every day, operations proceed with essential concerns about continuity and direction, within this same basic value-management cycle:

- Can we do it? / What are the outcomes? / Why is that important? / (Repeat) -

At each point in the cycle, operations managers presume that the desirable answer is a logical result of cause-and-effect. Putting pressure on each point, meanwhile, are significant forces (such as, respectively, skills and knowledge, location, and competition) that are tough-to-manage variables affecting the actual answer.

Now, with unexpected or rapid change occurring independently at each of the three points, as well as across them, more and more time is spent trying to overcome complexity in determining the difference and the linkages between intended cause-and-effect versus actual cause-and-effect.

Without this determination, management cannot know whether the most effective operational path to meet currently targeted ultimate objectives is through the existing environment or through a modified environment in the future.

There are many ways to conduct an environmental review that generates both an assessment of the current environment and a design of a future environment. All of them have the purpose of solving the same "You can't get there from here..." problem, by either repairing critical stepping stones or building a new path.

But always just as important as the path itself is how you run on it. For organizations whose management feels (rightly or wrongly) that it is in a known, locked down environment and needs more effectiveness from its activity within that environment, that train of thought is increasingly important. Here is where Invention, Improvisation and Innovation have pushed to the foreground, being additional ways that management can run.

Each option is an idea with important cache that, if abused, will reduce it to a buzzword. To prevent doing that here, let's point out the source of each one's attractiveness --that is, the associations that explain why each merits any attention.

a - invention: relates to products and productivity
b - improvisation: relates to capacity and agility
c - innovation: relates to differentiation and advantage

At a given time, the relative attractiveness of any one of them likely reflects the organization's current estimation of its performance problems. Any week spent reading the management trade mags will bear this out in the columns of strategic advice.

Meanwhile, it also seems easy to indulge the implication that the group of three line up as a "chain" of success factors, a-b-c. Indeed, what often happens in discussion is that the lines are blurred between the three, such that any one of them appears to be a spoke leading to the the same virtuous hub called NEW -- which reduces them to being synonyms for each other, or to being alternatives just requiring some pragmatic prioritization.

Those views are not always the case. But at worst case, misperceptions readily lead to misinterpretation and misuse. For the sake of being more proactively positive and avoiding "lost opportunity", we can look at the way that invention, improvisation and innovation generally get traction, and use that visibility to guide ideas about how to most sensibly incorporate the interest in them, as part of management.

The following diagram illustrates business components and relationships with which managers generate business capabilities. At any of these same touchpoints, management can manipulate capabilities with a range of options including invention, improvisation and innovation. But effective organizations take invention, improvisation and innovation seriously by managing the operational environment necessary to see them through the value cycle of can we do it, what are the outcomes, and why is that important. The high-level view shows infrastructure, goals and culture holding down the three points in the value cycle.

The picture's high-level story is about the complexity involved in the balance to be struck between value and its associated risks, and likewise between requirements and the options for meeting them. Respectively, high-level improvisation and innovation engage those tasks.

Let's look at invention, improvisation and innovation one by one, to start factoring in their opportunity, purpose and effect.

II.

In its literal root sense, Invention refers to "finding something within". Practically, this sense is associated with exploration and experimentation, the two activities that typically host and court the experience of invention.

Because both of those activities can be structured, their practice may be placed on a supporting mechanism designed to make them accessible, accountable, regular and persistent. We can see that underlying mechanism as a combination of methodology and infrastructure.

But once methodology and infrastructure are in place, they become the key constraints on invention. The challenges become to maximize the effectiveness of leveraging them, and maximizing the ability to re-engineer them if necessary. The importance of this is in the need to know whether they are promoting invention more than they are inhibiting it. As we increasingly find in the arena of knowledge management, invention is a fundamental daily activity necessary to site-specific problem solving in the organization. Nonetheless, an equally big challenge is to commit the investment in that methodology and infrastructure to actual invention as opposed to routine production -- otherwise the methodology and infrastructure are unlikely to change towards effectiveness. This commitment is seriously challenged because of the similarity thatinvention has to production activity. The similarity makes it easy for the organization to appropriate the means for one purpose instead of for the other; so invention must compete for priority in order to keep its means:

PRODUCTION
- manage compliance to known causes that effect specifications
INVENTION
- Manage attention to assumed causes that effect theoretical outcomes

If the organization does not have theoretical outcomes representing high mission priorities, then it is less likely to find the fortitude for sustaining use of its methodology and infrastructure to drive invention. This would likely prevent R&D in infrastructure and methodology. With the pace of change in business requirements today, that would be crazy: who was it that said the definition of insanity is doing the same thing over and over but expecting a different result?

III.

Improvisation, in its literal sense, refers to "the unforeseen". From that, it attributes two key characteristics to activity -- unplanned, and extemporary (casually observed as in "the heat of the moment" and "at hand"). Importantly, it involves no lack of understanding of what is to be produced; rather, it is concerned with how the production was organized. Being aimed at a target "effect", improvisation seems to be related to invention. But the real difference is that while invention proceeds according to a plan to make something of undetermined value, improvisation is unplanned but aimed at making something of determined value. The even more important issue with improvisation is that, unlike invention, it occurs under production pressure: that is, an acceptable outcome is already described and targeted, and the means of generating it must succeed within the excited restrictions of available time and materials.

In short, the problem in improvisation is not so much "product" as it is "process". As a shorthand for what could be another whole discussion in itself, let's think here of process as navigation. In this way it is easier to recognize the real significance of improvisation as a production mode -- which is not that it is any less rigorous than following a plan, but that it relies on a different frame of reference for guidance. The star-charts and weather forecasts of the operation's environment -- such as scorecards and dashboards -- must be the basis of decisions about pace and course corrections.

For management, the decision to improvise is challenged mainly by the dual concerns of accountability and risk. Thus, the choice to improvise must be made through prioritizing effectiveness over the expectations of accountability and risk. Deep experience, for example, offers a cognition and frame of reference that allows a manager to abandon what seems to be a failing prescription and improvise instead. We tend to discuss this in terms of "instincts", but for most managers, confidence in actually executing this way requires an understanding of the difference between process and "technique" -- with confidence in technique. Both process and technique are ways of describing "the method of procedure", but the difference is that process is specifically about the method of activity, while technique concerns itself with the method of using available tools and materials. Consequently, the key contrast is between improvisation and construction:

CONSTRUCTION
- organize production procedure around accountability and risk standards

IMPROVISATION
- organize production procedure around resource availability and logic

Usually, for improvisation to take hold, the organization's management must decide that in the face of a construction's projected inadequacy, the consequences of ineffectiveness are too harsh to tolerate. This explains why improvisation is most often considered for issues where unexpected failure looms. But it is also the case that improvisation serves as research for future construction-process improvement. So improvisation becomes an extremely valuable experience for enhancement through re-invention...

IV.

Taken most literally, innovation has the fascinating responsibility of "introduction". In turn, introduction has a core meaning of "to lead into" a position. This accounts for why every vendor touts itself as the "leading" whatever, because the vendor stakes its argument for your attention on the idea that it has "introduced" its particular distinction into some context with which you identify. But if all comers are "the leader" then what matters is what might be new about each one's effect. As noted frequently in content here in the Archestra collection, there are at least three main ways of being significantly "new", and the value of each will obviously depend on how relevant it is to the occasion at hand:
- new solution for a new problem;
- new solution for an old problem;
- old solution for a new problem.

As we know, any of those results might come from invention or improvisation... but to the extent that this is true, it occurs because there is a concept of "solution" that is actually applied to a problem. On the one hand, this application might be speculative. On the other, it might be highly strategic. On either end of that spectrum, motivation levels may be just as important. The issue is to determine the source of the motivation and whether the source remains a catalyst or driver. In short, is the innovation "needed"? The most important context for determining the answer is likely to be one that examines priorities for innovation versus improvement:

IMPROVEMENT
- increases the value of the result by enhancing its current type
INNOVATION
- increases the value of the result by changing its type

The key challenge to management is that innovation creates pressure on competency at an elemental level, possibly interrupting the terms of value already established for resources through their existing configurations. While the point of innovation is to get to a result, the practice of innovation requires that organization and competency are not misaligned through a redirection provoked by innovation.

V.

That leads us to the observation that infrastructure must be balanced against culture if the organization is to "get there from here."

In our environmental diagram (repeated below), this idea is illustrated as components and relationships that management can manipulate, with a range of approaches including invention, improvisation and innovation. Organizations take invention, improvisation and innovation seriously by managing the operational environment necessary to see them through.

Again, the picture's high-level story is about the complexity involved in the balance to be struck between value and its associated risks, and likewise between requirements and the options for meeting them.

At any given time, the current operational environment plays mediator by determining what types and levels of value correspond with given types and levels of risk. Meanwhile, norms (primarily including expectations and standards) usually set the terms on which operational alternatives are committed to requirements.

In situations of potential invention, improvisation or innovation, the broad middle zones of environment and norms are where change (through management) creates the energy and leverage that drive potential results.

VI.

In the diagram, the key change-points can be seen within three perspectives that comprise the environment: infrastructure, goals, and culture.

Strictly speaking, all three are generated by invention -- with the form of invention variously being physical or conceptual, essential or political.

Each perspective includes a characteristic value objective that is associated with a characteristic issue of risk. For example, infrastructure value is essentially expressed through management's ability to assure its availability, but meanwhile the risk inherent in infrastructure is in the configuration that it currently presents, which is also a consequence of better or worse management.

Typically, innovation adopts a new example of the value objective and calls for the risk to be realigned to it through the environmental factor. The major precedents for this have been reorganization and re-engineering, but the main observation that this illustration makes is the layout for integrating a variety of internal innovations. This puts the organization on an evolutionary path to threshold-level ability for producing and supporting a successful external innovation.

VII.

Two facts common to enterprise change also distinguish one organization's efforts from another:
- Direction creates focus; but different cultures have different ideas, which sets or resets direction.
- Competency creates opportunities; but different norms set different tolerances, which motivates or inhibits competency.

Management is working on direction when it tries to link goals to culture. When it tries to link infrastructure to goals, it is working on competency.

Improvisation navigates the potential connections in real time, which is the prerequisite for what the enterprise calls agility. Thus, improvisation works out alignment across the perspectives rather than within them.

However, the horizontal alignment effort that management has usually committed to is process improvement. In the big picture, that helps opportunity, but it only affects things from one perspective. Its relevance to goals and direction is still critical to protect its power to enhance the overall benefit of the operation. Infrastructure must be balanced against culture if the organization is to "get there from here..."

VIII.

A final observation about the model in the diagram is that it is an abstract model, not a literal one. This means that it is "scalable", because it can be applied to a small end-to-end effort as well as to a very large one. Wherever an effort can be described in terms of the related options, norms and requirements, there will be aspects of the effort paralleling "infrastructure" (the means), "goals" (the authorizing target results), and "culture" (the permissions and tolerances surrounding the effort). That means, according to the model, that invention, improvisation and/or innovation may be applicable.

Furthermore, since small efforts combine to complete larger efforts, we can see in a logically abstract sense that, for example, an innovation on one scale might be a component of improvisation on a higher scale.

Is this meaningful? As an example of "yes", consider that an innovation in infrastructure might enable an improvisation in business process -- one way to describe the architecture of a breakthrough to agility.

Posted by Malcolm Ryder at 7:51 AM | Comments (0) | TrackBack

August 15, 2005

Truth-based Management and a Single Version of the Facts

I.

Performance measurement has stampeded onto the scene in even casual literature discussing management.

The force of its impact is hardly about measurement per se, however. Measurement is not new. Rather, the buzz is all about what "performance" means.

Scholars, consultants, analysts, vendors and managers alike are aggressively exploring the scope of the term, searching for standardization of both its philosophy and its application in practice.

The resulting range of perspectives, from scholars to managers, is so sweeping that it often appears we could discuss nearly anything at all under the umbrella of "performance".

Despite this, much of the discussion now centers around a handful of ideas that appear with renewed urgency in many perspectives.

The two biggest of those ideas are:
- you can't manage what you can't measure; and,
- to manage effectively you must have everyone on the same page.

What makes those two the kings of the hill is that they each address the top problem in management today: operational complexity.

But -- what makes them such frustrating goals is that they each run counter to the "natural" probabilities of how management is exercised...

II.

Complexity is simply unavoidable. Business organizes its performance expectations around capabilities that actually require complexity to exist; and then it brings those capabilities into a game that features constant change. But at that point, ironically, the two most attractive characteristics sought of operations are simplicity and repetition.

Knowing that the knot of complexity should not really be untangled, management at least needs to reduce the number of significant variables crowding its moment-to-moment thinking, and improve the signal-to-noise ratio by deciding which ones to keep and which ones can be left out.

The normal strategy for this is to divide up and distribute responsibility for what must be thought about, so that fewer things must be attended to by anyone in particular. But naturally this brings the challenge of agreeing how to divide things up, and soon afterwards, how to overcome the many silos of information that result.

To recover from that, management usually brings a serious determination based on two resolutions:
- fact-based management; and,
- a single version of the truth.
In the typical management scenario, measurement is relied upon to "establish the facts", and decision-making relies on those facts to establish the type and priority of changes that will provoke improvement of performance. Interestingly, this approach makes it clear that measurement is a form of discovery -- and as the philosophers note, we tend to see what we're looking for more than we see what is there. Analysts further point out that the discovery instrument we use predetermines what can be discovered. Consultants note even further that the instrument is only as useful as its user is skilled. And so on... What emerges is a fairly definite realization that these "facts" -- born as they are through selection and invention -- are simply ideas that find agreement amongst the group of users who are considered to matter. But meanwhile, the discipline used to eliminate arbitrariness from "facts" is nothing other than competition from other facts!

Once we see that facts are actually propositions, the need for management to rely on them must move its focus from the facts themselves to the mechanism that validates the facts. When validation stops, the occasion signifies that the group intending to "stand by the facts" considers them to be "truth" -- and only at that point does management actually use the information to make decisions. In other words, the norm is truth-based management.

III.

Managers are responsible for deriving that truth. But managers everywhere have suffered from and battled information overload and inconsistency. That very experience is what has led many of them, whether politically astute or not, to acknowledge that "truth-based management" has been the reality. And, as the management of business operations has itself been segmented into different component departments or functions, the competition amongst different resulting versions of the truth drives executives crazy.

Hence the call for "a single version" of the truth. What this is supposed to mean is a single set of facts that represent the state of any subject or object to the highest degree of undisputed accuracy. The usual expectation is that this accuracy is practically indistinct from the validation that we've just discussed. But why is this expectation incorrect?

The answer is that the call for the single truth is driven by only one thing: the need for confident interpretation. This need presumes that with "one truth" there will be no contradiction in the meanings that can be drawn from the facts. Contradiction is a strong word, but within its literal definition of "speak against", it simply means that there is more than one way to describe something. In business, that variety is usually the desired rule, not the exception.

Naturally, when there is more than one way to see something, there is an underlying reason. The main reason in management is because management itself is distributed. Having different views of the same facts is justified by the same thing that justifies distributing management in the first place: the need for multiple points-of-observation. That does not conflict with the idea that facts should be accurate -- management should pursue a single version of the facts; and yet because they will be interpreted in various ways, the emphasis should be on the objective of the interpretation, not on the results of every available metric.

IV.

And that brings us to today's circumstances. But what does it have to do with measuring performance?

Performance refers to the degree of achievement towards a predefined target pursued in a predetermined way. Due to operational complexity, it is increasingly difficult to determine the extent to which achievement levels are the result of the predetermined activity path. If achievement levels are too low, too inconsistent, or too brief, then underlying chains of cause and effect must be identified to reveal the mechanism needing adjustment.

But the next thing that management has to do in that investigation is decide what it is that must be assessed about the "performance" mechanism. The assessment problem stems from confusing "performance" with other issues such as "value", "quality", "efficiency" and "execution". The common fault is that one of these issues crowds out the necessary visibility on the others, and poses as the whole story of performance.

In managing the business, each one of these issues is a mandated interpretation of circumstances -- one that results in more and more data being cultivated in a search for more precision in their respective explanations of what's going on. The challenge becomes to select from each perspective only what is necessary to construct a logical end-to-end account of the causes of achievement levels (effects).

The second thing management must decide is what degree of precision is necessary to basing the assessment on measurements. The third thing is then to decide what to do about the results of the assessment. Differences between the apparent chain of causality and the desired chain will have to be rated for their entrenchment and criticality. If the chain is altered, management may need to follow suit...

Most businesses have operated with the assumption that precise interpretation by a manager is the higher responsibility. But complexity is forcing us to realize that the base level of effective interpretation likely lies across management perspectives, not within them. Meanwhile, the higher responsibility within a given perspective is accurate but judicious observation.

V.

In an environment where complexity is the rule, performance is a concept that must be articulated across multiple perspectives. Performance is not just an event; it is the outcome of a competency that navigates diverse opportunities to direct activity towards goals. This often means seeing a single event in multiple ways, to find the chance of making it mean the most in terms of value.

A classic example of a single-fact with multiple interpretations is from the customer service world, where telephone support is expensive by the minute yet building customer relationships is the source of long-term profit. In this situation, the average length of a support call should be determinable with high accuracy and little debate. But the impact of that call length can be assessed in several dimensions. One point of view on a 10 minute call can be that 10 minutes is a high dollar cost. But another view is that the information exchanged in the ten minutes might increase the strength of the customer's efficiency thus loyalty and likelihood of buying again. Or it might signify that the support agent has now finally mastered a range of skills sufficiently to take the full range of issues in a call and resolve it without transferring it (even more expensively) to some other agent. These different dimensions are important to acknowledge and assess, but what should not be in dispute is the fact of how long the call was. Meanwhile, support costs need to be calibrated such that they enable impacts that drive the development of business value for as long as necessary. Since there is that important relationship between time, costs, and impact, the relationship must be managed, not just the parts, if the goal is to "improve levels of achievement against target levels through that means" -- that is, to improve performance.

VI.

In managing performance through measurement, the challenge is to first have an agreed model of performance that is comprehensive enough to address the important multiple dimensions; this is the "truth" aspect, the same page. Meanwhile, within any dimension of interpretation, consistency in point of view should be a goal; that is the "fact" aspect, the measurement foundation. Therefore, a mechanism must also be established to conceptually share "facts" across dimensions.

VII.

The biggest point of complication is where the interpretation of facts is also required to generate new data that must be used as "facts" in another dimension. Experience has shown that the classic way of doing this -- namely, hierarchical rollups of reports across management levels -- must be supplanted by information translation across dimensions.

This means nothing less than that a framework must be in place to provide an architecture of development and interpretation of facts. The framework is used by all management perspectives and levels. It provides a standing logic that explains the nature of the information needed to account for performance -- thus relieving anxiety about levels of accuracy and precision without discouraging them. Without this framework, performance measurement always risks merely replacing, at no reliable benefit, one kind of complexity with another.

Posted by Malcolm Ryder at 7:35 AM | Comments (0) | TrackBack

August 12, 2005

When "ROI" means Return on Insight

Best quote of the week comes from Thomas Davenport, director of research for the executive education program at Babson College, who was interviewed by CIO Insight magazine:

The only way we can get people to use knowledge on the job is to understand how they do their jobs, and then figure out some way to inject knowledge into the course of their day-to-day work, not make it a separate thing [they] have to consult when [they] need knowledge.

In this lengthy interview, Davenport also leaves us with the ironic thought that this might be pretty difficult to do for knowledge workers (!) because so often knowledge workers don't expose or formalize the process(es) that they use to get their work done.

Well, that's gotta hurt. As a group, knowledgeworkers are these days tagged as the source of innovations that are the source of business growth. Growth is good, yes? So...

Setting aside the alchemy of k-worker production, we can still always say that the rate at which innovations prove to drive growth is a performance measure, and the resource efficiency with which k-workers produce effective innovations is another performance measure.

But certainly there can be innovations that, regardless of how efficiently produced, prove not to be growth drivers; and there can be innovations that were "produced" outside of any intentionality other than ultimately acknowledging the effectiveness of something unexpected.

This reminds me to bring up Post-It Notes and Silly Putty, two famous accidents that luckily got seen in a different way, were trademarked (or something just as fierce; please take notice), and went on to revolutionize work and play. They exemplify one of the three types of innovation:

- new solution to new problem;
- new solution to old problem; or,
- old solution to new problem.

But which one? What's so interesting about deciding which type of innovation they represent is that it depends on who the customer was. Let's face it, for some people, being able to temporarily copy a comic strip and bounce the copy across the floor had never been a problem. For them, the discovery of the gooey means to do so was... enlightening? Aggravating? Confusing? I found it Compelling, almost shocking, as did my fellow fourth graders.

Thanks to some guy with insight, when the accidental putty was christened "Silly" and re-purposed, it became an innovation instead of sunk cost. How do we assess the "productivity" of that sequence?

Effort of all kinds involves on the one hand the intended vs. unintended, and on the other hand the expected vs. unexpected. What are the possible outcomes? We actually have names for them that are already pretty conventional:

- Intended and Expected: product
- Intended and Unexpected: experiment
- Unintended and Expected: risk
- Unintended and Unexpected: accident

In hindsight, the lab work that failed its purpose yet output the putty dubbed Silly could be called "research" (experimentation); while in foresight, the intent to "salvage" value from the putty could be called "development" (production)!

Knowledge that was contributing to (or at least consumed by) the research is one thing; knowledge that drove realization of the market potential of the re-purposed putty is quite another. The labwork methodology was likely pretty well prescribed, in an explicit way. The likely tacit and intuitive method of recognizing "Silly Putty" might simply not be practically proceduralized. Is this difference one of being mechanical versus organic? Scientific versus artistic? And/or other dimensions?

This inspires me to list key touchpoints in a dynamic that might account for both the "failed" labwork and the "successful" marketing vision:

inspiration -> improvisation -> insight -> innovation

Inspiration: much of this comes from observation, experience and especially memory; deciding to see or think about something in a certain way.

Improvisation: this is very much like exploration and especially testing, whether it be conceptually and logically as with "thought experiments", or instead materially as in the lab; designing the relationships indicated within the inspiration.

Insight: this is very much like comparison and analysis, especially inference; understanding the implications of the improvisation.

Innovation: on a practical level, this is very much like categorization and especially contextualization; finally deciding what to do with the insight.

In considering modes of injecting knowledge into the "process" of knowledge work, we need to be willing and able to respect the difference between a dynamic and a process. The most important difference is that:

- a dynamic is the behavior of a network of simultaneous influences, whereas

- a process is typically and essentially linear even if it is able to contain detours, shortcuts and sideroads along the way.

It does makes sense that a dynamic can generate a pattern of behaviors that we might finally describe as a process if the pattern is recurring -- or more to the point, intentionally repeatable. But, it might be that the problem of increasing "productivity" in knowledge work is to feed information into the touchpoints of the dynamic in an effectively influential way, rather than to shoot for a process that might not exist.

Posted by Malcolm Ryder at 4:26 PM | Comments (0) | TrackBack

August 11, 2005

Performance from Knowledge-based Quality

Readings and conversations frequently put the question in mind, "what is the difference between managing performance, quality and knowledge?"

Described specifically in the context of a business:

- Performance management provides a practice and methodology for ensuring operational alignment to business requirements.

- Quality management provides a practice and methodology for ensuring production compliance to product requirements.

- Knowledge management provides a practice and methodology for ensuring concept relevance to process requirements.

In all three cases there is an issue of usage (using operations, using production, using concepts).
Likewise, all three are associated with some kind of mandatory success threshold (alignment, compliance, relevance).

But their distinctions are critical.

- Performance is focused on organizational design and purpose. (business requirements)

- Quality is focused on customer expectations and demands. (product requirements)

- Knowledge is focused on role-specific competency. (process requirements)

These distinctions are "sweet spots", not mutual exclusions or boundaries. But their relationship to each other has a typical pattern: generally, the business should assume that knowledge will drive quality to a level where desired performance is enabled.

Specifically, concepts inform the production underlying business operations. But each of those three elements can change at any time; and therefore, their relationship -- as practiced by the business -- merits continual re-evaluation and pertinent tuning.

Meanwhile, each respective case (performance, quality, knowledge) has a management process associated with it that has the goal of improving the state of that case. Thus, to improve its own effectiveness in that responsibility, each management process itself becomes subject to better knowledge, quality and performance.

For example, the Performance Management Process itself should evolve with attention to its associated knowledge, quality and performance.

This shows that as a set of abstracted competencies, the pursuits of knowledge, quality and performance can be applied at many scales in the business, from the task level to the project/process or finally the enterprise level. Consider these examples:

- At any given time or place in the life of the organization, there might be a focus on the "performance" of the Knowledge Management practice, while Knowledge Management is under pressure to help improve business production's Quality.

- Or there might be a focus on "quality" within (that is, the quality of) Performance Management, while business operational Performance overall is additionally being supported by business production's Quality Management effort.

And so forth...

The business needs to identify these various more specific emphases and determine whether or how they are complementary (or at least mutually benign) rather than competing.

Posted by Malcolm Ryder at 10:55 AM | Comments (0) | TrackBack

August 8, 2005

Strategy vs. Governance vs. Alignment

When is a solution not a solution? When it solves the wrong problem!

Hunting for solutions is so complicated because it is a multidimensional issue.

First, solution approaches vary:
- re-engineering, or "designing the problem out"
- innovating, or defining a new relationship of a technique to a task
- renovating, or correcting mismatches of current configurations to current requirements

Additionally, a choice must be made between pursuing the root cause of the problem or pursuing something less (such as symptoms). This choice is affected by:
- timing
- execution risk
- cost
- agreements

And not least of all, stakeholders affect the prioritization of the solution effort. In general, stakeholder concerns include:
- solution scope
- benefits and liabilities
- safety

These issues of approach, range and priority are almost invariably brought up in discussions about strategy, governance and alignment. Relying on the guidance of these discussions, a very substantial checklist of action items can easily be built. This level of awareness is a critically useful shot of clarity, but how do you decide which action items are the "right ones" to put at the top of the list?

First, defining the list's "top" region should follow the technique of rating alternatives according to both importance (the need for a certain impact) and urgency (the starting time needed to ensure likely achievement of the impact). Items that rate highly on both counts go to the top.

This won't prevent high-priority issues from competing with each other. And the competition doesn't mean that something big should be dropped... But the different items should be distinguished by their purpose.

This is where most of the confusion reigns in the literature about strategy, governance and alignment. There is no debate that most of the concerns in any of those articles and studies are vital to preserving and improving business opportunity, but that doesn't automatically communicate how to incorporate the advice at the appropriate times and levels of the organization's operations. Such incorporation is a critical success factor to the solution really being a solution.

Too often it seems that every concern is trumpeted as an item essential to every cause, whether the cause is strategy, governance or alignment. But if there is any importance to the different names for these causes, then how can the most effective distinctions between their respective basic concerns be drawn out?

The quickest way may also be the most reliable and comprehensive. Often the difference between the causes is mainly a difference of "perspective" -- and perspective is something that by definition is generated by looking around from a certain point of view. It is possible to see the same item in more than one perspective (or literally, from more than one point-of-view), and this is how the same item comes up in different stories. But the item's meaning can and often does vary with the perspective. The trick is to detect that difference, and this relies on point-of-view.

We can describe the key organizational management perspectives called strategy, governance and alignment, as follows:

- Strategy: addresses needs; needs are about the values of the organization, which reflect its idea about where it is in the scheme of things and what importance is attached to that position.

- Governance: addresses requirements; requirements are about the critical dependencies that exist amongst interactions that define the organization's functioning.

- Alignment: addresses specification; specification is about the particular definition of deliverables that are measured for their level of impact (whether benefit, neutral, or liability).

How confident can we be that these distinctions are correct?

The first way to test that confidence is to simply imagine if there is any importance to the initiatives for strategy, governance or alignment if they did not focus on the key components in these descriptions. Strategy that does not organize things around needs is pointless. Governance that does not organize things around requirements is pointless. And so on.

The second way, in case the first is not decisive enough, is to look at what the three perspectives respectively show us about the organization's current state and therefore what kind of problem is at hand. Generally:
- Failures of strategy pertain to the way an organization became disassociated from the basis of the opportunity that it pursued. It lost relevance.
- Failures of governance pertain to the way it became unable to control the dynamics of the opportunity pursuit. It lost viability.
- Failures of alignment pertain to the way it misunderstood the importance of its output versus the way its stakeholders did. It lost value.

As a result, we can finally understand the differences in an even more rudimentary way:

Is it time to change directions? -- Strategy
Is it time to change the rules? -- Governance
Is it time to change measures? -- Alignment

In order to follow up on any of those three things, certain actions prove to be constructive, and some of those actions prove to be constructive in two or even all three of the areas.

This further explains the recurrence of certain points and advice across all the various topics. But the key to their being "successful" solution components is to understand why it is important to achieve the difference that they make, set expectations accordingly, and then use them explicitly for that reason.

Posted by Malcolm Ryder at 11:08 AM | Comments (0)

June 25, 2005

Architecture and Strategy

Architecture designs spaces for functions.
Strategy designs functions for spaces.
OK, on with the show.

Posted by Malcolm Ryder at 11:33 PM | Comments (0) | TrackBack

June 22, 2005

Managing the Productivity of Knowledge Work

Co-founded by a group of organizations including Accenture, Microsoft and Xerox, the Information Work Productivity Council drives a sustained collaboration intended to build a framework that measures productivity in "the information-centric business environment of the 21st century."

Early research released from the Council stresses the importance of some evolving ideas for understanding productivity in "information work and knowledge work" through a combination of lessons learned from manufacturing and I.T.

However, Accenture's Institute for High Performance Business emphasizes that a definitive reference model for measuring this productivity is still not on the horizon. And the IWPC itself states, "Although recent surges in productivity have been attributed to the use of IT, we still have no effective way of measuring or verifying its impact on information work."

In no small part, according to Accenture, this is due to ongoing debate about what to include in the kind of work being scrutinized for productivity, even including a sense that the popularity of the term "knowledge worker" might be missing the point by arbitrarily discouraging attention to equally important issues of information-based productivity.

But while Accenture makes those comments with a view on the internal needs of a given single business organization, I think it is absolutely necessary to step beyond that and propose that the "industrial" landscape of 2005, compared to the landscape of 1985 or 1965, quite loudly demonstrates increased "productivity" in the form of 2005's awesome diversity of types of viable business attributable in the main to business IT adopted in the last few decades. Proposed more simply, IT productivity really manifests itself at the market level moreso than at the enterprise level. Likewise, "knowledge productivity" manifests itself at a higher level than operations, in the form of a sustainable diversity of fully viable business capabilities. Discuss...

The intensity of the "productivity" investigation is certainly not at all in doubt, but the majority focus is on a somewhat different point, as both executives and academics are going "all out" to credibly factor the business reliance on information work (including knowledge) into the equation for business value and business valuation. That effort (and accompanying debate) would account for how knowledge work affects the conventionally measured productivity of a business's company.

Nothing strikes me as more certain to inhibit the effort as would a failure to unravel semantic confusions that inspire solving the wrong problem. Credit IWPC for stepping on that same stone, but in my view what follows from that point is a brief sprint down a course of resolution different from IWPC's -- not to a necessarily different or further endpoint, but in an alternate direction at least for the time being. My premise: there should be a view of the productivity of the actual work itself, providing a precedent baseline logic establishing why and when the work contributes to the productivity of its consumers and beneficiaries. In particular, I'll focus on knowledge.

1.

To begin, let's presuppose the reason behind our certainty about the criticality of knowledge in the modern business.

The fundamental operational issue for the business is to maximize opportunity at minimal risk, and to convert the opportunity into necessary benefit at minimal cost.

Correspondingly, utilization of knowledge is needed to, and proven to, impact opportunity in three essential ways:
- accelerate its development;
- differentiate it; and
- secure it.

Meanwhile, utilization of knowledge enhances the foresight and awareness of risks and costs pertinent to the opportunity.

The elaborations of that utilization are seemingly infinite, if accounted for by the organizational variations of one company to the next. However, the principles for the utilization do not change from one company to another, which means that there is a common reference regardless of the commonality of practices.

2.

The next presupposition, however, is the most critical one to my direction -- namely, that the term "knowledge worker" is NOT a synonym for "information processor".

IWPC's namesake distinction of information from knowledge is an important precedent for including "information work" beyond "knowledge work", signalling the belief that really meaningful talk about productivity requires an expanded field of terms. But a more fundamentally important observation to make is that "processing" is work, and that knowledge workers are process managers.

The key question is, what processes do knowledge workers characteristically manage? What's necessary here is to answer the question the right way, assessing the activity being conducted instead of the department (e.g., marketing or finance) commissioning the work. And this activity can be assessed in terms of knowledge, without the expansion into "information work", as follows.

This next short list highlights the distinction that is most relevant to the business issue of knowledge work productivity. These processes have outputs, and the business challenge is first to understand the significance of the outputs and second to understand the practical options for optimizing the generative processes:

(1) Strategics: a term coined here as a placeholder, this is mainly the interpretation of projected conditions with the goal of modeling their relationship to objectives.

(2) Heuristics: this is the use of a hypothesis as an instrument of iterative examination.

(3) Diagnostics: this creates and applies systems of identification and classification to distinguish the constituent elements of conditions and entities.

(4) Forensics: this discovers and determines items as relevant elements of a proposition that is a candidate "fact".

Then, the important consideration is the matter of how those activities are proceduralized, such that their respective underlying methodologies become portable to other workers. Logically, this is one of the responsibilities of the individual knowledge worker: initially adapting the activity's methodology to the real environment for operations. This adaptation is the basis of the activity's effectiveness. But the adaptation can also be assisted and formalized, to increase the efficiency of applying the methodology by the given worker. Any external assistance can be considered an "input" to the management of the processes.

Here, another distinguishing point emerges regarding direct measurement of knowledge work's productivity. The person identified as a "knowledge worker" could be evaluated as a "resource cost" -- but that type of evaluation is likely arbitrary without comparative benchmarks that describe the same activities and assists applied to substantially similar circumstances. In effect, the "resource cost" view presents the "knowledge worker" as a kind of function, for which availability and quality are actually the key measurable characteristics. But in that case the productivity issue derives from the management of the worker, not from the worker's own effort. We still want to understand the worker's effort itself.

3.

What really matters to business improvement is the impacts of the knowledge processes. For example, there are two basic categories of significance holding four types of results that should be treated as target business outcomes of the knowledge work:
- (impacts related to liabilities) risk mitigation and lower opportunity cost
- (impacts related to benefit) quality certification and innovation

As the source of these impacts, the knowledge processes managed by the worker thus protect and expand the business's measurable ability to affordably create and capitalize on opportunity. This means that, when successful, they produce a new "resource" of greater value than the business's ingoing investment in acquiring, deploying and maintaining the knowledge worker as a resource. That defacto statement of ROI addresses the motivation behind executive attention to the improvement of knowledge work.

Posted by Malcolm Ryder at 9:33 PM | Comments (0) | TrackBack

May 23, 2005

Permission versus Approval in Governance

"Governance", unfortunately, means different things to different people. First, there is the aspect of who enforces compliance. Second, there is the issue of how each given business participant's scope of responsibilities mean they should conduct compliance. Depending on who most needs increased orderliness in the environment, the two aspects are blended in various ways.

In order to work out those blends, one thing that governance should especially be able to do is to formally distinguish permission from approval. Why? Because when company members must decide amongst multiple options for action, approval will link the choice to current priorities, while permission only links it to opportunity. Thus, permission fosters opportunism, while approval fosters performance.

Enforcement and conduct are, of course, fairly direct influences on "successful" governance, both individually and in their relationship to each other. But the relationship between the two of them is often invented, not just legislated.

That happens because an organizational structure, although highly pragmatic, must not be rigid; and as it structurally changes to meet evolving and new requirements, it must rediscover what is governed and where a practical need for governance is most emphatic.

In the business organization, the relationship between enforcement and conduct must usually be resolved from the top down in the management structure. Yet "top-down" is not a one-size fits all approach. Instead, a variety of formats exist to establish the presence of a governance practice, including centralized, shared, federated, and others.

Our society is so complicated these days that governance is becoming an increasingly explicit topic of concern in regular life. This exposure might be very instructive.

For example, one especially interesting phenomenon of top-down governance surfaces in the news every few months: how can there be an event that is federally banned yet allowed by the states? What is the point of having a state position that apparently is overruled by a higher authority?

A review of this governance issue may hold lessons for use within the individual company arena.

First, we would consider what is the purpose of the state level of government versus the federal level. Second, we look at how the purpose distinguishes the position taken on the issue.

As an example, certain medication options appear to be permitted by a state but not permitted by the federal govenment.

The trick here is that the overrule is only apparent. Here's a solution to the paradox:

- The Federal-level position is that the medication is "not permitted" unless authorized, but that authorization is permitted at a state level.

- The State-level position is that the medication is permitted if the state authorizes it, but it is not authorized unless it is approved, an action for which there is generally some procedure defined. The procedure itself may have to pass Federal muster.

This makes a state-level approval the condition that establishes permission recognized at both the state level and the federal level, bringing them into alignment.

This complex mechanism of granting authorization and approval rights is interesting primarily because it allows a "think global, act local" approach that accommodates present risk and change in operations.

The accommodation allows for contingencies and innovation that help the organization generate and capture more opportunities of great value -- namely, opportunities for business recovery, continuity or growth.

A business mechanism similar to the example above might feature a policy guiding a portfolio with which the organization is managing some contracts.

Posted by Malcolm Ryder at 11:48 AM | Comments (0) | TrackBack

May 21, 2005

The Archestra Lexicon

The Archestra lexicon consists of terms that describe three classes of structures:
entities,
instruments, and
domains.

Entities identify the organization as distinguished from other organizations having autonomy and independent ownership of assets.

Instruments describe and supply the logic used to guide the organizational activities.

Domains identify the relationship networks used to host and channel agreements that form the enterprise.

Strategy and Architecture blend these structures to create the business.

[Entities] include: ---------------

Enterprise the full extent of relationships that constitute an organization's sphere of influence through its developmental and transactional activities.

Company an organizational unit of an enterprise accountable for the distribution and utilization of designated assets within a prescribed jurisdiction and range of locations.

Department a unit of an organization established to be accountable for the functional progress and quality of business processes based on a task-level of execution.

Task a prescribed association of a work-requirement, a skill set, and a work-product -- to measurably change a condition and thereby meet the requirement.

[Instruments] include: ---------------

Framework dimensions that select and coordinate the structural components and relationships within an entity.

Model a demonstration of the characteristics and interrelationships of components in an entity that allow its structure to support its purpose.

Policy a charter of negotiated tolerances constraining operational decisions.

Process a prescribed series of inputs and outputs for points of action that transform conditions from one state to another.

Function a predefined type of transformation of material or conditions performed by a predefined type of action.

[Domains] include: ---------------

Firm all stakeholders whose management decisions directly affect the balance of cost and risk in the enterprise's investments.

Organization the full set of contractual and regulated relationships that dictates the consumption of resources by business processes.

Project the organizational method for development of a specified construction

Infrastructure the set of rules, policies and mechanisms that make "environmental resources" available to inhabitants on demand for purposeful activities.

Architecture a set of principles that prescribes standards and models of construction and component interactions, to assure compatibility between environmental capacity and the functional needs.

Posted by Malcolm Ryder at 5:21 PM | Comments (0) | TrackBack

May 15, 2005

What is "what you know" worth?

It's not what you know that counts; it's how you know it.
Ask any psychic.

I. So, you wanna be a knowledge manager.

What are you, psychic or something?

Ordinarily, you can go down the KM path armed with this:

Data+context = info
info+usage = knowledge
knowledge+history = wisdom

You'd think this would be a good place to have your employees wind up, but that's not what they care about.
Their issue is that they have to go from observing to thinking to deciding to expecting. The path they want you to pave is like this:

Reconnaissance --> Information
Information --> Analysis
Analysis --> Patterns

We're accustomed to leaning on our "information systems" to carry out the reconnaissance and analysis, but do our info systems make us smarter? Only if they interpret the patterns, too. We feel "smarter" when, based on what the patterns mean, we know what to expect.

Why the emphasis on expectation?

Because in business there are two main types of "smarts", both future-oriented -- the kind that reduces risk, and the kind that leads to innovation. By solving problems, and by surprising customers and competitors, the business goes forward and gets ahead. That's where the rewards kick in.

So what do patterns have to do with these benefits?

With the speed of information processing now available, the main problem for a business is not to get enough information on time, but instead to get "the right" information. For the most part, the problem lies in not knowing which information is relevant or "best", and that confusion makes both finding and choosing the right information equally daunting. Result: complexity in the thought process overwhelms confidence in decision-making.

But a pattern exhibits a path that navigates through complexity. This is the kind of knowledge that rates highest, the kind that the business wants.

And who are considered the smart guys in your company? The ones who can either make a path or see one, where others can't or don't.

But how do they do it? More importantly, how do you do it for your folks?

II. Teach a man to fish...

Typically, "business intelligence" comes in with the responsibility of generating patterns from the complexity. This sets the stage for what the business is really after, which is to use the patterns to make decisions.

Thus seeing the affair as having two steps, we can look at what essential challenges the knowledge manager will need to overcome.

The first step, "intelligence", is critically dependent on information discovery. We realize that the diversity of the company's employee and customer population means that there is a lot of information distributed in ways and places that are tended mainly by those people. To aggregate the distributed information, we need them each to contribute what they have. Usually called collaboration, a voluntary aggregation creates a body of information that must be formatted for usability-on-demand. Making contributions voluntary is a tough prerequisite worth solving only if their usability is also known to be within reach. Altogether, this is the heavy lifting that changes the way most people can get things done. Even exceptionally gifted "knowledge workers" or experts like Infoworld's Jon Udell rely mainly on this capability enhancement.

The second step, "interpretation" of patterns developed from business intelligence, is about what people will decide to do. It has most often gone by names that we (except for marketers) don't attach to information systems, names like "wisdom", "insight", and "intuition"... Too often hopelessly confused with each other, they seem unmanageable or evangelically mystical.

Fortunately, each mode of interpretation can be seen generating a distinctive kind of "findings" which have practical value in support of decision-making. But these kinds of findings are something that we need to get our hands on -- and then record, repeat, compare, associate, and so on -- from less than supernatural sources. People, histories and systems can all variously help, but the full value comes from covering all the interpretative modes:

Wisdom --> Probabilities (operations)
Insight --> Implications (tactics)
Intuition --> Foresight (strategy)

III. The Payoff...

This consistently future-oriented perspective on the value of knowledge is naturally where KM needs to bank, strategically empowering risk management and innovation on demand.

Ultimately, what the business wants from knowledge is explanations for "what kind of risk did we decide to take?" and "how is this going to give us a new advantage?" Bottom line: "What makes you think that?"

Managers should have a bird's eye view of the plan for keeping those explanations coming.

- A certain amount of excitement comes with realizing that a description consisting of foresight followed by implications and then probabilities yields... a business case!

- And, accompanying the aggregation that initially supports decision making, critical review finishes off the job.

- Under the umbrella presumption of their "experience", we should look to other people for both the content to aggregate and for the terms of a critique. The manager's challenge is to determine when and how.

In the end, cleared of hype, the business point of actually managing knowledge is to get beyond knowledge per se, and into an accountability of expectations.

It's also clear that management should set expectations of KM's deliverables accordingly.

Posted by Malcolm Ryder at 10:04 PM | Comments (0) | TrackBack

May 10, 2005

Alignment rap: Cats and Dogs, playing together, nicely

I'll leave these here just drying on the sun line instead of in the hot tumbler, until I need to use the clamps for something else.

Collaboration: two parties working concurrently on the same goal for the same reason.

Co-operation: two parties working concurrently on different things in the same place, compatibly.

So far, if you're a parent, you already knew those two were different. If you're not, you might have felt like arguing. Don't bother.

Correspondence: two parties knowingly and separately acting on the same thing, compatibly.

Corellation: two parties separately acting on different but interrelated things.

Coincidence: two parties acting on something at the same time or place, whether different "somethings" or not, but usually meaning on the same something.

And in the not-so-nice category:
Competition: two parties working on the same thing for different reasons.

Collision: two parties working on different things for different reasons in the same place at the same time, incompatibly.

Confusion: two parties thinking that each knows what the other one is doing but at least one of them being wrong at least at this place and/or time.

Corruption: two parties, where one party has the other party unknowingly doing the first party's work for the first party's reason.

Coercion: one party unwillingly doing the other party's work for the other party's reason.

Constipation: one party just not being able to get rid of the other party. :-O

Posted by Malcolm Ryder at 3:47 PM | Comments (0) | TrackBack

Much ado about Knowledge

Here's a riff about KM.

You have the hierarchy (bottom to top) of data-info-knowledge-wisdom.
Data+context = info
info+usage = knowledge
knowledge+history = wisdom

All four items in the hierarchy can be recorded, making them "content".

Every kind of this content has a lifecycle of:
-acquire (discover/create/buy)
-store (classify/format/save)
-deploy (publish)
-process (consume/transform)
etc.

Then the fun begins:
-what are the reasons for taking any action in any phase of the lifecycle of any kind of content?
-what are the restrictions for ditto...
-what are the rules...
-what are the requirements...

Why are those the reasons/restrictions/rules/requirements?
- authorization (by who)
- circumstances (where, when)
- benefits (and for whom)
- costs (and for whom)

Perhaps lastly you have the idiosyncratic stuff:
- expectations
- permissions
- quality

and those kind of things tend to determine whether behaviors with content get exercized, prioritized, banned, or whatever:
- sharing
- distribution
- licensing
- maintenance
- etc.

Now, in each of those groups of considerations above, think of every separate item as a possible term or factor or "feature" of a content package that party A can make available to party B. (Ignore that some of the features might be undesirable or irrelevant sometimes; they still have to be accounted for in production as being intentionally included or excluded.)

Next, work up all the feature permutations and price them. What's the "market" for each permutation (i.e., type of package)?

Then, if you think of yourself as the package provider, and you think of the start-to-finish provision of a package as a "made-to-order, from scratch" event, it's easy to imagine yourself quickly wondering "hmmm... how can I do this as a mass-customization gig, where my speed and cost and complexity is not pushed out of control by the unpredictability of the next order versus the previous one?"

In designing that thing, you'll clearly have to run the gauntlet of politics, property, ambiguity, and risks.

It's amazing how much knowledge it's going to take to manage knowledge!

Wherefore, my two impertinences of the day:
#1 - "When information is free, only bums will have information." (Original, thanks.)
#2 - "A fool with a tool is still a fool." (Borrowed that one.)

Don't let this happen to you!

Posted by Malcolm Ryder at 3:00 PM | Comments (0) | TrackBack

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 8:35 AM | Comments (0) | TrackBack

April 29, 2005

Performance, Success, and Strategy

Much of what will appear in this site's content pertains to an accepted or conventional use of the term "performance".

But in order to reinforce consistency in examining what "management" manages, it helps to distinguish between "performance" and "success". Here's a great definition of success ripped from Dictionary.com: The achievement of something desired, planned, or attempted. This definition makes it pretty easy to focus on the idea that a business has an ultimate measure (success) while it acknowledges variance in the effort to get there (performance). It also makes it easier to understand strategy as something that logically relates performance and success.

An immediate extension of this is the notion that "success management" and "performance management" are separated but related.

Success, represented by desired achievements, stages a level of further consideration that is mainly about determining whether goals should be reprioritized, retained, replaced, revised, etc. This has an obvious bearing on the idea that some success can pave the way for more success -- the ambition both of the business and of its stakeholders -- whether "more" means longevity or volume. Most importantly, it stresses attention on whether there is agreement or not between the business and its stakeholders on what goals are important at what time.

Performance, represented by the quality of the effort to succeed, becomes more obviously about improvement and about cause-and-effect. Here, emphasis on competency is the point. The notion of competency has a great precedent and use in legal and medical fields, where the meaning references the ability of a person to both spontaneously and consistently call upon relevant functions("faculties") in the face of demand for responsiveness. The most interesting observation about competency is that if the spontaneity and consistency are verified, the competency is validated even if it does not result in an advantage for the competent party. Parties that can stand trial or withstand surgery will not necessarily prevail, but incompetents will not be subjected to the stress of trial or surgery in the first place. Performance management understands that it can help the party "come through with flying colors" but acknowledge that the jury is still out and may finally come in with an undesirable outcome.

Strategy has the very interesting challenge of synchronizing available performance levels with currently prioritized goals. This responsibility makes it more obvious why risk management and change management are fundamental to strategy, along with scenario modeling and forecasting. Strategy can be prescriptively influential on both success and performance, but it cannot "cause" either of them. Instead, it gives a plausible argument for being able to establish, maintain and leverage the synchronization within certain ranges of certainty that include variation in both success management and performance management.

A final note on these distinctions is two-fold:
- first, the generic distinctions between success, performance and strategy apply whether the level of attention is enterprise-wide or task-wide; if on a given level all three things are not well-related, there may be little reason to believe that a higher level can depend on the lower one...
- And, in each of the three cases, the "management" discipline not only attends to a focal point (e.g., "competency") but also to the means for addressing that focal point.

As will be seen in lots of other content in this site, the above illustrates that the conventional concern about the gap between strategy and execution is really much easier to understand in terms of a gap between success and performance. To put a bighter light on the reality of this more precise difference, we only have to remember that in fact the "best" team does not always "win"...

Posted by Malcolm Ryder at 11:59 PM | Comments (0) | TrackBack

February 21, 2005

Models

Models show an inherent structure of an object, procedure or event, in a way that is intended to explain why the structure is viable for the purpose of the object, procedure or event; or, to demonstrate that a certain structure accounts for given expressed characteristics of the object, procedure or event.

The structure exhibited by the model always shows discrete components and relationships.

The definition of the components and relationships is a point of major difference between any two models that (otherwise) both intend to refer to the same object, procedure or event.

For the purpose of modelling, a "state" in the course of changing conditions can be treated as an event. This is especially helpful in describing "problems" with models.

Posted by Malcolm Ryder at 5:02 PM | Comments (0) | TrackBack