February 1, 2007

I.T. Without ITIL

The most exotic thing about information technology has always been terminology. It is the key to the scientific success of the field. But quite naturally, the complexity of the science also has meant that the terminology works steadily against any increase of ease in the field's practical management. More and more cats pop up that need to be herded. The net result -- a nightmare of semantics -- caused what the Gartner industry analysts noted over five years ago: the overwhelming majority of cost in I.T. comes from not technology complexity, but management complexity.

Perhaps that's why it is that in these last three years or so, the I.T. Infrastructure Library, or ITIL as it is commonly now known, gained traction with the kind of momentum carrying an industry standard. ITIL describes a huge range of management processes using a vocabulary of enormous logical consistency, which can make the semantics of management suddenly unambiguous despite IT's complexity.

At the same time, the sheer scope of ITIL is fear-inducing. Many of those who would use it fall into one of two groups: those who look for evidence that there is actual practical import to sticking the toe in the bathwater; or, those who religiously convert. Analysts like Forrester Research say that the former group is about 60% of the gang, while about 10% are fully pious and immersed, leaving the rest either just thinking it over or dabbling.

On the spectrum between the larger and smaller group, the larger keeps its practitioners cordoned off (but not quarantined) in a swim lane... handling the semantics of ITIL as another special expertise hoped to achieve some natural ascendency, the same way an innovation outstrips or obsoletes legacies. The smaller "immersion" group swims the rough open waters of large-scale revolutionary change in culture. Because ITIL is primarily documentation, there is not a real threat that either approach will alter it's ability to provide consistent guidance. But giving good advice is not the same as causing it to be followed. The top obstacle to following ITIL, ironically, is still confusion. Why is this the case? Simply put, corporate IT groups are forced to move at a pace that is much faster than their ability to absorb ITIL, and they are loathe to risk, much less give up, hard-won benefits from pre-ITIL practices. Yet behind those benefits, they often don't have an effective overview of where they already are. Thus, following along ITIL's paths, they constantly run into forks in the road that don't offer the obvious correct choice. Net: ITIL is a maze.To get over this hump, they still need a way to see, in short order, how they can connect the dots between their current practices and ITIL's.

Following suit, the perspective represented in the picture below simplifies the identification of the pre-ITIL circumstances, locating the starting line for a move to ITIL without the threats of disruption or of time running out.

The key assumptions in this picture are as follows.

First, no one really cares about I.T. except for whether it is perceived and proved to be useful.
Second, there are only two major points of view on that utility: the lifecycle of items composing the IT infrastructure; and, the production that composes IT operations.
Third, all of the IT management, whether in infrastructure or in operations, is essentially about two things: how things are (i.e., states), and how things happen (i.e., transactions).
Those three assumptions, when aligned as shown, organize every critical aspect of driving value from IT utilization. From this point, the rest is a matter of additional levels of detail.

Since management is popularly understood to be impossible without measurement, and since measurement can't happen without semantics, it is hugely important that the perspective drawn so far does not rely on confusing semantics and meanwhile shows analysis as an ordinary, not exotic, activity covering the field.

Within the general framework, four main phenomena surface as the major management subjects. Driving these down into daily practices makes sense under the assumption that the point of the practices is to establish value in the utilization of the info technology involved.

The utilization is established on two fronts. One is to give form to the actual information technology that users can ultimately access and exploit; this is what is called "IT Services". The other is to give form to the mechanism that creates and sustains that access and exploitation; this is what is called "Support Services".

In an unconventional but easily proved distinction, IT Services is about the provision of the IT configurations; whereas, Support Services is about linking the IT to usage requirements, as systems for use. (These systems are essentially and primarily logical, and secondarily take on physical form as the peculiarities of the company hosting them might allow them to at any time.) Usually, in effect, it's the difference between supply and demand, between service level management and service level agreement, and so forth.

As seen in the picture, the two kinds of services cover (i.e., attend to) the four major subjects in a certain way.The types of services relate to each other because they work on the same subjects. But the services differ from each other in what it is about the subjects that are the key points of their respective concern and influence. These key points are added into the framework's quadrants to clarify the high-level of analytic detail that really matters for the services. This level of detail is the one that initially accounts for the co-existence and co-influence of the two generic types of services (IT and Support).

For followers of ITIL: the difference between IT Service and Support Service is not indicated in the normal ITIL vocabulary. Instead, the generic concept of "management processes" proxies Support services that bring IT services to the user or customer. ITIL largely provides a taxonomy of those management processes, and most observers first engage the taxonomy of "delivering" IT Services (defining and developing them) versus "supporting" IT Services (maintaining and optimizing them). But at least half of the trick in adopting ITIL is to orchestrate its management processes into standing "Support Services" as described in this discussion's framework, which is oriented towards managing the value of utilization.

Posted by Malcolm Ryder at 4:50 AM | Comments (0)

January 21, 2007

ROI and The Rush Job

or, The Productivity of Production

Years ago, the only way to get custom-printed photos on a rush basis was either with a LOT of money -- or NOT a lot, through a pretty darn good photographer friend, emphasis on the friend. Smelling an opportunity, and not pld enough to eschew self-abuse, I broke into a really crowded field of commercial photographers by offering the unthinkable: "fast, cheap, or pretty: pick any three." For six months, I didn't charge premium or "rush" prices: I just didn't sleep, and I custom-printed photos for delivery by rush deadlines.

Don't try this trick at home! It jump-started my business, but the six months cost me a couple of years of longevity that Science says I won't get back. A negative ROI. In general, production organizations know this could happen to them, too, and they sanely stick to the rules: "fast, cheap or pretty; pick any TWO."

The problem is that customers sometimes don't care about the rules, especially if the customers hold the production organization captive. A typical example of this is an IT organization in a corporate setting. Although it seems irrational, IT routinely has to solve the dilemma of offering all three outcomes.

Susan Conway, in her article Keeping the Think Factory Humming in Optimize Magazine's January issue, actually offers a fairly straightforward idea -- that getting cheaper (through tools) allows more effort to getting faster (reducing cycle time) and thus becoming prettier (through enabling continuous improvement of quality). Running in that direction, from tools up to quality, there is an increasing "enablement" applied layer after layer to the circumstances that must generate value from production.

Although she calls that value "efficiency", it is both more than and different from that; and the deceptive linearity of her run-up doesn't point at how those layers, or links in the chain, actually get connected: namely, simultaneously, not sequentially. It's not the "links" themselves that make the difference, it's the connections between them that do -- the linkage.

For clarifying why this is true, an important reference to have is Goldratt's Theory of Constraints -- in which the notion of a weak link is explored as an effect, not as a cause. We make the link weak by what we do around it; it is not inherently so. Likewise, we make the link stronger. This prevents us from taking the "linking" effort for granted. More to my point, it calls out the simultaneity that must be addressed: all the links matter at the same time...

Let's take that idea to heart. As a producer, how do you do Fast, Cheap and Pretty all at once?

We might make a new Pontiac Solstice, which shows that it can be done. But the usual situation is that each target characteristic can influence the production differently and even dominantly versus the others; so it matters that we know what their co-existence really demands.

Typically, we feel that we already know what each individual characteristic is about, but how about their combinations?

For example, what's an exemplary instance of Fast plus Pretty? How about Muhammed Ali's left jab. Effectiveness, wrought from precision, which was wrought from discipline, which was wrought from training. It's the precision that is its key distinction -- the organizing principle that creates the linkage, and its value, between Fast and Pretty.

And away we go:

Fast + Pretty? the left jab. Precision is the secret. Relies on discipline (from the training).

Pretty + Cheap? the sari. Elegance is the result. Exploits pattern (from the technique for folding or wrapping).

Cheap + Fast? the omelette. Balanced to the occasion. Leverages the facility (of a standing "factory" -- the hot skillet).

In other words, if we knew we needed both fast and pretty, "precision" is a good aspect to pursue, and to get there, we're going to need the discipline of having been trained into consistency. And whether wrapping a sari, or doing math equations or calligraphy, the elegance of "less is more" relies on drawing the optimal pattern through technique. What about that omelette? Balanced, neither too much nor not enough for the appetite, you grow it quickly from very little, on the already hot pan. While that pan is hot, you just keep crankin' 'em out.

But back to bigger work, what is production up against? The point is to get one deliverable from combining all three characteristics. Like that incredible car from Pontiac. The prerequisite is you'll have to be organized to pull it off.

This illustration calls out the three key constraints in managing the connections of the production -- design, controls, and sources. They are fit and related amongst the initial objectives to be met.

For example, when we talk about "sourcing", we're concerned with the scale of production that we need from the process, and how much that is going to cost. We'll source production from a factory that gives us the desired economy of scale from its process.

The model also looks more directly at what we think each initial characteristic feature is, here more carefully identified. For example, "pretty" typically means that the production output has high compliance to specifications. Or when we say "fast", what we're usually talking about is how quickly the product can be provided every time it is requested.

And earlier, the path to noticing standardization was from training that creates "discipline". But now that we've noticed standardization and its place as a principle, we can recognize and include other key influences that are related to it, such as policies.

Pulling these constraints and principles more to the foreground, the following picture shows how Archestra's ActiveROI model similarly organizes management in IT production organizations to drive productivity for the business it supports. As seen here, ActiveROI describes the systemic relationship of the constraints of design, controls and sources through implementation of architecture (design), portfolios (sources), and policies (controls). Investing in this systemic management practice puts the organization on the footing for not just efficiency (a small piece of the puzzle) but for holistic generation of business value.

[See more on ActiveROI by searching Archestra. ActiveROI, originated by Malcolm Ryder and commercially developed at Renovance LLP, pops up in various disguises in your Google or Yahoo search results, but it should not be confused with marketing companies, other persons, or machine intelligence projects that like the name so much they use it too. For updates to the model, and for a list of its authorized promoters, search the Archestra archives exclusively, and/or contact M. Ryder at Archestra.]

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

June 19, 2005

Evaluation versus Value

Evaluation closes the loop of management activity that begins with idea definition and continues through design, implementation, operation and support.

Following and actually overlapping "support", "evaluation" determines when the effects of operation are complying with initial standards and objectives, and whether the effects are compatible with requirements that have emerged and become newly current during the elapsed time of the idea's actualization and employment.

For managers, that current compliance and future compatibility mean something primarily because of the initial justification for the idea being actualized. This justification is often simply called the "baseline", and one of the primary goals of evaluation is to generate information that supports decisions about how to respond to changes from the baseline. As a result, performance information feeds change management to protect value.

Normally, the justification is a description of "value" to be gained by realizing the idea. Compliance will mean that the terms of the original justification are being met, but compatibility to new requirements means that expectations about future value are still reasonably positive.

An evaluation that cannot include both perspectives -- that is, of original and current expectations -- is at least incomplete, if not downright suspect. For example:
- an evaluation based only on the (earlier) original expectations might describe work done properly to produce something whose intended impact is no longer possible or relevant by the time it is actually delivered.
- an evaluation based only on current expectations, ignoring the previous forethought behind how the current conditions developed, might mistake a presently mismatched organizational stance towards requirements for a lack of capabilities instead of a lack of direction.

Another problem in evaluations is confusion about what approach yields information of the right type of importance. For example, these three following approaches are distinctive enough in purpose and capability; they can and should be complementary but are unlikely to successfully do each other's job:

Assessment - a determination of what kind of value should be associated with something, not just how much something is worth. In determining what kind of value, the assessment process examines how something actually creates value, and/or how it fails to do so.

Measurement - a determination of the degree to which something has a given quality or property.

Analysis - a determination of something's constituent parts and especially their inter-relationships, explaining a particular characteristic of something.

As an example of why these must be correctly used, look at the common need that organizations have to conduct performance assessments, performance measurements, and performance analyses. Casual conversation might use these three terms interchangeably, but in actual practice they will not correctly provide the necessary decision support if misused.

A performance assessment should investigate, and report on, the likelihood that an operation can meet the demands of given types of requirements. Along with this, but regardless of what current requirements are the established ones of record, a performance assessment should expose what types of requirements the operation is most likely constitutionally fit to meet, based on knowledge about how such requirement types have been successfully met in the past. This is usually where notions such as best practices are referenced.

A performance measurement should investigate and report on what level of compliance the operation has achieved regarding specified target levels of impact for certain types of impact. Typically, benchmarks are referenced in measurements instead of elsewhere.

A performance analysis should investigate and report on why measurable performance levels have occurred, regardless of what the measured levels are; then based on the reasons why, the analysis should predict the levels and types of performance that are most likely from the same dynamics. Forecasting is usually expected here.

However, the three approaches are complementary:
- Assessments and Measurements can share categories
- Measurements and Analyses can share data
- Analyses and Assessments can share models in common.

Taken together, the three approaches provide a complete reference for describing the relationship of operational effects to the objectives that for managers represent creation of value.

A full evaluation that includes assessment, measurement and analysis will give a description that traces the logic of what is actually happening in a way that accounts for expectations. In that way, managerially practical comparison of original expectations to current expectations should be possible, identifying the underlying conditions that are shaping or being shaped by operations.

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

May 26, 2005

Business Process Management and Organizational Architecture: a performance ecology

This month, Gartner Group research chief Peter Sondergaard outlined the top emerging issues in Business-IT management, by identifying the already driving needs to:
"...foster greater business agility, to promote quick build-up and tear-down of business partnerships, to facilitate adjustment and deployment of resources where needed and to render harmless approaching danger well in advance of that danger's arrival," Sondergaard said.

We're accustomed already to the idea that processes must be readily modifiable to keep up with changes and risks. But a closer study of Sondergaard's statements yields two other survival requirements:

(1) repositioning and security capabilities: this will require a mature "sense-and-response" ability that exploits forecasting.

(2) re-organization capabilities: this will require a mature ability to "re-compose" the organization by exploiting a model of it components.

In a nutshell, a form of organizational architecture must drive suitable types of readiness.

Meanwhile, business processes will remain the delivery vehicle for the operational impact that creates business value. To users of a process, the process is virtually the organization... But forecasting and organizational modeling determine whether the business process executes effectively -- that is, in the right direction and at the right strength.

Said differently, processes execute with critical "ecological" dependencies on their environment.

This dependency can be described from two viewpoints. In one, any process is essentially a "behavior" of the organization that enacts it. In the other, the process is a "user" of the organization that hosts it. Either way, to modify a process and obtain effectiveness, the organization that enables the process must successfully adapt as well. The issue is to determine the nature of the necessary adaptation. Is it repositioning, reorganization, training/maturation, or a blend?

The more frequently or continuously processes must be changed to meet requirements, the more explicit it is that the logical purpose of a process is to "map" the current requirements to the current functional capacity of the organization. In this view, "successfully" adapting a process to changing requirements means that changes of the underlying organizational structure must keep up with or even precede changes of the process. (The lessons we have already learned about mapping requirements to organizations come from project management and product management, where the organizations are often shaped and managed specifically to conform to fulfillment of the new requirements.)

Here, it is important to see organizational "structure" as a configuration of functional capacity. The purpose of the organizational structure is to deliver the capacity, and the purpose of the process is to leverage the capacity.

Usually, the chosen configuration will be selected according to criteria of cost, risk, availability, scale, stability and durability. But those attributes really describe outcomes of the organization-in-use, as enabled by the interactions of its elements. To recombine the elements and predictably obtain the same (or acceptable) attributes, the elements must be identified in terms of the properties they are known to exhibit in interactions.

In powering business agility, forecasting and modeling are both going to be based on those interactive properties of the elements, which comprise the business' operating environment.

Organizational building blocks

The type of understanding that will exploit elements defined this way is akin to both chemistry and meteorology.

Chemistry is an especially compelling metaphor: we already recognize that preparing a chemical "reaction" is precisely how we proactively develop the solution impact that we seek. It emphasizes that the structure (i.e., the chemical composition, the "organization") hosting the reaction is the driver of the reaction, containing within itself the potential and also sometimes the catalyst. Accordingly, the prescriptions that are developed by a chemist reference what is known about the interactions of the chemical elements, to compose the offering. Similarly, we are entering an era that calls for organizational composers, working with or without automated help...

Meteorology is also a compelling metaphor because of its constant analysis of the environmental dynamics. Meteorological analysis accomplishes tasks by means such as distinguishing weather "elements" from weather "factors", by determining what underlying elements are interacting, and tracking how they are interacting when certain dynamics occur. The interactions of elements are factors; factors combine to produce dynamics; and systems of dynamics produce the common high-level weather structures.

Abstracting the components of an environment or state such as the weather, we might identify:
- Structure: a seasonal climate
- Dynamics: a rainstorm, tornado, wind current, etc.
- Factors: a high-pressure system, cold front, etc.
- Elements: air, water, heat, etc.
Although we still can't control the weather based on what we know about it, we understand much about the near future weather because this analytic discipline helps us to model it and forecast it in advance.

Decomposing a business's internal organization this way, the business can then plan for the organization's states or behavior just as we might plan for the weather's, and exploit reorganization. Likewise, decomposing the external environment of the business helps with making decisions about where and when we can best "locate" ourselves to accomplish what we need or want, repositioning as needed.

Process architecture

Linking elements to factors to dynamics to structures is an abstract design technique. It can produce architectural models that are:
- the prescriptive composition of the business organization; this addresses the need for a re-organization capability
- the projected state of a business environment; this supports a repositioning capability.

Here is a diagram about composing an organization:

The picture gives an example of the many-to-many relationships that build up an organization, from assets to resources and so on.

In effect, a running business process issues requests that must intelligently "invoke" a certain configuration of these relationships during run-time.

The "intelligence" includes rules, permissions, and qualifications of various kinds. At run-time, if new items have entered the picture or earlier ones have changed or left, some of these rules, permissions and qualifications might need to be discovered on the fly, to assess and accomodate the differences from expectations.

The same approach can describe external environments as well as internal organizations; for example, a market space might be decomposed into:
- (structure) channels and partnerships
- (dynamics) campaigns and contracts
- (factors) products and services
- (elements) features and property

This market decomposition would exhibit the same many-to-many relationships of one tier's items to the next tier, whether going up the hierarchy or down.

Process-driven architecture

Leveraging that architecture, a business process requests a real-time configuration of an organization. The process always anticipates the potential for effectively exploiting the organization to meet the expected current or future state. But that anticipation is not always satisfied.

As business process management(BPM) increasingly centers itself around a business analyst role (performed by a manager or other employee) and expands that role across functions, it also extends itself into a request-management function that wants to ensure the satisfaction of the request with available and approved resources.

The key challenge in the request management effort is to determine whether the request can be satisfied through an existing organization or must be through a "reorganization" that makes acceptable resources available. The challenge for the analyst is to get the process to make the optimal number and type of requests in the available environments.

If a reorganization is suggested, it is likely not permitted until the request has been assigned a priority that effectively authorizes the reorganization for the request. (This prioritization typically comes from strategy and performance management.)

In this scenario, "orchestrating" resources brings selected factors into play, enabling the dynamics that a process attempts to manage. The orchestration is the virtual real-time organization. In effect, the organization becomes a resource agent for the process. And that orchestration comes with scale and scope issues that must be assessed for their implications in cost, risk, stability, duration, etc.

Which came first: the chicken or the egg?

BPM is evolving (expanding)into a complex of practices within which the design of the process prescribes a solution for the delivery of business outputs, and that prescription requests a fulfillment through organizational functions.

In that way we can say that the targeted process catalyzes the organization. But at the same time, those prescriptions are speculative without knowledge of the organizational potentials, and speculation is a risk to business efficiency and effectiveness.

Necessarily, the attending organization may be a "just-in-time" organization derived through bidding, collaboration, or the standing availability of a qualified outfit (whether internal or external).

What's especially important to note is that the criteria for selecting or composing the organization should effectively function as architectural standards looking for compliance by the actual organization that winds up engaged with the process.

These ersatz standards must be validated against evidence of the business' tolerance for them. We can't always get what we ask for, and we have to be careful because we might get it!

Why "architectural"... ?

By demanding certain combinations of cost, scale, scope and duration, the criteria effectively specify what capacity can be expected from given organizational (structural)configurations. The business must agree to those expectations, or seek sufficient capacity through whatever means available. The issue is whether the specification is too constraining or not.

In that way we see that architecture is actually what is being exercized. Far better that this is understood from the start than to encounter it as a barrier. The challenge is to apply architectural discipline proactively, yet in a manner that is calculated to maximize the ability of processes to obtain the organization that they need on demand.

Posted by Malcolm Ryder at 9:25 AM | Comments (0) | TrackBack

May 25, 2005

Data, Dictionaries, and Organizational Performance Alignment

Engineering is often where we find crisp statements of problems and solution-approaches that are already pretty far along but may not have found their way to routine use in a more general population of managers.

An example of this is from a BMC Corporation technical whitepaper that stated the following: Nowadays each IT infrastructure component has its own language or dialect when communicating with the outside world. This makes it extremely difficult to derive and understand the impact certain events or combinations of events have on the business. BMC is, shall we say, very much "on the case" in creating a system for more uniform identification of components-in-deployment.

Not coincidentally, this same type of problem is cited quite explicitly by at least two other sources of tremendous import to performance management -- the Zachman Framework (for enterprise architecture) and the IT Infrastructure Library a.k.a. ITIL (for IT service management). Both Zachman and ITIL go on to provide a logical framework of how the semantics and syntax of an organization allow efficient and effective construction of complex functional products.

The online Wiktionary offers the following explanations:
Semantics - the science of the meaning of "words"...
Syntax - A set of rules that govern how "words" are combined to form "phrases" and "sentences" ...

These definitions literally look at communications as a construction process, with the quality of the output being at stake. But what Zachman, ITIL and other development aides take from that is a way of looking at construction as a communications process.

Why is this meaningful instead of just a handy twist of phrase?

Performance Legos

First, items like words, sentences, etc. all point to "information", which we use as a construction material in the business.

Second, when complex constructions require that "components" are developed and integrated to make higher-level "subsystems", then the functional compatibility of the components becomes the primary goal of managing their development and provision.

Altogether, that throws focus on how information itself is developed, and thus on how that information development effort is managed.

The objective of that management effort is to assure that the quality of the construction process minimizes the risk that its "product" will fail to meet its requirements. The development process must create components that support the construction process.

For business purposes, the management effort for information has at least two major issues:
- how does the information have meaning (semantics), and
- how are the meanings combined for practical use (syntax)?

What makes information usage practical?

First, "information" is itself a component of the business because it is used to create, for example, "processes" and/or "workflow" -- in other words, subsystems of the business.

Second, "business" information describes the characteristics of the business itself. Successful identification of a business entity, condition or characteristic is fundamental to the point of the info's usage.

Practically speaking, the information is usable only when the user understands the information's way of providing identification. The semantics always come first. The biggest challenge in transporting information across a progression of different users is the risk of the semantics being lost along the way. This is not a matter of "what" something means but instead a problem of "how" it comes to mean what it is supposed to mean.

Here, Wiktionary again is convenient. It offers the following:

Protocol - A rule which guides how an activity should be performed.
Context - the circumstances or settings which determine, specify, or clarify the meaning of an event.

Interestingly, this suggests that business terminology probably should be managed as a thesaurus, and that business information should primarily be managed as terms of requirements and agreement (i.e., specifications).

Construction quality as a performance factor

Communications protocol comes to the foreground as the mechanism by which the business constructs its understanding of where it is and how it is doing.
- Protocol represents the quality requirements issued to those activities that construct and convey meaning across the enterprise.
- The organization uses those meanings to determine and drive performance.
- The mechanism for utilization is the problem that the organization (and solution providers) must solve.

Decision support as an organizational constructor

Let's go back to the original issue at hand, which is to "derive and understand the impact certain events or combinations of events have on the business."

Decisions shouldn't be made without having that understanding in hand. But naturally, recognizing events must precede any determination of their impact.

Of course, decisions don't just make themselves. The organization makes decisions -- including the ones that change the organization. So we have two additional things to consider here.

First, from the vast universe of business data, what are the essential classes of information to derive -- for example, "entities", "events", "impacts", and so forth... And second, to what extent does our idea of "the organization" rely on demonstrated usage of this information instead of on prefabricated boundaries (silos) of data ownership and custodianship?

Does the organization define itself by the way it actually uses information, or instead by what it thinks it should "know"?

The emerging consensus is that what distinguishes high-performance businesses from lesser ones is their smarts in the midst of environmental change; but therefore, information usage must drive the business and the "organization" should conform to the necessity of making information useful. This spawns a couple of giant trends in organizational management: standardization of operating language and automation of decision support -- or put differently, vocabulary and analytics.

Together, the two trends do nothing less than attempt to reconstruct the organization.

The off-hand expectation would be that a standardized vocabulary should make analysis easier, since the terms in the analyses wuold be more efficiently validated and transmitted. For this, we would be looking for a new and improved "dictionary".

But organizations can certainly fail faster when they try to replace the need for communication with analysis. If they had to have one without the other, communication should win every time. And dictionaries don't make communication successful: protocol does.

In what follows, we'll go through the key points of this graphic:

The use and abuse of "universal vocabularies" and "analytics"

Let's use ITIL as a case where a better single dictionary, in fact a great one, is available and necessary -- but insufficient.

Many IT organizations are attempting to implement quality improvement initiatives aimed at their service management processes. Taking ITIL as a guide, standardization of vocabulary is a strategically critical dimension of their efforts. IT organization leaders realize, both instinctively and empirically, that the standardization will be disruptive to a significant degree, as adoption of the standards must run through the current configuration and linkage of most people and systems in the IT organization. The expectation, however, is that the resulting changed organization will be leaner, faster and more powerful as a services provider.

In a recent article, Pennsylvania consultant David Pultorak, president of Fox IT, provided the following citation:
Organizations implementing ITIL saw the following benefits:
according to a 2003 itSMF survey...
- Improved customer satisfaction
- Motivated staff and increased productivity
and according to a 2002 survey by DMR...
- More consistently implemented changes
- Reduced repetitive problems
- Reduced amount of time spent "firefighting"
- Produced more business-focused metrics

These outcomes are highly worthy goals. How were they reached?

ITIL's intended impact, on the capability to manage IT services to high levels of business value, is promoted primarily through improvement in management processes. That improvement is heavily predicated on the standardized vocabulary for identifying actions, conditions and events. With ITIL, one management process can more readily understand another management process, making their interactions more dependable and predictable.

But finally, a successful "ITIL implementation" requires (and means) that the organization has adapted itself to be a suitable and healthy host for the management processes and for their integration.

Success rates with ITIL implementations might always be measured in terms of goals such as above, but ITIL implementation failures are most often discussed in terms of being overwhelmed by the difficultes of adaptation. Organizational change management discplines emphasize that adaptation should be both strategic and evolutionary, so we assume that the "successful" implementations will actually exhibit accomplishments that are both strategic and phased.

Does this mean that in successful implementations, the vocabulary standardization was incomplete at various points along the way? If we look at ITIL consultants' frequent references to capability maturity models, the answer is evidently "it depends". If "process improvement" was intermittently verified, and IT organizational performance was also measured trending up, the real situation is that the terms of measurement allowed the evaluation outcome to be positive. This suggests that a certain amount of the process vocabulary was identified for inclusion in the implementation, and that somehow it translated into business vocabulary, "completely enough" to support definitive assessments.

But how did that those assessments take place? Measurement puts vocabulary to the ultimate test. Even with ITIL's dictionary, processes can improve in quality independently of the change in their business impact. Why? Because process utilization is by choice. At first, the impact of a new process may be mainly a reflection of the degree to which the process is used effectively, regardless of its inherent quality. So if process quality does not equate to business quality, what vocabulary is universally applicable? This is the issue.

A business communications protocol

Standardized process terminology can be quite different from process information. Terminology that helps to conduct the process may describe the integrity of the process without describing the impact of the process. This is likely the terminology in a model.

Process information, on the other hand, should describe the availability and relevance of the process to participate as a component in the business operations. Standardized process information would concentrate on bringing consistency to describing availability and relevance. This kind of information might be found in a catalog or registry.

As identified earlier, business terminology, managed with a thesaurus, should allow observations to cross contexts without losing their meaning. Attaching certain perspectives to terminology, the thesaurus provides "persistence", yet not rigidity, in the ways that business operations are observed.

And finally, business information should supply the description of impacts, risks, benefits, goals, and other value judgements that distinguish the state of the business from one situation to another. The most prevalent example of this is a contract.

Deriving "business intelligence" from business communications

As shown in the graphic above, these four approaches in protocol anchor the development of certain types of communications, to which numerous business roles can subscribe without fear of confusion. Thereafter, business performance analysis mainly relies on integrating the different types of understanding derived through the protocol, not on integrating the data.

The conceptual integration of those different kinds of understanding will require models of operation and models of performance that define the chains or networks of influence expected amongst the associations of actions, events and states. But it is higher-level frameworks that provide the mechanism for identifying the actions, events and states which need to be observed in order to build the models.

Since most performance measurement analyzes compliance to existing models, the initial frameworks actually lay out the "foundations" for the business analysis as well. Business vocabulary should therefore concentrate on the frameworks, first.

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

May 9, 2005

Returning to Return on Investment

Not being an economist or statistician has its small virtues when talking about value. One of the best virtues is an undaunted respect for the ability to say that something is valuable without needing to qualify it other than logically. This is what I've always thought of as the difference between ratings and metrics. Both are cases of "measurement", but a metric needs a standardized rule and a rating only needs a non-standardized preference.

So who cares about this? People who like gift boxes full of ROI. They don't like ratings when what they want is metrics.

It seems to me, though, that the point of ROI metrics is still to wind up with a preference, namely, to have a certain amount of value of a certain kind, above and beyond what value you think you gave up (i.e., invested) in exchange.

This makes it easy to lean on a logical definition of ROI instead of necessarily a mathematical one. That is, where does ROI actually come from?

If there is some kind of property for which you have "ownership rights", you can treat that property as an asset. Once you give the asset a job, then you can treat it as a resource. This assignment is also the point where you can first say that you've made a specific investment.

The purpose of the resource is the next important issue. The purpose is all about what yield should be obtained from the utilization of the resource. The yield represents the type of benefit targeted.

But the yield is valuable only due to the event that it can address. The event is a type of condition that the benefit can affect. The effect that the benefit has in the occasion of its influence is the return.

For example, let's say that there is a rusty chest believed to contain important memorabilia and some expensive antiques. If someone gives me ten dollars with permission to use it, I virtually own the ten dollars (an asset). If I spend the ten dollars on a hammer, I've created a resource (the hammer). Then I use the hammer to open the rusty chest (a benefit), with the understanding that I'll be rewarded for opening the chest. The reward can be 20 dollars for getting the chest open, or ownership of the contents of the chest. The value of the contents of the chest is monetarily (we presume) either greater than the original ten dollars or not, but at this point the issue is the importance of the kind of value that the contents have for me. Would I rather have the contents, or have the ten dollars back with ten more to spare?

This simple example shows that the "ROI mechanism" is to:
- create a resource from an asset, then
- use the resource to create a benefit, and then
- offer to redeem the benefit to gain new value, and finally
- select the type of value to accept in ultimate exchange.

Logically this would always be the pattern. Circumstantially, meaning in any given instance, you may not have many choices in the amounts, types or occasions involved in the mechanism, and this might make the whole affair seem to involve fewer steps and options. For example we often automatically think of an asset as a resource because we think of assigning the asset to only one purpose (even though it could be assigned to a different one). Or we don't seem to have choices of rewards so we think of the benefit as automatically provoking a certain kind of value, which makes the benefit and the value synonymous.

Experience shows that these "abbreviations" are ideas that we choose to have instead of facts. The logical facts allow for circumstances where the number of options at any step is somewhere between zero and more than zero, but the step is still always a part of the mechanism. We might not be aware of it until someone comes into the picture with a different agenda and an ability to add or subtract options from a step. For example: you can typically do that with "efficiency measures" (subtractions) or "contracts" (additions).

People like to "maximize ROI" and they may have various reasons (or requirements) to do so. The ROI mechanism just described also shows, perhaps more importantly, that there are a number of points at which decisions might be made to adjust the effectiveness of pursuing a desired return. It also shows a mechanism that can take only minutes or might take years. The difference is in the details of executing each step, and in the progress made to align each step with its subsequent one. In the Archestra view, this is the basis of the need for what we call "ActiveROI".

For more info on the illustration below, contact me via email...

Copyright 2004 M. Ryder

Posted by Malcolm Ryder at 1:20 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 22, 2005

Managing Strategy versus managing Performance

For the most part, recent consensus on the state of business health includes two interesting headlines. One is that business competitiveness now requires "growth", which in turn requires moves that go beyond cost-cutting. Another is that effectiveness requires "alignment", which in turn requires moves that go beyond efficiency.

In the new era of growth and alignment, the old business platform of economy and efficiency is now mainly a staging area in which processes are designed, or repaired, or re-designed. There can be no doubt that every business must design there, but as we also see in the current consensus, the new criterion thrown into the mix is change. This ingredient pushes all resource management (whether of processes, people or technology) up against the challenges of agility and renewal -- both challenges pressed upon the business by operating environments that are increasingly independent of any given business.

In fact, to secure the business's ability to be responsive to the right things at the right times and thereby consistently exchange value offered for more value gained, the business now must concentrate more than ever on relationship management. Through collaborations and partnerships (both internal and external to the company), relationships bring the business earlier alerts, economies of scope, and a broader range of available resources -- on demand. Thus the business has greater means to assure itself the right positions, on time.

However, exploiting the positions is what causes a payoff -- and another current general consensus is that companies do not so much fail to have viable positions as they do fail to execute from them.

This notion, which argues that most companies have a strategy but fail to execute it well, points us at the idea that performance should be seen mainly as successful execution of strategy.

Ironically, the other big story that managers are hearing is about how companies that successfully execute poor strategies would actually "outperform" companies that have great strategies poorly executed. This story clearly equates performance with results. But it does not usually drill down into whether the sustainability of that output is likely or is even relevant to the foreseable future. In effect, it is a disposal definition of performance.

As a kind of advice, the story is appealing in a comforting, common sense way, as if to say "perfect is the enemy of good enough!" This advice is just great, as long as whatever strategy is being used really will likely tap into significant levels of opportunity even if it is poorly conceived. Executives who are betting your careers on that, please raise your hands.

So how does the idea of "successful execution" of strategy actually net out? Is the point of strategy simply to get organizations on a productive path but then step aside? Or does strategy just "pan filter" the range of execution's results for the results that it wants? Or is it that the competitors that really matter are just not different enough to require a strategy above and beyond superior execution?

Our problem is to understand what strategy really has to do with results, and how that connection works. The underwhelming answers just described above can be reached by at least three paths of confusion, each of which should be avoided...

#1 - "Execution" is thought of as just a synonym for operation (i.e., thought of as procedure, instead of as actions continuously negotiated between options and risks).
#2 - No distinction is understood between tactics (securing opportunity)and strategy (creating opportunity).
#3 - Short term results are not examined in the context of long-term value, so they are not asked to contribute to it.

The Management Framework
To dispel this confusion, a couple of "management" definitions of strategy and performance allow a better perspective on the issue and provide consistent connections of strategy and performance to growth and alignment.

- Strategy is about the value of the direction chosen. Essentially, strategy selects positions oriented towards a selected goal.
- Performance is about the quality of the effort made to go that direction. Essentially, performance selects ways to get and use the positions established by strategy.

The key to this vocabulary and point of view is recognition that both strategy and performance start out in management's mind as projections, as models of possible futures, not as assessments of the past. From the models, plans are developed to link the models to the specific organization. Then the plans are used to both steer and evaluate the ongoing "actuals" versus the models.

Again, strategy and performance are both aspects on a planning axis; typically, given the usual level of internal and external business complexities, most organizations will not approach projected strategy or performance targets except by working to realize the plan.

On another axis, growth and alignment are both aspects of execution.
- How is growth pertinent? Primarily, growth is meaningful when it is increased capacity that is effectively applied to opportunity.
- How is alignment pertinent? Alignment is meaningful when it is increased coordination that raises the certainty of operations meeting requirements.

Given that, it's fair to assume that all companies want to enhance growth and alignment -- in other words, they want to accomplish both growth and alignment in a way that makes the two things valuable. But even if they don't immediately accompish those things, they want valuable results from their ongoing efforts, which means organizing activity for meaningful, incremental deliveries of value.

This brings us to a clarified distinction of what it means to manage strategy and to manage performance.

By understanding that execution must be concerned with supporting growth and alignment as success factors and not just with outputs, we see that the manager's primary responsibility is not simple procedural adherence to plans, but rather that "realizing" the plan should be continuously pursued in terms of whether intermittent activity and outcomes are consistent with the goal of growth and alignment.

In both the cases of strategy and performance, managers need to bring execution capabilities to the plans. Synchronizing those capabilities with the needs of the current plan is a manager's highest priority. By making change more manageable and therefore increasing the organization's accommodation of new plans, capacity and coordination (respectively, elements of growth and alignment) characterize the key approach to optimizing the potential of strategies and performance. Because capacity and coordination are literally provided through the makeup of the organization, this point of view explains the connection between organizational development and results.

Consistent with the working definitions established so far, we can now use typical management terms to map out the synchronization described above...

STRATEGY:
- growth intersects strategy in objectives.
- Similarly, alignment intersects strategy in priorities.

Strategy management primarily attends to objectives and priorities -- conceiving, communicating, tracking, supporting, evaluating and adjusting them -- such that they nurture and leverage growth and alignment, respectively.

Applying that same cycle of attention (i.e.,conception through adjustment), performance management addresses performance's intersection points with growth and alignment.

PERFORMANCE:
- initiatives nurture and leverage growth; while
- tactics nurture and leverage alignment.

Thereafter, with initiatives and tactics supporting objectives and priorities, management negotiates results. This understanding replaces the ambiguous notion of "executing strategy" with something that all managers can directly and rationally engage.

Posted by Malcolm Ryder at 1:45 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

February 19, 2005

Archestra Projects

Archestra projects basically catalog individual and collaborative efforts to add to the Framework depth and integrity in any of the following ways:

(a.) identify or propose a new structural component of a relationship in the Framework;
(b.) adjust and validate components and relationships for their integrity;
(c.) demonstrate a method for "managing" development of a component or relationship - including to define, discover, make, test, scale, position, measure, change or delete;
(d.) demonstrate similarities, affinities or integrations between the Framework and other frameworks, models and literatures;
(e.) apply the Framework to designated problems in enterprise strategy, resulting in documented application hypotheses, methodologies, or case studies.

Posted by Malcolm Ryder at 7:28 PM | Comments (0) | TrackBack

September 26, 2004

Framework for implementing Strategy

Most strategies are not well-adopted by the organization that must host them in order for them to take effect.

Implementing a strategy requires that key characteristics of the organization are integrated with each other as well as individually supported.

The following chart identifies the coordination and support of those characteristics.

Posted by Malcolm Ryder at 2:32 PM | Comments (0) | TrackBack