October 24, 2010

Social Knowledge versus Business Networking

More and more businesses are assertively working on using "social networks" to try to move the business operations to a more "advanced", and at least more agile, stance.

We would say that "Social Networks" are something whose time has come. And this would be true due in no small part to the acceptance that business really does run fundamentally in and on an "Information Economy" -- with social networks being a dazzling opportunity to easily generate and acquire information heretofore untapped or even orphaned in time and place. In short, what is sought is an infusion of Social Knowledge into Business Networking, and "social network" actually becomes a handy abbreviation.

No wonder that the phrase "Social Network" has special meaning to a large business.

But in reality, businesses have a funny way of not worrying about the "special meaning" of something, and instead grasping and acting on the "convenient use" of something. Convenience is sometimes pleasant but often unruly, which, in business lingo, probably means counter-productive.

If everyone keeps their head on straight, then there will be agreement that "a Network becomes a Medium for Communication of Information that may be Shared in the Production or Distribution of Knowledge"... With all the capitalized moving parts in that description, a few questions arise. For example: did the business actually "capitalize" (i.e., fund) all the parts (on its own or through partners)? Is the "connectivity" of the Network to the Production or Distribution being managed? What if anything is being done to transform Communication coincidences or Information coincidences into Shares? And does the business acknowledge that each moving part already carries a legacy of "administration" that is different from the other parts? Does it acknowledge that applying a "social" aspect to any of the parts requires both control and flexibility (i.e., policy)?

In the last four companies I've worked at (present included), none has actually licked the problem because the effort to cover these bases is huge and in fact there has been no "chief knowledge officer" to lead and enforce what is really necessary to make these parts work together properly and sustainably: namely, Engineering!

Let's face it, the "culture" of social networking is emotionally averse to the idea of environmental engineering, because the culture is about finding the magic in organic evolution, and it thinks that engineering will work against it. This aversion results in having the sense that crafty opportunism, packaged as "innovation", "grass roots" and "collaboration" should be the strategy for growing the environment we want to call the Social Network. The problem is, of course, that making a Social Network into an actual Business Environment is the only way that a social network can be both valuably and practically leveraged by or integrated with a larger, legitimate, managed business environment. The goal of that would be to eliminate the most predominant problems of business (not workforce) adoption of social networks:
- information mistaken for knowledge
- expensive and unvetted redundancy both within and across different information and communications systems
- unreliable completeness of collections and conversations
- unaligned value judgments amongst frequent users vs. occasional users
- and unaligned value judgments among managers of the business vs. non-managers.

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

August 8, 2010

Orientation - Strategy, Architecture and Enterprises

What is it about a strategy that can have an architecture, and why would it need one?

Having a strategy means taking a position from which operations will extend in logical directions and relations. In that sense, the strategy dictates a structure. This structure must function as an environment within which to comply to the strategy. Within the environment, certain behaviors are critical to the strategy by forming an alignment to the sustainability of the strategy. This means that the strategic requirements of the environment are for the environment to sustain the mandated logic of the operations.

No wonder, then, that strategy often precipitates re-organization. Organizing that environment is an architectural concern. Architecture creates the "spaces" in which behaviors conform to generate the impacts that function as the support for the strategy.

Spaces created by architecture are designed spaces, and the purpose of the design is to specify the characteristics of the space that are necessary to assure the needed functions (which are the impacts of behaviors).

The essential behaviors pertinent to a strategy are generic, but for any given strategy the behaviors are specifically related. This reflects the reality that strategy does not define behaviors (which are autonomous, portable and reusable) but instead defines their relevance. Behaviors typically needed for strategy include, for example:

• reconnaissance
• analysis
• communication
• production

These behaviors may be understood as "domains", and within a domain the activity can occur across a "range" of various disciplines, locations, resources, events, processes, and other phenomena.

The importance of acknowledging the domains and range is to understand that at minimum there is, for a strategy, an architectural framework that maps out commitments to some domains and commitments to some of the range. This framework is readily envisioned as a 2-dimensional matrix, but the likelihood is that more than two dimensions will be needed to sufficiently articulate both current commitments and the progression of successive commitments over time.

Architecture also is responsible for designing the spaces (the intersection of domains and ranges) in such a way that they facilitate the progressions, not just the moment. This is, for example, what is meant by saying that a flexible architecture is a prerequisite to strategc agility.

We can apply the concept of an architecture of a strategy to the scale and activity of an "enterprise".  This architecture is especially important to an enterprise because it is the nature of an enterprise to set external boundaries and internal relations that in both cases cross over multiple significant time periods and multiple discrete organizations. Enterprise Strategy does not simply mean "the enterprise's strategy" -- but much more significantly and primarily it means "strategy that enables continuity and persistence of operation as an enterprise".  To that concern we secondarily add the context of particular goals being addressed by the selection and plan of a strategy dedicated to external impacts (being, namely, where you're going to be and why you're going to be there).

Understanding the order of precedence of those two issues is esential to understanding that the relationship of strategies to enterprises is that they need each other but that the relationship may still fail or succeed. This relationship outcome usually has only some predictable factors, and uncertainty is a built-in characteristic of strategies but not of their good architecture. The risks of a bad strategy can include the risk of disrupting the viability of the enterprise, and the benefits of a good strategy can include enabling enterprise status where it had not existed before.

The Archestra Topical Framework (June 14, 2005) is the central reference framework of the work that appears on this website. As a reference it may be used as an instrument -- to contrast or confirm, extend or constrain, and describe or dissect the subjects, topics and propositions about strategy that come from theorists, analysts and practitioners, presented in their work.

(This text, and the Archestra Frameworks, are copyrighted by Malcolm Ryder.)

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

June 27, 2010

The Tao of "New"

Back in April of 2007, Optimize Magazine ran an article by M.S. Krishnan titled Moving Beyond Alignment. Its summary: strategic business innovation requires a flexible infrastructure so that the company can utilize the business models needed to achieve goals. Thus IT governance and architecture must enable the enterprise to "synchronize with changes in the business environment".

Meanwhile, scheduled for late 2010, the book from strategic technology architects Greg Suddreth and Whynde Melaragno called The Path to Real Business Transformation discusses "dynamic synchronization... a rigorous, business-case-driven collaboration between the business-process owners and their IT counterparts." For this, the framework of problem-solving is what they call business architecture.

"Innovation" always has an aura that suggests the big moment of arrival of the new. But getting to utilize the new is the only way that value is derived from innovation, and utilization requires integration into, and synchronization of,  the operational scheme of things. This emphasis on synchronization firmly declares that the problem of follow-through on business strategy is fundamentally about coordinating the moving parts.

Anyone who has tried to manually shift gears in a moving vehicle knows that synchronization has two operator-controlled aspects: time spent in the gear, and timing of gear changes. In a competitive context, where time and timing are pre-planned and managed for variances and circumstantial adjustments, this plan is even seen as a strategy itself. The performance level of the plan's execution, especially in complex or volatile environments, is then most often seen as "agility". Achieving agility is, for that reason, a common business objective related to scoring business goals.

Suddreth and Melaragno further state that "business architecture" is developed through a process that defines and institutes long-term change within a framework of strategy (for example of goals, related positions and directions), planning (for example, of resources), and execution (for example, of services). They go on to point out that multiple business areas must be complementary in the context of solving a defined business problem.

To assure proper pursuit of that agreement, it becomes necessary to appreciate the difference between innovative business uses of IT versus business use of innovative IT.

• In the former case, the emphasis is on the business-level understanding of how moving parts might be aligned in a new way.
• In the latter, the point is to introduce moving parts that have a different set of characteristics and interactions than those typically tried before.

From the point of view of these authors, the former issue is a concern of business architecture; and the latter issue is a concern of IT architecture, in which (among other things) the business architecture is  "physicalized" according to Suddreth and Melaragno.

Given those points above, it would seem that the challenge is to prioritize business innovation, then leverage business architecture to identify and incorporate IT innovation that can be scheduled within IT architecture for a reasonable chance of sustained synchronization.

 

Posted by Malcolm Ryder at 9:36 PM

May 24, 2010

Discovering Leadership

 The distance between current benefits and future benefits is, in an unadorned sense, the territory for which leaders are bred to navigate. Leaders are expected to represent to us why a different future will be better, not just different. This explains why the idea of vision is so important to most models of leaders that history provides in our look to the past.

Vision may be a fundamental attribute of leaders, but no less important is acuity -- the type of perception that allows leaders to understand if you really can "get there from here".

Acuity may be the explanation for how leaders emerge from the complexity of ongoing operations. We expect leaders to be able to navigate; but often, after the goal-setting that dictates what should be IN the participants' points of view, the remainder of the task is largely delegated -- and this creates the risk and problem of losing awareness of what is AT the points of view. On the other hand, the successful navigator may acquire the leadership, gathering the role and position around them as they are found repeatedly, by others, at the right place at the right time -- a trick attributable to acuity.

Mythical leaders are most often soloists, but the complexity of modern organizations means that leadership teams are the rational way to assure that goals and navigation are not disconnected from each other. The purpose of the team is not to forsee the future, but to develop 20/40 vision of the present. Delegation into teams is a collaborative strategy that provides the bandwidth of attention to find the track to the goal and stay on it. And like all lines, the track is a collection of key points.

Image and full article Copyright 2009 Malcolm Ryder / Archestra

The track from current benefits to future benefits can be seen as a passage through various gates. Generally, four gates are along the way.

At the first gate, current pains are felt as a tradeoff accepted to sustain the currrent benefits. Because their impact extends beyond their causes and justifications, pains may become excessive and trigger a decision to find a substantial remediation, the second gate. This research for a course of action, usually fueled by analysis, will separate remedial action options into those that are mandatory and those that are not. With the weight of "necessity", these decisions or change mandates -- the third gate -- will drive determination of priorities going forward; and those priorities -- the fourth gate -- will in effect set the grounds and boundaries from which future benefits can develop.

For this pathway, it's often the case that leadership must reverse-engineer the course, finding and aligning the appropriate set of conditions at each gate. In this effort, acuity is paramount to determining if these conditions do, or can, exist. 

Said differently, the gates in this route are practical checkpoints in the assessment of an organization that presumes to form itself around the leadership and follow.

• Priorities correspond to culture. Culture is the primary factor constraining future benefits. 
• The requirement for changes that precede the culture corresponds to politics that, understood objectively, is the negotiations about the balance of risks between stability (quality) and progress (advantage). But it must be understood that because requirements are decisions, all needs are not necessarily requirements.  
• Preceding the change requirements, administration moderates  a competition for attention to needs;
• and administrative transparency may be critical to allowing the environment of operations to present its true current pains.

Building forward again, those issues can manifest on familiar management terms -- for example, terms such as quality, resourcing, policy, and governance. Other terms may similarly and respectively apply

But the more interesting aspect is this: the necessary ability to identify the path to future benefits within an existing organization suggests that from the perspective of the participating organization, real leadership may have to be discovered more than to be supplied.

  

Posted by Malcolm Ryder at 8:34 PM | Comments (0)

November 16, 2008

Control: Got, or Not?

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

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

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

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

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

The explanation so far leaves two areas for further clarification.

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

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

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

- Activity then logically follows the plans.

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

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

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

 

Posted by Malcolm Ryder at 8:56 AM

September 17, 2008

Business Process vs. Business IT: again?

Eric R. Chabrow checks in with the September 17, 2008 CIO Insight in an article called "Do CEOs Get Alignment?"

Chabrow's citations of a now-popular survey by IT professor Jerry Luftman bring to light a few things that, as it turns out, "represent IT" with an impact unhelpful to forging the "I get it" moment in the CEO/CFO offices:
- Personal experience with replaceable devices...
- management decisioning about replaceable providers...
- and of course the implication that CIOs are replaceable without strategic loss...

These frustrate the chances of recognizing "a business process called IT".

On the one hand, this is hard to overcome if people don't say what aspect of IT they mean to identify when they say "IT". An interesting point to put on the matter is that the primary expectation of IT users is actually "process management automation" -- not the same problem to solve as "information management" nor the level-setting about which sanctioned company processes are strategic/tactical/operational.

On the other hand, the word "alignment" itself continues to provoke and refresh the difficulty of reaching "I get it". The more important term to emphasize is not "alignment" but "integration". Imagine that some decision-making sector called "Business" was not integrated with the decision-making sector called "Finance". Since managing IT, like managing Finance, creates and governs a critical dimension of the business operational environment, some businesses cannot be dis-integrated with it and still rationally expect to succeed.

What might be really interesting short-term is to see and compare what stances about "alignment" come from CEOs who are Lawyers or are Technologists as opposed to Finance alumni.

Furthermore, however, as long as the "alignment" banner keeps getting hoisted by analysts and pundits in the trade, they'll keep educating CxOs to think about things in the wrong way. When it comes to IT, CxOs should be working on the management process competency at all levels -- an approach that would make it more obviously the responsibility of CEOs and CFOs to cultivate, not just for CIOs to offer.

Posted by Malcolm Ryder at 10:04 AM

July 9, 2008

What's In Your Portfolio?

For providers (instead of consumers), Portfolio Management is a robust and widespread discipline that has meaning which crosses industries and departmental functions. In short, it organizes opportunities deemed to be beneficial into suites of categorized commitments that make the opportunity "actionable" . But portfolio management is most often associated with related efforts that represent either the authorizations of the action, the methods of the action, or the customer of the action -- in effect tracing the run from supply to demand. The efforts articulating this run are, respectively, programs, projects and solutions. One confusing aspect of the way these efforts are supported is that portfolios are mistakenly thought to be components (or "children") of programs and supersets (or "parents") of projects. In fact, that is an erroneous association: instead, as illustrated below, a portfolio is a model that relies on the other three efforts to be actualized. Further, it is the interoperations of these efforts that powers and stabilizes the portfolio.

Why is portfolio management often misplaced amongst these efforts? There are two predominant reasons. For one, practitioners of these efforts often mistake scorecards and dashboards for portfolios. And two, portfolios are often pursued under "performance" requirements (i.e., requirements to increase the rate of return on equity), whereas the actual purpose of a portfolio is to provide a model for the commitment to the opportunity, defining how value will be recognized, not how "value will be generated and captured".

The language that helps to understand where portfolios help goes like this: "what is the benefit of the investment model?" Obviously, one model could be modified or even discontinued and replaced, while still addressing the same apparent opportunity. At the least, this simply acknowledges that two competitors may chase the same prize in different ways, with both making progress (without predicting which one will prevail or even whether one necessarily must). But within the model, other key actions are generally positioned as catalysts or governors -- including things like identifying a distinctive market niche and specially producing for it, tracking the cost of scaling up for the demand level in that niche at a given quality benchmark, and exercizing policies to keep decisions and approvals predictable throughout changing circumstances -- all relative to a certain type of enabling stakeholder who is the primary beneficiary.

Posted by Malcolm Ryder at 9:21 PM

June 27, 2008

Do As I Do, Not As I Say

The McKinsey gang's ongoing interest in behavioral economics leads from time to time to email alerts about articles that lead off like this:
Hidden flaws in strategy

"Why do top managers, steeped in theories of good business strategy, still make bad decisions? While ignorance and hubris sometimes play a role, the brain itself—how we think—is also a culprit. Insights from behavioral economics help explain why we don't always think rationally and how our logical flaws can lead to bad strategic decisions."

On a day like today, when the stock market dropped over 300 points, the catchiness of that intro is in the contrast between the confidence we want to have in logic and the confidence we want to have in our ability to use it.

Getting strict, we might have to say that when strategy is based on logic, strategy is interpretive -- because in different hands, the same logic might lead to different strategy and/or different strategic outcomes.

But why doesn't it make just as much sense to place the first faith in the strategy and then find the logic to execute it? Well, it does; it's just that in this mode, the "strategy" is not a performance; instead it is a proposition that supplies the point of view to be used when managing functions.

McKinsey's discussion seems to be poised to warn us away from the problem of management personalities corrupting objectivity, and further, poised to argue that this should be the right warning because we can assume that there is usually going to be sufficient objectivity to correctly navigate to the correct destination. That is, the most prominent assumption that we can read into the McKinsey caution is that it's not cool to split from the plan. Logic shall bear decisions and decisions shall bear the plan and the plan shall be righteous.

But isn't that still letting the bad boys off the hook? Levity aside, coaches bring the game plan to the players knowing this: that the players actually have to play, which means that the players will improvise their way to the opportunity to comply, if they understand the strategy -- "strategy" which is again essentially a point of view and not a performance prescription.

Strategy is about belief in the value of your position. It is esentially about where you're going to be, and why you're going to be there. Because of that, any position within a hierarchy of operational dependencies can be a strategic position. In effect, a position represents the opportunity, so the most direct way for a leader or manager to damage the potential of a strategy is to make decisions that inhibit or prohibit the players' opportunity to align and coordinate their compliance to the strategy.

Because of that, we want a model of coaching to rely on, not just retraining (or re-straining) of senior staffers to the logic-decision-plan mode. We want an observation-design-motivation mode just as much if not more. We want the sideline clipboard.

Posted by Malcolm Ryder at 11:21 PM

June 24, 2008

Business-IT Alignment: Who Do that VooDoo?

At Tech Republic, the online resource for IT management information, executive editor Jason Hiner's article "Sanity check: What’s the difference between CIO and CTO?" relays the following quick guide.

Chief Information Officer

• Serves as the company’s top technology infrastructure manager


• Runs the organization’s internal IT operations


• Works to streamline business processes with technology


• Focuses on internal customers (users and business units)


• Collaborates and manages vendors that supply infrastructure solutions


• Aligns the company’s IT infrastructure with business priorities


• Developers strategies to increase the company’s bottom line (profitability)


• Has to be a skilled and organized manager to be successful

Chief Technology Officer

• Serves as the company’s top technology architect


• Runs the organization’s engineering group


• Uses technology to enhance the company’s product offerings


• Focuses on external customers (buyers)


• Collaborates and manages vendors that supply solutions to enhance the company’s product(s)


• Aligns the company’s product architecture with business priorities


• Develops strategies to increase the company’s top line (revenue)


• Has to be a creative and innovative technologist to be successful

Given that picture, the two top observations are these:

1. Infrastructure affects the bottom line (what you get to keep), while systems affect the top line (what you get to get). Of course, this goes a long way towards explaining why a CIO would report to a CFO, while a CTO would report to a CEO. More importantly, it indicates that strategic resourcing can be a CIO's calling card, but that strategic positioning can be a CTO's calling card.

2. Much less explicit but still clearly in evidence is the difference between being a chief operations technologist (a.k.a. CIO) and a chief business technologist (a.k.a. CTO). Naturally, the easy way of understanding how to assess their respective progress and performance would rely on understanding the consequences -- of not having good infrastructure (provision of operations technology) and not having good systems (provision of market interaction technology). But getting it figured out in positive terms has stumped the panel often enough and long enough that these job descriptions still have to get spelled out long after the hiring has been done . What's still needed furthermore to get the dust to settle is a plan of co-production between them. Whereas neither effort alone could get the whole job done, the combined efforts of the two groups would offer a company an office of Business-IT Alignment...

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

April 29, 2008

Information Overdrive

Profitability through information management gets fresh illumination and color on Page 8 of the March 2008 issue of BPMStrategies, where Tom Dwyer, VP of research for the Brainstorm Group, walks us through a 21st-century operational blueprint in his article, "Using BPM, BDM, and SOA To Create A More Agile Supply Chain".

In the Brainstorm illustration on that page, the title of the Venn diagram (below) suggests that a blank area in the top center intersection would have been labelled "Actionable Insight".

The question we first posed to Dwyer was: shouldn't this intersection be titled "Policy Compliance" and stand as the third factor, instead of "actionable insight"? One can readily argue that a full reckoning of profit and advantage (the very central theme) must include this risk management dimension, and it proves to be so in actual practice but simply has (typically) more influence as a constraint than as a lever.

In a brief offline interview, Dwyer replied, noting how his system works:

"The point that I was making was to identify three elements that contribute to profitability by optimizing the management and execution of a supply chain... The three I chose were all meant to be levers or enablers to achieve higher profit... [Within those three] the combination – or intersection – of intelligent applications built on a responsive infrastructure and accurate, timely data is what enables 'actionable insight'... I would agree that achieving policy compliance at the lowest cost would definitely impact profits... but I would not choose the constraint of policy compliance over the enabler of actionable insight. "

Interpreted with lots of wiggle room, Dwyer's descriptions in the BPMStrategies article strongly suggest that the role of agile technologies is to generate transparency [largely internal] across the heterogeneous organization -- while the role of integrated real-time data is to generate transparency [largely external] across the organization's multichannel embrace of suppliers and customers. Respectively, albeit oversimplified, this amounts to an organization knowing what to do and how to do it, complemented by knowing what it should be acting on and why. In both cases, timeliness of correct information is critical. But to highlight the most important issue, it is the matter of being actionable that makes being insightful worthwhile.

Additional consideration of Dwyer's formula leads to this summarization: knowledge management, business intelligence and performance management may converge to drive sustainable competitive winning, if you know how to make them converge. We view this as a matter of management information systems being deployed strategically rather than just tactically.

Strategically deployed, the information must allow the enterprise to identify and leverage its positioning, capability, and internal alignment, so as to understand whether revised operational mechanics are appropriate to the actual environment of the organization's practice.

To put this back into the proper original context of Dwyer's discussion: the improved mechanics in question are driven by business process management (BPM), business decision management (BDM) and service oriented architecture (SOA). The strategy challenge is to realize and exploit the correspondence of these approaches with the management of information. For example:

Development: SOA : Process efficiency

Production : BPM : Performance Effectiveness

Research : BDM : Actionable Insight

In a follow-on to this discussion, we could consider the recently published arguments in The New Age of Innovation by C. K. Prahalad and M. S. Krishnan on how global resource networks represent the new supply chain mechanics and how the arguments express the information/mechanics correspondence. For example, in the coverage of the book provided by Information Week's Bob Evans, the key idea noted is that Darwinian forces of customer-centricity require transformation of a supply process into a service, causing the B2B (business-to-business) supply chain linkage to operate more in B2C (business-to-consumer) mode -- which changes the kind of information necessary to manage success. Says Evans: "resources must be shifted continually... " and "processes must be shifted from a focus on millions of customers to the individual."

Punchline: for many enterprises, the prospects of future success resemble hitting a moving target from a moving launchpad. To be able to execute that strategy, there will first need to be a strategy for enabling the execution.

Posted by Malcolm Ryder at 7:09 AM

March 23, 2008

Suddenly, It All Made Sense

Finally, that track that everything went off of, and where to get back on.
For the hi-res view, click here and go full screen or print.

Posted by Malcolm Ryder at 6:42 PM | Comments (0) | TrackBack

March 16, 2008

Innovation by CIOs: the Same Old Same Old

Proposed: Business is built on IT, and CIOs know more about what IT could offer to innovation, so they should drive the innovation.

On the one hand, it looks good on paper. It's not new, but it seems to make sense.

On the other hand... wait, where IS the other hand?

The CIO Insight Discussion hosted some talk from industry analysts Forrester and kicked off followup commentary.

Reader Jon McAdams had left an earlier comment there that saved the rest of us some writing... So I'll segue from some of what he was pointing at.

CIO's who don't feel very "chiefly" should rightfully question whether their compensation is in line with how they'll actually be measured. But in the world of performance measurement, speaking truth to power is personally relatively expensive. How do you afford it? There's the dilemma.

Proposed: Any CIO who wants to use the word "Innovation" more than once a business quarter should be prepared to provide the definition of what innovation is, by distinguishing its flavors from each other: the planned, the authorized, and the actual. If the CIO is a decision maker in all three dimensions, then there is, fortunately, no dilemma; there's just execution.

But in execution, there are two tracks to follow: priority, and production. If the CIO is not being paid to decide and validate their alignment with each other, then again there is, unfortunately, no dilemma. There's just the matter of whether other people around the CIO want to know what's real or not before they take the actions they actually take.

Let's face it, giving action orders to the "head of IT" doesn't require having a CIO or being realistic. Meanwhile, getting orders can be done with one hand tied behind your back. But being held responsible for the consequences of someone else's higher up decisions is clearly not a prescription for being the chief.

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

February 6, 2008

Proof Politicizes Architecture

Management requires an ongoing accountability for effectiveness. Normally, this accountability is the recognized set of terms for "proof". The accountability includes some model of measures, and while the model may be good or bad, the agreement by interested parties to use the same model makes it the argument that counts the most, even if it is wrong.

The model then represents the ruling hypothesis about effectiveness and, in short, memorializes the belief system in place about how to make progress. This fuels, in turn, a prevailing culture of proof that casts its influence over the several necessary layers of enablement that allow for effectiveness to result. The problem is that this influence may be inappropriate, and to avoid being misled by it we need to know why.

The answer is that the layers of enablement are variables, and the combinations of their variations offers more than one path to effectiveness. To describe an occasion of how effectiveness resulted, we would monitor variations within threshholds on as many as seven layers:

1. Effectiveness is usually a measure of the degree to which an actual outcome matches a desired outcome.
2. But the outcome is a strength of reaction to an impact generated by some agent.
3. The level of impact observed can itself be more or less than expected, or desired, or needed -- and often there is insufficient attention paid to distinguishing the three characteristics (which is what allows the seeming inevitability of unintended consequences).
4. The cause of the observed level of impact is a state or an output.
5. The agent of that state or output is a quality level of process.
6. The runrate of the process consumes inputs.
7. The level of supply of inputs allows the processing.

In this view, the bottom four layers predispose whatever can happen in the top three, which is why the bottom four are so routinely captured by the design of an architecture. But if the architecture is unfamiliar or expensive, the distance between layer 4 and layer 3 is quite large. The burden of proof will fall to the architect to demonstrate bridging the gap.

With some "proof-of-concept", the effort is made, but it must be accompanied by its own "concept-of-proof" that relieves it from the pressure of "measuring up to" the top two layers.

It takes gutsy decision makers, or ones with little to lose, to accept this -- rather than to impose the top-line measure as the justification for considering the architecture at all. Innovators and early adopters accept their proof points at level 4, while laggards are hard pressed to dig below level 1. Consequently, the architecture in question gets positioned on the spectrum somewhere between demonized and championed.

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

January 1, 2008

Driving Value from Change with Knowledge

Frank thoughts about why people are important to an organization mainly go down two tracks.
One track examines what is necessary for the organization to be "in the game" it plans to play... The other examines what is necessary for the organization to play the way it wants to play, when already in the game.

Few experienced people still hold on to the simplistic idea that the former track is about line workers with the latter being about the managers. Since the recognition of CRM's dominant influence on the top line of the business, ample evidence establishes that alignment of front and back offices is critical to sustaining wins. Repeatedly getting the right things to the right place at the right time for the right reason means that staff in management and in line production must both attend to operational fundamentals, and both attend to situational performance differentiators.

During the early adoption period for that principle of alignment, "knowledge worker" became a profile arguing for distinction. We identify it as a profile, and not as a role, because it is an optional mode for every role. In organizations where it actually makes sense to discuss "knowledge workers", I.T. has made the greater part of production dependent on information processing and on interpreting the status of the processing outputs. Net: in the procedural life of the organization's activity, analysts now constantly threaten to outnumber mechanics.

The appropriate new idea of worker "productivity" follows quickly on the management of information, where the issue is about what value the worker's information management should provide. In the usual formula, value is expected to result where experience influences the information management.

But there are two tracks involved in applying that experience to the information:

- keeping things the way they were designed to be; and,
- successfully adapting as necessary to changes.

Most practical experience in organizations is role-based. In fact, we must assume that managing experience through roles is the complement to managing information, with their sum being what we recognize as practical knowledge. The question that the information age has added to the foreground of this discussion is how the manager role and the line worker role respectively exercize the knowledge worker profile to provide the value expected from their roles.

Workers with a higher degree of performance recognition in the organization are most frequently those who run the second track -- adapting to change -- in the knowledge worker mode.

To point this out more specifically, it helps to identify what qualifies as "change". The table below identifies, in ordinary language, the key types of change (points where value is generated), and the relevant "valuable behaviors" sought from managers and line workers executing their roles in the knowledge-worker mode.

Aside from confidential facts, the most privileged type of information is ideas. Speaking broadly, we can say that an "idea" is a proposed condition with an expected meaning. Left to its own devices, the "k-worker" (knowledgeworker) profile is about managing ideas for specific circumstances. As shown in the table, that relatively "pure" focus is pulled to different pragmatic effects by the role that uses it (manager or production line worker). That said, for most companies relevant to this discussion, a prescribed business process is the production line of importance that "manufactures" the necessary deliverables from the organization.

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

September 29, 2007

Beyond Alignment: Balance?

What actually makes any "Top Ten" list interesting is knowing something, maybe a lot, about what didn't make it onto the list.

Baseline Magazine's Topline section ran their top ten best practices for IT-Business alignment in August, with Robert Hertzberg laying out "core principles" that should help companies get past what he called "messing up this fundamental aspect of I.T. management"... What it said, in its own words, is that "a lot of these [practices] are about structures and processes... but think beyond alignment." Since the article handily lives in full online (and also still in print for the diligent researcher), we can just revisit it here both in summary and with an eye towards what it didn't say.

After a couple of readings, the ten items in the list group into an interesting basic story. The highlight of this story is that the best practices all seem to hinge on meetings and facetime, documentation, and/or interaction and teaming. Put simply, without communications, most of the practices don't happen or don't matter. But there's more. In summary fashion, here's how the high-level dynamic stacks up: communications mediates between what we care about and who cares. More specifically, as shown in the pictures below, the core ten practices list advises to model and measure commitments (what we care about), and to organize support and awareness (who cares).

Looking at the themes represented in the core ten list, it turns out that this means managing risk, strategy and ROI on the one hand, and managing projects, relationships and incentive on the other. So what was left out of the list? It's not so much a matter of line items as it is a matter of further identifying what must be done about what made the list. Curiously, the Baseline list, claiming to be largely about structures and process, didn't use any of many key terms that one might expect in a discussion aimed at I.T. managers. In the images below, we can see the general correspondence of the themes found in Hertzberg's list (upper image) to the way I.T. managers might ordinarily implement structures and processes to support the core practices (lower):

Given this "big picture", the most interesting and maybe disturbing omission in the original Hertzberg list was any clear reference to the roles of managed knowledge and of managed I.T. architecture as factors of alignment between the Business and I.T. We can only speculate whether this is some kind of sign of the times, or instead is meant to be implied by whatever lies within the list's advised "thinking beyond alignment".

But as suggested in the illustrations above, alignment itself may be something needing a degree of redefinition. What if the key to preventing the "messing up" is first and foremost about balance? Namely, balance between the attention to what we care about (the left side of the pictures) and the attention to who cares. For example, many practices aim to "optimize" efforts within a single area, presuming that the results will be valuable in some absolute way. But whenever the energy given to the issues on one side of the picture aren't matched by corresponding emphasis to issues on the other side, it is arguably unreasonable to expect good things to happen, and it is easy to expect counterproductive exaggerations of some kind to occur instead.

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

September 21, 2007

CIO 2.0 part Two

When Gartner Group published its Resource Synchronization Chart at ITXpo 2000 seven years ago, it identified a 4-level maturity model that identified the highest level of maturity -- System Synchronization -- in terms of a "business unit's view of IT Value" in association with "IT Asset Management" and "Operations Management".

Seven years later, it may be the case that only some large interesting companies, not the numerous smaller or just plain boring ones, are going to be recognized as having reached system synchronization.

What is the BU's view of IT value at this synchronization level? "Facilitate Business Value Creation". When we look at what "value" has to mean, it almost always means "a distinction with a difference", as opposed to the popularly known opposite, a distinction without a difference. A proper understanding of this will mean not just glamourizing year-over-year growth, but equally well recognizing companies that successfully maintain themselves where others can't even play.

Value comes in the difference that a distinction makes, while the distinction itself comes from actions taken. Actions are the source of alternatives, contrasts, innovations, or namely all the things generally associated with well-executed strategies that provide a competitive (survival) advantage in a business ecosystem. Action is essentially labor, and technology is essentially labor enhancement. So the question of aligning technology and business has never been complicated, not for the Pony Express and not for Amazon.com, but also not for dentists and not for a pro baseball club.

Politics and economics in implementation are where most of the complication typically arises, but with companies that mainly play in markets actually created by superior labor capabilities, a refreshing absence of confusion about IT can exist. The real challenge is for those companies to know that they are doing the right work -- literally, to know that they are making the right difference.

Except in some Darwinian sense, it does not logically follow that our CIO 2.0 is supposed to know what the right difference is. If that were the case, we wouldn't need chief marketing officers. But where does "the right difference" come from, anyway? From the perspective of someone who both cares about the distinction made by the labor and who can reward well enough. What is more sensible, then, is that all executives who can articulate how labor and opportunity are related to serve the interest of a market should be responsible for organizing the enterprise appropriately. The responsibility is what makes them executives or chiefs. There is no demonstrated reason why CIO 1.0 couldn't be qualified to do that. But there has always been plenty of evidence as to why CIO 1.0 has not been allowed to do that, if not at the hiring gate, then afterwards. The question is, why is that going to change now?

Meanwhile, we just can't know how many great "marketers" have been undermined by inadequate labor. As for convergence, well, rebranding good ideas is important because it gets fresh audiences paying attention. But the biggest problem to solve in the business-IT relationship is not going to go away until organizations learn to prefer "resource" accounting over "property" accounting. And what is a resource? An asset with a job to do. Guess what happens when bad assignments are made.

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

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

September 19, 2007

Make IT a Business Strategy

In the CIO Magazine article Let the Business Drive IT Strategy, the visibility of many views on strategy helps to paint the map so that people concerned with IT strategy management can see where their relative starting points are, not just their goals.

But in that map, how did we wind up in so many different starting places that we decided to call by the same name?

Here is a 50,000 foot high view to consider. What does "IT Strategy" mean? Strategy for what? The candidates are found in two dimensions.

First - what is used:
- Services
- Resources
- Information

Second - how it is organized for use:
- Provision
- Architecture
- Property (assets)

Make a 3x3 matrix of the above, identify what needs to happen in each cell and who needs to care (owner, operator, consumer), and then on the business side at least everyone can see what they are trying to talk about.

With that view, it then becomes meaningful to talk about the business's ideas of performance (goals), value (impacts), and risk (policy and culture) -- with the objective of assigning people to be responsible for them and then investing to make those people successful.

This isn't about "succeeding with a strategy"... it is about actually managing with a strategy.

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

March 18, 2007

Personal Value, Company Worth

Despite the buzzing about organizational flatness, it is still customary to think hierarchically about the relative importance of individuals in the corporate workforce. This is continuously fortified by the dual notions of "promotions" and "tiers" that characterize most organization charts.

The attendant mythology is that if people are higher up the chart, then they are more important. More factually, there's little debate that more organizational power resides at higher altitudes -- but what must not be lost on everyone, meritocracy notwithstanding, is that even higher power is not the same as higher performance.

Org charts are just a sketch, with limited ability to explain three key issues.

1. How does the individual decide what kind of contribution to make? Does he want to be influential or just billable? Particularly critical, or broadly resourceful? What does it take, and is it possible in his workplace?

2. Conversely, when a particular company initiative or problem rolls around, what kind of value is most needed from the individual, and therefore what individual has the appropriate profile to meet the need?

3. Finally, is the company really cultivating the potential for getting the contributions that it most needs -- or is it just coasting on organizational conventions?

From the standpoint of performance, not only can higher ranking individuals be objectively evaluated in the same way that lower ranking ones are, but every individual actually thinks in the same terms to decide what kind of value he or she is really going to bring to the organization's performance. For everyone, there are the same two steps: they make decisions about modeling themselves, and they align the personal model with the circumstances. The effects are not uniform -- not for one person over time, nor for different people in the same moment. But what actually gets done by the organization is pretty much the consequence of all these individual decisions pitted or adapted against the day's environment.

To see how the self-model fits in at work, first walk through the self-modeling picture:

Here, within the main oval, we see the four key reference terms that the individual uses to describe their predisposition coming into the work situation: Billable, Critical, Resourceful, and Influential.

It's fair to see these terms as multiple "ambitions" occurring simultaneously but with varying degrees of strength; thus at any time the individual has a "profile", which may fluctuate from one time to the next.

Some individuals fluctuate more than others. But more to the point, there are surrounding factors that encourage or inhibit the person's profile, and that is how the rest of the picture comes in.

From the management viewpoint, the objective notion of the individual's value is simple, and twofold, in summary:

In effect, this is what the company is trying to do with or get from the individual.

When evaluation time rolls around, the question is largely one of whether the individual has committed to these two conversions as much as the company wanted him to. (In our research, we've noted that most observers initially believe the terms provided here are mis-ordered, and that the conversions should be "skills into quality" and "time into revenue". But, through most simple ROI analyses for intellectual capital and capacity management -- mandatory stuff for an enterprise -- that belief is quickly shown to be misguided.)

So, to understand why any success was possible or achieved in the person's alignment with the company's wish, it is necessary to see how the person's self-modeling fits into the company's model.

As arranged below, the remainder of the terms from our first illustration are indicators of that company model. They bring up the points at which the company makes things more or less hospitable through making investments that resolve key resources and constraints.

If the company doesn't make the investments, then the constraints do not enhance; instead, they become "restraints" -- and the resources (people) cannot be effectively heightened in value.

Roughly speaking, that final illustration compares "what kind of workplace" is available (worker in context) with "what kind of company" is there (work in context). Not coincidentally, these are the two key perspectives that the worker intuitively brings to the situation, greatly affecting his motivation (at least) or ambition (at most).

Back in the initial illustration above, the interdependencies involved in that comparison of workplace and company are laid out along the main oval, where they can be individually inspected.

Companies often make defacto decisions regarding those interdependencies that seem like no-brainers but may really be value-inhibiting. For example, assignments are an ordinary feature of the organization's workday. But assignments link skills to time and literally position the worker in the workflows. Thus, the potential of the business process is critically afffected; meanwhile, the logic of the process design is either a smart reason to invoke the worker or a not-so-smart reason. Bad processes can easily mis-position (i.e., waste) a worker, just as a bad worker can make a process ineffective. Management needs them both to be "good".

Likewise, it isn't hard to understand that overworking the person (in the "billable" link of time and revenue) lowers morale, or that training (education) would beneficially link skills and the quality wanted from the use of time.

Similarly, other "ordinary" aspects of the company will predictably map to the dynamics underlying value-capture. Depending on the point-of-view, these aspects may be recognized through other names or circumstances. For example, in our illustration's set of work-in-context constraints:
- Policy = "governance"
- Expertise = "intellectual property"
- Process = "organization" (dynamic, not static)
- Capacity = "goodwill" (of the stakeholders)

This helps us envision what impacts are really being obtained from things we know we're already thinking about or doing. But as arranged in the original oval, the most interesting part of the dynamics shown may be their bilateral nature. For example, just as education should be derived from investing in expertise, the picture asserts that strategy execution should be cultivated from policy (governance) -- certainly not only the reverse.

It is easy to recognize that the corporate valuation relies on those very issues of policy, capacity, etc. But now it is also easy to see how they are not just "performance results" but instead actually success factors -- due to the need for the company to invest in them as constraints to be managed around workers.

By tracking decisions and actions about the key factors illustrated above, we get answers to performance questions that may not have been apparent before.

Posted by Malcolm Ryder at 7:28 AM | Comments (1) | TrackBack

March 13, 2007

Fast and Pretty, but not Cheap

Normally you'll find an article here instead of a conventional blog posting, but today Michael Hugos, of CIO Insider, caught my attention with his blog posting about agility on his site, Doing Business In Real Time. It definitely warranted a fast reply of comparative and perhaps contrasting views, reproduced here below. (Be sure also to see his Comment following.)

Very often the agility issue comes up in conversations with managers, and there are two interesting and recurring characteristics when it does.

One, it comes up *after* results have been calculated and posted. That is, managers see what already happened and ask "if we had been more agile, would it have made a difference?"

And two, there is tremendous confusion of agility with other ideas including "flexibility", "resilience", and "versatility".

The one-two punch of being reactive and confused makes "agility" something that remains vaguely ambitious as most managers don't know where to start, on which aspect they are really concerned about, or whether it is the right aspect.

Let's call that the worst case scenario. Hugos' article addresses that by outlining "agility" measurements -- which turn out to be what is largely now identified as Operational Performance Management (OPM) -- great stuff that is not the same as "agility" but is the same as "alignment".

I propose that the agility issue comes in when OPM is a strong practice, allowing targets and their pursuit to change in ways that are (here's the punchline):
- easily operationalized...
- with successful change management...
- to realign on time...
- without breaking things.

There, in a nutshell, you have the four points of reference that allow you to spot why your company is or is not agile. It's a process matter.

As for the 2% to 4% financial improvement that Hugos uses to stand for agility, that's a target, interesting as a representation of what ROI might justify the effort to be agile. But knowing where the target is doesn't tell you how to get there. For most managers, it is not so much that being agile will "cause" the percentage increase; instead, the issue is one of "prerequisities" -- namely, the probability of getting the increase without being agile is so poor.

Posted by Malcolm Ryder at 12:15 PM | Comments (1) | TrackBack

February 15, 2007

Why "Best Practices" Improve Efficiency

Inefficiency comes from disorganization. To gain efficiency, and get ROI in that effort, typically we must organize specifically to meet demand. Naturally, this organization (verb) will rely on distributing responsibility (accountability) and assignments (resource investments).

But in the context of managing value, "inefficiency" is often attacked at the wrong level. Operational inefficiency is important but the more significant issue is the efficiency of the relationship with the "customer".

For a customer, the most valuable efficiency is about how consistently and readily events in the relationship are satisfying on demand, as opposed to how much there is a necessity for extra effort on the part of the customer if customer satisfaction is to be achieved.

This is efficiency in the same sense that we say a market is efficient: that is, where supply readily meets demand under terms that are economically favorable to both parties. In the matter of "best practices", supplier readiness is the focus.

So what exactly is "best" about best practices?

1 - "Best" doesn't assume any perfect world of complexity. It is problem oriented. It directs an approach to solving and preventing problems.
For different kinds of problems, different practices are best.

2 - "Best" is not about execution under supervision; instead, it's about managing by plan.
It is not primarily about processes, but instead about what expectations of processes are most reasonable and why they are.

3 - Yet, "best" is not about promised outputs. Instead, it's about optimization that removes barriers to availability and capacity.
It's about inputs, not outputs... environment, not results.

The following illustrates the relationship of factors in the best practice equation.

First there is an operational underlayer for driving quality and cost to needed levels. This is about production.

Then there is a governance layer that provides the organizational context and principle
for bringing production to customer relevance. This is where practice makes "best" or not.
It generates reliability by optimizing conditions in which cost and quality can increase
availability and capacity.

The punchline is that in the context of the customer relationship, operational "efficiency" is predominantly about the reliability (efficiency) that the customer finds in the relationship with the supplier, or else it doesn't matter.

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

January 15, 2007

Critical Mass on the Critical Path

In his comments on the Archestra article "Why Change Is So Hard", Sid Kemp of QTI, Inc. picks up the beat on how to campaign a change. His description highlights the idea of transitioning between different stable states: the periods before the change and after it. A seven-element program that Sid outlines is a case methodology for "covering the bases" that the Archestra matrix on individual attitudes presented in the original article.

Where it comes to covering these bases, Sid's comment calls out something of more pointed interest to think about -- i.e., that an individual exerts influence on other individuals in a way that leverages the current state of things into a sufficient level of steadiness for a change to be either "accomplished" or "prevented". In other words, the individual can disproportionately contribute to a critical degree of momentum or inertia.

Good call. Furthermore, that has very obvious implications for the idea of "leadership"... It's a given that a group involved in a change will typically feature, within the group, different functional roles in the composition of the "to be" steady state. Not everyone will have the same kind of influence, and the new equilibrium will not ask them to -- neither in the composition activity nor in the final composition structure. In effect, amongst the group of individuals involved, would-be leaders may need to adopt the change differently from would-be followers, and so forth. Along with that, some individuals may experience a change in role due to the move from before to after the adoption campaign. Following suit, have we as change managers identified the leaders and followers on the "momentum" side, separately from the leaders and followers on the "inertia" side? (By the way: we'll note here, for future consideration, that change leaders and change agents are not the same role, even though they may both be played by the same individual. But how about when the agent is not a leader?)

This lets us revisit a "truth" that we've both observed and experienced, which is that in some occasions, "success" is not pretty. It goes without saying that becoming different is not necessarily becoming better, so a proposed change has to carry with it a presumptive confidence that its objective is an outcome that has more value than does the status quo. This is exactly why one of the quadrants in the Archestra matrix is "appreciation" -- it includes the same sense that we convey when we say, as an objective measurement, that anything else has "appreciated". The change proposal argues that the value will be there; the question is, will the individual say "I'll buy that..."??

When the proposed change is an executive goal, those individuals that don't buy that may in a different sense "buy it" : they may become either targeted damage or collateral damage, clearing the way for transition.

But if these individuals are still deemed important as resources to the future state, then managing these resources is a risk management activity within the campaign for change. At minimum, the individual's role must be proposed.

Attention to this issue had been developed methodologically during 2000-2002 by the consulting group Fulcrum Management, whose principals Howard G. Hastings, David A. Messineo, and yours truly M. Ryder offered Change Assessments using the analytic cycle Requirements-Risks-Resources-Approvals to reality check the top-down alignment of objectives and commitments in change.

It is on this point of "alignment" that Sid Kemp's comments on populations being "systems" carry weight. Additional specific light on this alignment problem is cast quite strongly since 2004 by Jonathan Becher in his work with Pilot Software, Inc. in Operational Performance Management. Kemp likewise offers work on the "leverage points" of alignment through his current offerings, under other labels, at QTI, Inc. Neil Russell-Jones puts out "The Managing Change Pocketbook" at www.pocketbook.co.uk, containing a fairly classical approach that we can see mapping to this issue. And (if you are still reading this!), similar efforts in your own sphere of activity are likely familiar to you under various other programs and entities you can name.

So what?

In further articles at Archestra, we'll maintain an opportunity to show how these different offerings reiterate the attitudes matrix from "Why Change Is So Hard", and how they help to explain the criticality of the individual's adoption to the design for change. Naturally, if we find that the matrix is broken, we'll change it...

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

December 17, 2006

Complicated vs. Complex: Hitting Moving Targets with Moving Parts

Coordination is the essential architecture of execution. It converts things that are merely cooperative into things that are made for each other. But don't take our word for it -- ever try to hit a pitch?

To hit a moving target, you aim for the impact point, not for the target. But to do that, there are two things to be done.

One, select the impact point (!) ...
Two, align with the target's trajectory. And that alignment requires that you:
- Predict the trajectory, and...
- Calibrate your attitude for engagement.

What is "attitude"? Effectively, it's the "Strike Zone" of your stance. It comes from the coordination that we've just called alignment to the trajectory.

Ordinarily, the lingo of baseball thinks of the strike zone as something the pitcher has to aim for; but in our case the important thing is that the batter creates a zone in which the batter is more able and more likely to strike the ball. We notice that the batter does this through his "stance": the combination of body posture, attention, and decision.

You can see the batter's attitude when he's standing at the plate, and the attitude generates his strike zone.
In particular, we can see the batter aligning his feet, knees, shoulders, arms, head, and so forth... All those parts are always there, but they don't mean much until the batter decides how they will be "together" for the heat of the moment of the swing... Before the swing, the attitude creates the potential -- the effective position versus the target; in effect, the attitude is the potential.

Potential is what we want, so let's break it down again, from the overall attitude to the elemental parts. Top down:
- Atttitude is, in effect, the timing, range and coverage area to which parts are together committed.
- Commitment is the state and fit, or condition, established of the parts, for the duty
- Condition is the presentation of the elements - i.e., the the quality of the coincidence of the parts.

To start out, the batter brings all the parts, but the parts do not simply present themselves; instead, the batter brings them in a certain way to the occasion this time, beginning the coordination that develops fully on up through commitment into attitude.

Our common language for describing that hierarchy of coordination reflects that we already know it: bottom up, we look at the batter and can say things like "he's brought his best stuff today", or "he's really putting it all together now", or "it's obvious that he really wants it"... in other words, we know that his overall readiness involves his technique, condition and commitment. And when we see him having a bad day, we might know that it's (respectively) because of injury or fatigue, poor choices, or lack of desire.

Said even superficially, the combination of condition and commitment sounds like an obvious formula for explaining the difference between probable and improbable success. It's what we already know from experience. So as managers, where there is a need to enhance that probability, we trust that it's important to know what they really look like, what makes them work. But what do they really look like?

At the core of the matter, the parts you bring to the occasion don't just make things happen because they are there together. Their combination might be merely complicated, or it might be valuably complex. When "complicated", the parts are there, but their coordination is low, leaving the value of their combination uncertain for the anticipated moment that matters. When "complex", their coordination is high, as their respective characteristics are all oriented to the cause in a consistent and focused way.

We know that complication can be a show-stopper; but sometimes it's just unavoidable, so typically we try to minimize it or make the best of it. This might be necessary, but it's not enough. More importantly, some effects are not possible through "simplicity" -- it might take a complex formula to get the right result. Increasingly, we need complexity.

In complication, the coordination of the coincidence of the parts looks different than in complexity. As seen in the comparison below, the possible value of the parts has been taken to a higher level of benefit in complexity than in complication -- and in managing execution, we want to aim for having the benefits to call on as our resources in the heat of the moment:

While even in complicated circumstances the parts can offer some benefits, they are not as potent as the parts are found to be in driving the value of complexity.

In complexity, as shown in the following illustration (click to enlarge), the parts will drive more. It amounts to an important overall difference:
- in complicated circumstances, including the parts still leaves variability that may or may not be useful.
- in complex circumstances, involving the parts generates agility that is probably useful.

The formulas for doing that are not offered here. While one can argue that the illustration is not proof of anything in itself, it is reflective of the difference in characteristics as surveyed in cases where complexity has been found behind good execution, versus complication being discovered behind poor execution.

To improve on complication in our situations, our problem is to look at the condition and commitment of whatever "parts" or elements we've brought to it, and change them so that we have a valuable complexity instead. By improving the quality of their availability and potency, we get a better strike zone...

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

June 26, 2006

Recognizing Progress: Effects versus Results

We know the old saying, "don't confuse activity with achievement." It warns us that making an effort doesn't necessarily mean we're making progress.

But one of the problems in recognizing progress is the need to know whether the conditions being generated by activity are beneficial or not.

To do that, there first must be an awareness that benefits may be unintentional as well as intentional. And meanwhile, we might get to the benefits in a planned or unplanned way.

This quickly catalogs four kinds of outcomes:
- intentional benefits from planned activity
- intentional benefits from unplanned activity
- unintentional benefits from planned activity
- unintentional benefits from unplanned activity

But along with activity and benefits, there's a third dimension too.

In management, we have to especially notice that planned or assigned activity is a mode of change, and that the circumstances (think "environment" or "context") of the activity can also change -- independently of the activity and especially during the activity.

With two sets of changes occurring -- activity and context -- the impact of each one on the other will shape the emergent conditions that are examined when we look for "progress".

When it comes to an assessment, history has shown that some combinations of conditions are far more associated with ultimate success than are others. This is why the "profile" of the conditions is so important to detect, not just a measure of an action or event.

This is a way of saying that success is relative to circumstances, so describing the circumstances adequately is more important than anything else in understanding whether an effort is being "effective" as opposed to its being ideally conclusive. For example, in a long race, the "patient tortoise" is more successful than the "impatient hare". The progress profile includes the awareness that the race is a long one... not just that the runner is fast or slow.

Here's another similar example. Imagine a motorized walkway running from point A to point B. If we decide that "progress" is to get from one point to the other, then the following problem occurs: walking on the walkway against the direction of its flow might "net out" to going nowhere. That seems to represent no progress.

But alternatively, if one must try to get to the opposite point even if walking against the flow, then going nowhere is better than going backwards -- so in making the effort, avoiding a likely loss of ground is a benefit to the cause and must be seen as making progress.

In the latter case, the benefit is clearly an "effect" -- meaning that it is an outcome contributing to the overall desired "result" although we don't yet have that final result. And we can see that the idea of "effectiveness" is most strongly associated with the way (and the fact) that we have predefined the requirement, not the goal.

Meanwhile, the effects of an effort are not always beneficial. We'll be getting effects from any effort, but they may not all make positive contributions to the desired result, and furthermore they may even be counter-productive.

The above perspective on things yields a description of the approach we need for understanding and communicating progress:
- We identify effects;
- We rate the impact of the effect(s); and...
- We measure the result

Thus there are three kinds of achievement to observe:
- producing the right kind of effects;
- gaining more beneficial impact from the effects; and...
- getting closer to the desired final state

Superficially, this mimics the structure of organizational responsibilities:
- operations (for the right effects)
- management (for the beneficial impacts)
- executive (for the target state)

But more importantly, there should be a strategy that guides the prioritization of efforts by telling what kind of progress is most critical, giving the most bang for the buck, at different times and places. Changing operational competencies is radically different from changing targets. Changing the wrong thing can be at minimum wasteful and at most catastrophic.

Postscript:
Extensive practical analysis of this issue -- including further distinctions between "activity", "achievement", and "progress" -- is available from Eliyahu Goldratt, who developed the Theory of Constraints.

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

May 29, 2006

Strategic Communications in Business-IT Alignment

Recently I was asked to revisit the book "The IT Strategy Management Process" by Eugen Oetringer (who has related work seen elsewhere here on Archestra). Oetringer's broad sweep in this book comes close to making its title a misnomer, as the first summation of the book's import is really about the creation of an internal commerce of knowledge to facilitate governance of IT operational performance.

However, the book's subtitle, "Supporting IT Services Through Effective Knowledge Management", promises a focus that would resolve some of the competition for attention otherwise being waged within its pages by governance, strategy, KM, and change management.

The question then becomes one of what KM's support of IT services has to do with strategy, and why this connection should be considered a management process for IT strategy.

In this book, the best approach to seeing that is to avoid trying to fit the book into other molds of that type. Instead, assume that the book brings whatever it needs, itself -- and chart out the connections.

As shown below in our original take (i.e., not Mr. Oetringer's, and not in the book), the key feature of Oetringer's discussion is the creation of a knowledge repository, for which the book offers an enormous amount of systematically integrated construction detail. The purpose of this repository (at bottom) is to foster the improvement of management's ability to optimize its performance (at top) in terms of solving organizational problems (in between). The organizational problems come in two broad categories -- structure and environment. Our original diagram here highlights in red the challenges in these different areas of concern.

As sorted out through this picture, one major corresponding observation in Oetringer's sweep of issues is that the structural problems suffer from sustained but inadequate responses, while the environmental problems risk going altogether neglected (sometimes unnoticeably). Intellectual capital is the common solution to the pair of problem areas: it most notably supplies strategy and policy in the prior void on the environmental side; meanwhile it improves the structural side.

With the assumption that this fortification "optimizes" I.T. management's ability to generate better services, business can better rely on IT to help successfully adjust to the continuing variability of the business operating conditions.

Given the above, the two obvious questions that the summary diagram raises are:

1. What is the mechanism by which the intellectual capital (generated from the underlying KM) is appropriately "invested" with the returns being effective structural and environmental management practices?

2. What is the mechanism whereby the incorporation of strategy is continually attended as a lifecycle of strategy use and renewal?

Overall, Oetringer's explanations point at communications as the primary "process" providing the mechanisms for these management enhancements. Oetringer's level of thoroughness shows that the communications issues are both pervasive and profound, but one might argue that the communications -- not the IT services -- are the focus of the KM contribution. However, in a success story, the services eventually gain benefit at their location farther up the value stack.

Consequently, from the standpoint of best categorizing the book's discussion, one may find both the title and sub-title of the book still somewhat orbital to the real distinction that it offers. However, as a hierarchical layout of the book's context, the titles do draw you to his discussion through explicit assertions of why you should care.

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

April 2, 2006

Business-IT Alignment: Revisiting ActiveROI

By the time the Y2K threat got serious in the corporate mindset, IT innovation had already reached a point of viability where replacing old stuff had to be taken as a serious alternative to patching it.

But it wasn't just the technology that needed to be reconsidered. As it is almost automatically remarked in the business conversation about IT, related people and processes also were in the mix -- and here came the dot-com wave.

Among various other things that "e-business" did to reposition IT in the enterprise, it gave an old teaching instrument a new meaning.

You may remember the elementray school spelling aid "I before E except after C"... For it's new web-era use, I translated it to mean "infrastructure before engagement, except after customer." The problem new to the day was that the web was now allowing customers unprecedented aggressiveness in dis-intermediating the corporate mechanics that ordinarily actually provided services. Customers emerged who wanted "do it yourself" relationships, while others emerged who simply had no patience any more for companies that mired them in internal production technicalities.

Effectively, in both cases the customer's punchline was: "if your I.T. doesn't make me happy, change it or I'm gone."

The hugely superior economies of keeping existing customers versus gaining new ones made the most sense of my new translation. But the implications for IT organizations were not really so new. The point-of-view on IT's operational performance just shifted from I.T.'s "internal" customers (business units) to the company's "external" customers. Internal customers had already had this attitude for a while, and everybody knew it.

Still, despite external customers suddenly getting their hands directly on company infrastructure, it seemed brutally obvious that IT organizations should not be held responsible for managing external customers. (Otherwise, what were business units for?) So the message really needing to be drummed was that internal customers needed to be better empowered by IT.

By abstracting the basic management steps to that empowerment -- resources to operations to relationships -- the model I first proposed set a floor under a wide region of research, from which several key further items grew. Among those, a major one well-rehearsed by 2002 forecast the IT Organization agenda as in the article CIOs: Managing the business's IT Agency.

Then, what brought that agenda to the level of the full CxO group was the problem of linking IT performance to enterprise performance. This problem enjoyed a huge rise in importance due to the maturing acceptance of having enterprise applications automate essential operations cross-functionally, despite hair-raising complexity in integrations and change management. While I liked referring to the celebrity of the problem as "Enterprise Chance Management", it wasn't much of a joke since it was also becoming more obvious that business opportunity was relying more and more on IT-enabled responsiveness.

Given the huge level of investment recommended by Y2K, enterprise applications, and the internet, the business need to understand the value of its IT capacity hit a high point that called for a way to put the IT agenda into a model of being managed by the business. In reply, I created (and own) the ActiveROI model -- a construct signifying the generation of business value from IT resource optimization, achieved in a continuous and proactively matured discipline. Translating the model into practice methodology, the consulting firm Renovance, LLP went to market. Renovance's elaboration of methods for applying the ActiveROI model was indicated early on in the whitepaper, "ActiveROI: Achieving Business Processes and IT Infrastructure Alignment through Real-TIme Management". (As a consulting firm, Renovance developed and offered trademarked practice methodologies of my copyrighted model, in its lines of business.)

From a CIO's perspective, the ActiveROI model describes that the enterprise's engagement with the marketplace runs on an organizational platform created by architectural and portfolio management disciplines that can coordinate IT.

But overall, ActiveROI understands performance in terms of relationships and the services that maintain them, while it understands resources in terms of events and the investments that address them. The critical thing to note is that services and investments are the two most highly discretionary offerings of the executive management of the business -- effectively defining the identity of the business that will predispose its opportunity in the market. As explained by ActiveROI, this "drills down" to the IT agenda and its business alignment.

By way of ongoing explanations and by hosting comparisons and debate, Archestra will continue to elaborate the ActiveROI model and several of its already-in-progress successors or offshoots -- including Archestra Runtime by myself, and works that certain colleagues may finalize for presentation via Archestra in the future.

- Malcolm E. Ryder, April 2, 2006

Posted by Malcolm Ryder at 9:50 AM | 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

March 9, 2006

Rules that Prove the Exception

This brief item is one of the occasional Archestra "bookmarks" to research or researchers.

In a discussion titled Management May Be The Ultimate Limit On Growth, John Parkinson's March 6th, 2006 post on the eWeek blog pulls to the surface an issue broadly massaged in many Archestra pieces, which is: the dominance of management as a factor of any return on investment.

With apologies to more strict research, and with heavy credit for inspiration to Paul Strassman, coverage of this "return on management" will likely always be a feature in the Archestra collection. My only gripe is that, seemingly, each time the idea comes up in a new place elsewhere, it shows up as if it is a new discovery. On the bright side, it keeps getting validated again and again.

Writes Parkinson:

GE's "core" is actually a system of management that is very nearly perfectly aligned to its corporate culture and chosen operating model. This system was put together under Jack Welch and allowed GE to essentially run any kind of business it wanted to...The challenge GE faced (and that Jeff Immelt is I believe steadily addressing) is that eventually, just about everybody who could tolerate working in the GE system was already in it—or at least the attrition and replacement rates were in balance. When this happens, you either have to stop growing or change the system.

But again, the full eWeek posting speaks for itself, so click here to reach it.

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

February 27, 2006

Getting Governed: Handling the Risk of Value

Remember life before governance?

We planned the work, and then we worked the plan.
A lot of the planning was about defining the "we" -- and cascading that definition down from the high (market) level to the low (task) level.

In this cascading, our business starts out as a model for certain kinds of market interactions, and then an organization is created to operate according to the model. We have a strong idea about what kinds of things are required for the interactions to succeed, so what we focus on is making sure that we know someone is responsible for attending to those requirements. We distribute those responsibilities -- expecting the organization's dynamics to more or less derive from that distribution.

So far so good. Then the fun begins: people actually start doing things, and on any given day the cause-effect relationships of what they do to what they accomplish is most of what we ever think about -- except of course for considering the value of what got made.

Between the resulting shortcomings and the advantages, the unnecessary and the useful, we make most of our judgement calls about what should continue "as is" and what should change.

The big hypothesis is that the model we started out with will generate sufficient redeemable value, if only it is executed vigorously enough. We're experienced enough to recognize that there will be obstacles, but to get around them or through them, we're willing to redesign the way we meet the requirements.

How much of that flexibility is a good thing?

I.

Most businesses initially take a pragmatic approach to flexibility that looks at whether results seem to be proving the prevailing method of satisfaction. The habit: do more of what works, less of what doesn't, and look mainly for external indicators that something different should be done.

The "performance" mentality is driven by pragmatism. But what has also developed during the last five to ten years is a perspective that holds the entire enterprise responsible to a community of stakeholders -- which expands the range of external drivers and, correspondingly, requirements.

In some arenas, this new perspective argues that the broadened scope of responsibilities actually increases the likelihood not of episodic performance but of sustained performance. The intuitive logic of this is as follows: as an aspect of competition in a hypercompetitive world, it's too risky to alienate or disrepect any stakeholder of significant influence -- namely, one who has the freedom to take their support to a different business (such as customers), or one who has a critical opportunity to undersupport their host (such as sponsors and employees). Performance is therefore seen as the result of stakeholders being motivated to beneficially cooperate in their provision of a hospitable environment for the business's competitiveness.

Environment? As represented by models such as "balanced scorecard strategy maps", stakeholder cooperation means logically promoting desired outcomes by chemically reacting in more or less the same alignment seen in a value chain. This reaction is casually thought of as a "process" because it represents cooperation as interdependencies -- and then represents interdependencies as a set of serially productive influences. If A then B; if B then C; etc. But a proper understanding of the influences is that the "links in the chain" are actually dimensions, co-existing and intersecting at all times, creating an operating "space" within which the organization tries to find, extend and orientate itself.

In contrast, a "governance" mentality is a more functional outlook than environmental. Closely related to the problem of methodological quality, governance argues that the organization must execute systematically but that its system cannot be managed without enforcing limits on the complexity of its internal interactions. As opposed to the competitiveness that is the ultimate concern of the performance perspective, the governance perspective is ultimately concerned with the effectiveness of the organizational structure in its given configuration.

So what is the argument about effectiveness that governance makes?

II.

Three thoughts lay out the governance view on effectiveness.

(1) Governance and Performance share a strong concern with impacts, but where performance looks at impact from a benefits point of view, governance looks at impact from a risks point of view.

(2) Governance distinguishes effectiveness from impact. "Effective" means that a certain way of doing things is acknowledged and desired for the predictability of its effect. The concept's true significance is in its use for identifying and thus selecting functional options according to a pre-measured balance of value versus risk. (Not all value is beneficial; value is identified as a significant difference, but benefit imposes the requirement that the difference is relevant.)

(3) Governance focuses on the likelihood of the organization's functionality being systematically coherent enough to maximize value while minimizing risk. It's natural elements of disciplinary intelligence are architectures, policies, and approvals -- all of which organize constraints on demand.

Performance, in contrast, concerns itself with "efficiency" -- in terms of how much input is necessary for a given level of output "on-demand". Performance doesn't expect governance to work on efficiency.

But what performance sometimes forgets is that the kind of capacity made available as input (to demand fulfillment) is a product of governance. Poor governance can easily mean poor (or unreliable) input.

In real life, not just in theory, performance's demand on capacity has not been a good thing for businesses lacking governance. The most notable consequences include corrective movements such as Sarbanes-Oxley and the crackdown on software license violations -- as well as gutted share prices and other industry news headliners. Less notable as general news are breakdowns like post-facto productivity failures in mergers, missed time-to-market, or violations of contracted service levels. To an important degree of frequency, these outcomes spring from innovated and improvised execution that has been directed yet disruptive, dedicated but ultimately incoherent.

Governance implements a certain way that real-time functional capacity is produced -- in the same way that fitness and technique combine to power an athlete's responsiveness to opportunities and threats. Ideas, strategies and plans are based on confidence levels in effectiveness.

III.

Governance focuses management on effectiveness by forcefully modeling execution as opposed to just process. Execution is dominated by the decisions that occur before action is taken. Process models assume a certain range of circumstances, but processes must be invoked. Execution is a management function establishing the decision that activates a process. Whether formulaic or improvised, execution precedes process and is primarily attentive to the circumstances that present or argue for the alternatives in hand.

Governance is concerned, therefore, with the quality of the decisions, and with preventing execution from being displaced by process. Here, decision quality refers to the risk/value balances that establish response-capacity on terms predictable by all key stakeholders -- and execution intends to manage impacts and help build benefits accordingly.

The illustration below describes how governance aligns influences on operational behaviors in a way that aligns the generation of impacts with the concerns of stakeholders. As shown here, the key feature of governance is management's attention to control. But the influence of governance pervades several layers of functional predispositions. An important property of the arrangement as illustrated is that it also establishes the semantics for discussing governed response-capacity -- on each layer and in the relationship of the layers to each other.

These semantics do not "cascade" -- not in the sense that the meanings on one layer are derivative of meanings on another layer. Instead, they distinguish what it is about each layer that is most relevant to controlling response-capacity for the best balance of risk and value. As a result, the various layers are logically complementary in their overall influence on the functional coherence of the organization. That is, under governance, the impacts of individual functions do not work at cross-purposes, making response-capacity more reliable under demand.

Posted by Malcolm Ryder at 6:09 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

February 17, 2006

Executive Agenda for IT

In the diagram below, we have a bird's eye view on the major business initiatives reconfiguring the management of the enterprise's reliance on the IT infrastructure.

The view identifies that the key high-level motives of the organization are related in certain ways.

The enterprise wants to maximize the value of its autonomy and identity through decisions and actions that:
- differentiate itself in the market,
- optimize its modes of establishing impact and presence there,
- sustain the mechanisms that it uses to do so, and
- control the dynamics of its organization's internal makeup and external behaviors.

These possibilities are systemically related to each other. That is represented by the perspectives that are used to monitor the general states and conditions that presuppose the enterprise's health and/or growth. These perspectives -- governance, performance, architecture, and security -- collectively describe the approaches and models for monitoring the enterprise. The general understanding sought is of whether the way the the organization has chosen to structure itself and to act is viable for achieving its intended goals in the environment it has chosen to inhabit.

Also shown in the picture is the prominent place that stakeholders have between processes and performance.
Likewise, the key intermediary position between security and processes is typically occupied by policies.
The chain of influence formed by their inclusion explains how security is linked to performance -- meaning that the enterprise continually must balance the opportunities to which it commits against the constraints that it can recognize.

For the time being, though, this discussion focuses on the chain of influence that runs between the enterprise's two more overtly discretionary states. Governance and Architecture are both highly complex but they are also more fully synthetic designs than are security and performance, because they are less dependent on external forces to realize and maintain their intended design. As such, they are closer to the issue of the competency and maturity of the organization that can be established directly by management. The picture above expresses the target competency and maturity through identifying issues such as that standards mediate the dependency of processes on infrastructure, or that change mediates the production of infrastructure from architecture.

Taking this picture as a bird's-eye view on the top "surface" of the enterprise's structure, what lies underneath are layers of composition, for example such as "assets". The picture shown here allows us to consider enterprise assets in terms of each motive, perspective and linkage illustrated, detecting discontinuities and strengths of impact. While financial evaluations, functional evaluations (which include intangible assets), and physical evaluations of assets are already three ways to understand how assets become enterprise resources, we see more clearly in the picture here the circumstances in which any of that matters. Likewise, operations, relationships, and strategies are each layers to be interpreted.

The presumption of the different underlying layers highlights that the terms shown in the picture are necessarily abstract -- but it is that very abstractness that allows us to understand that they influence each other in an "essential" way, not just a circumstantial way. Understanding the enterprise from this model is mainly an act of interpretations. For example:
- From an organizational viewpoint, it's not hard to see the organization defining itself in terms of the linkages such as rules, systems, services, etc. by which it institutionalizes itself for attending to the primary motives.
- From a practices viewpoint, it's not difficult to understand from the picture things such as that compliance is a management responsibility that derives from the influence of rules, policies and requirements.
- From a disciplinary viewpoint, BI and BPM have evident locations and sensibly share influence on agreements or "contracts" by discovering and then formalizing the conditions for assuring appropriate deliveries.

While the abstractions and their interpretations cover a wide range of management phenomena and business objects, we'll always eventually wind up back at the huge reliance that the business has on information technology in order to just stay on the playing field. As a result, it is appropriate for IT executives to interpret IT plans, operations and impacts with this same picture of the enterprise, acknowledging that the portfolio of IT implementations can be evaluated for its completeness and effectiveness by considering how much support is being generated for the alignment and balancing of the items in the picture.

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

February 11, 2006

Linking Economy to Profitability

After a five-year pendulum swing of spending to cutting to spending, we've managed to stretch across four chapters of the IT-Business relationship: Y2K, dot.bombing, BackToBasics, and now Compliance Versus TheTopLine.

In these chapters, the story of transitions also features patterns overlaying other patterns.

For example, over the phases, we'd see that:
- the role of an IT infrastructure was swinging from being a risk factor to a success factor, back to risk, and back again to success. Meanwhile...
-The business model credibility was swinging from supply-chain angst to demand chain angst, back to supply, and back again to demand.

With patterns like those to find and juxtapose, there is plenty of room for examination of cause-effect relationships in how technology evolution and architecture may have precipitated new phases or ended them.

No question, this examination must necessarily acknowledge both intended and unintended effects. Business reliance on IT is a double-edged sword and, as shown with space exploration, we get to know how to reach a place too soon-- but only later how to stay there, and sometimes almost too late.

Yet, respectful of the need for wariness, we can honestly look at each of the aforementioned phases and, with the clarity of 20/20 hindsight, see for each one the gigantic "DUH!" that shouldn't have had to be. Obsolecence, irrational speculation, anorexia, and opacity if not arrogance... all of them butt-kicking poisons from the business side, not the IT side.

Because of that, where the topic is "intention", there is another big story, too, about the glacial maturation of what must be considered "business intelligence" (BI). Although at the moment mired in the learning curves of collaboration and analytics, BI's ultimate goal of achieving a sufficiently comprehensive perspective is perhaps represented most clearly by models such as Kaplan and Norton's Balanced Scorecard and European systems for systematically including the measurement of intangible assets, such as Karl-Erik Sveiby's Monitor and Juergen Daum's. At any rate, the rush is on for businesses to actually get smarter through intelligence -- with the twist being in the emphasis on having the right kind of smarts.

So, lessons learned: while IT makes action almost too possible and makes info almost too widely available, these are relatively intrinsic qualities of IT -- characteristics that have the great potential to simply erupt without regard to management, and therefore are not reliable barometers of business value in IT. In turn, that means we can't build value management on the basis of those characteristics.

The real issue for management is not to "enable IT" to do those things but instead to harness and leverage IT's innate ability to be an enabler itself. Business management is the source of return on IT investment.

In that light, some interesting points surface:

- The characteristic dimension of the business focus on IT management is, except for professional developers, not technology development!

- Neither, despite all the rage and benefit, is "business-IT alignment" the essence of IT management's focus on the business; that is really a business management issue.

- However, abstracting and separating the business and the information technology, the common challenge of managing IT is that IT's impact on business activity is so intense. In IT's role as a business "enabler", the critical success factor is the degree to which IT impact organizes the business rather than dis-organizing it.

Business management must step through the logic of that success. The logic has at least these three pillars:

(1) From the business perspective, for IT to be nutritious and non-toxic, the basic business need is to deal with what it is about the business that IT aligns and how IT does that.

(2) The responsibility for managing IT's role belongs to the business, not to IT. Responsibility for appropriate production within the role belongs to the IT management organization.

(3) What business needs IT to do in the business, just as business needs other functional elements to do, is to align economy and profitability, so that having one of them doesn't diminish the other. The way IT does that is to optimize capacity.

I.

The way business uses IT for optimizing capacity is by modeling business management of IT's impact through processes and portfolios.

IT inherently offers the kind of speed and scale with which a business must build and sustain capacity in today's marketplace. With capacity as a mandatory "given":
- Processes are responsible for economy versus capacity; and,
- Portfolios are responsible for profitability versus capacity.

Managing the contribution that IT makes through processes and portfolios allows IT to align economy and profitability through the organizing of capacity.

The huge top-level significance of that observation is in its implications for strategy and change management. Strategy presumes to model the competitive advantage that the firm can capture from perceived opportunity, while change management presumes to stabilize organizational resiliency and thereby keep the business positioned for opportunity. But in the effort to balance risk versus value, strategy reflects demand, and change management reflects supply, while neither must actually include financial optimization to be logically valid. The fact is that they both are simply designs that are fully able to get "their" jobs done while being benignly neglectful of financial stress. The organization actually has to figure out whether it can use these designs, but if it can't use them it doesn't mean they are broken; rather, just inappropriate.

Thus, with IT being such a dramatic enabler of both strategy and change, managing IT should in particular target helping to fit the strategy or change to the organization's terms of self-sustainability. In this regard, Process helps ensure that capacity is effectively useful, Portfolios help ensure that capacity is effectively directed, and IT supports both of them to get it all done.

II.

One analogy for this is that capacity is the "stored energy" or "battery" of the business. IT is what charges the battery. Consumption of that power is where processes do their work (economy), but the application of the power is where portfolios do their work (profitability).

By another analogy, processes make capacity into skills, and portfolios make capacity into value commitments. Furthermore, between those two, management creates behaviors, from which actual outcomes derive. Since the behaviors can either propagate or negate the potential of the skills to address the commitments, the benefits of skills (economy) may or may not apply to the opportunity represented by the commitments (profitability). Business management, through generating behaviors, makes the link, using decisions to deliberately leverage the skills for the commitments. IT supports that management, by literally incorporating the decisions -- that is, by making them "actionable" (functional) and thus producing behaviors.

In short, IT must produce resources; managers must deploy them, and the business must commit them. This perspective guides the assessment of IT's relation to both performance and return on investment. IT-generated capacity can give managers of business behaviors more options, but the value of the capacity is not created by IT -- rather, by the business modeling of both the consumption and commitment of the capacity. High performance presumes successful execution of good models, but meantime the models must be relevant to the strategy. Finally, strategy must be sensitive to the possible capacity that IT can generate, without arbitrarily "assigning" value to the possibility.

III.

In what follows over the next several iterations of this document or in other followups, we can illustrate that concept in more ways, as well as more specifically. For example, business process management (BPM), business intelligence systems such as configuration management databases (CMDBs), and performance knowledge systems like operational performance management (OPM) bring implementations of information technologies to more directly bear on the model-oriented management that optimizes capacity.

But the immediate general statement to be made is that the business needs appropriate capacity to address its desired opportunity; and it uses IT to provide itself with not just capacity in general but specifically with appropriate capacity.

Understanding business from an IT perspective is of vital importance to IT providers who must come up with useful resources. In that regard, superior architects power superior IT providers.

But more important is the flip side: understanding IT from the business perspective means understanding what business management decides to do with IT. IT management must take its direction from business management. The directions it takes are mapped out in processes and portfolios.

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

February 10, 2006

Pointing The First Finger, Having the Last Word

One of the more interesting opportunities to demystify organizational ineffectiveness rests on turning over a common assumption that Authority should delegate Responsibility.

In a revised view that brings operational discontinuities to the surface before they do their damage, organizations should consider having Responsibility delegate Authority.

Responsibility requires explicitly committing to performance levels that are critical to the welfare of an organization's clients and stakeholders. When the stakeholder view of performance is itself explicit to all members of the organization, authority can be a flexible tool dynamically distributed to where and when it is needed most.

Members of the organization should be encouraged to identify what they can do to contribute to the organization's successfully meeting the responsibility; thereafter, the operational issue is understanding when their actual opportunities to contribute should be solicited and/or approved -- in other words, authorized.

Distributing authority is the main purpose of Approvals. If approvals are designed correctly, they are based on a set of priorities based on rules and requirements that represent the stakeholders' best interest and guide the interpretation of real-time events versus. Formalizing the understanding of these interests is where Policy comes in.

Obviously this also brings up the issue of what stakeholder is being represented -- consequently it is easy to appreciate that there may be multiple policies representing multiple stakeholders. This is presumably good for the stakeholders, but it is also problematic. For example, customer-oriented policies may overlap supplier-oriented policies in some repects but conflict with them in others. Since there is a greater variety of customers than suppliers, the chance of this happening is not insignificant. Emphasizing this point: anyone who has been caught in an "unsolvable" customer support problem, where multiple support parties cannot agree on providing a successful response, already knows that the likelihood of conflict is very real. This means that policy reconciliation is important to be able to pursue, and it needs to be timely in order to be considered effective.

By example on a grander scale, the breakdown of cooperative recovery in disaster situations such as the Katrina Aftermath exemplifies the weakness inherent in the system of authority delegating responsibility. This article from the New Orleans Times Picayune spells out the typical complications. In the story, the presumed top-level responsibility is to manage levees to protect the city from future flooding. But the attempts to align parties to the responsibility are conflicting with the current distribution of authorities (which have not issued from the responsibility). This current setup finds the practice of "standing authorities" delegating responsibility, with the result that the levee protection appears to remain uncoordinated. Excerpt:
[Republican Representative M.J. Mert] Smiley, whose district includes Livingston Parish, told Boasso that local-level leaders had opposed being part of the [proposed consolidated] authority “because we will never benefit in any form from your bill.”

In essense, that party refuses to accept the high-level responsibility, leaving it dis-organized and, even worse, ripe for competitive blaming should future flooding occur.

But let's keep that in context. Policy-based granting of authority also presents the issue of who should be interpreting approval requests, and who should account for compliance to approval standards. Since the policies and rules already set the key terms for granting the approval, approvals per se do not stem from the interpreters. However, in actual practice, authority based on the approval mechanism is granted by virtue of the interpreters. Who are these interpreters? Administrators and executives.

Thus we can see that to avoid dis-organization, what an organization needs administrators and executives to do is to dedicate themselves primarily to promoting acceptance of the high-level responsibility that represents the stakeholder to the organization. From this predisposition, it is far more likely that the resources actually resident in the organization can be tapped at far more depth and variety than is usually done. Organizations that enjoy the idea of being "agile" and "adaptable" must understand whether their basic premise for granting authority internally is actually productive or counter-productive.

In achieving that understanding, another key consideration will need to be the ways that processes currently distribute authority in competition with policy interpretation. As a proxy for approvals, processes can eventually hide the assumptions behind the decisions that the process enforces. This is actually being revealed somewhat dramatically through a new generation of business process management tools (BPM) that excavate rules from the processes and leave the rules bared to direct re-examination. Because of that, organizational behavior can be freshly evluated for how it connects the assumptions behind the rules to the demands behind currently respected requirements. Then we can adjust the assumptions, the connections, or both. Thus we can see how BPM works as an aspect of managing performance. The big opportunity is to improve alignment of the processes to the same responsibility that spawns policy and its approvals. That way, processes are more likely to productively support policy -- a "no-brainer" improvement objective in the face of challenges such as regulations, competitive differentiation, environmental risk, and economic pressure.

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

February 9, 2006

BSM: Play to Stay

Sports analogies aggravate a lot of people, maybe even more than military analogies do. But why do they keep coming up anyway? Because at least in sports, the rules of the game make the court or field a laboratory demo of problems, at a scope and level of complexity that we can easily grasp.

It's easier to see the relationships between the elements:
- assets (such as players),
- configurations (such as formations),
- functions (such as manuevers and roles),
- processes (such as plays),
- outputs (such as positions and possessions), and
- outcomes (such as points).

It's easier to see discrete management decisions about each element. It's faster to observe whether the impact of the decision is short-term or long-term, slight or heavy. It's even easier to remember what worked and what didn't, or no less important what actual effect occurred as opposed to what expected effect occurred.

When a point in the game calls for a certain type of change or benefit -- that is, a certain need -- we look at how many of those elements probably need to be adjusted to respond organizationally with success. We feel like we can see them all at once.

I.

When we ask a losing team what happened, there are hundreds of specific things that they might cite. But in the big picture, every team knows before they go into the game that they will have to do three things.

(1) Not make mistakes
(2) Stay in the game
(3) Give themselves a specific chance to win.

Said differently, execution, priorities and opportunity are the three dimensions of winning. They are not hierarchical; but they are systemically interactive. If one changes, the others do too. The challenge: any one of them can change independently of the others, and when one changes, the degree of change by the others is not always predictable.

So, in the heat of the moment, when the team must mount a specific response to a specific need, the actual response carries the burden of all three dimensions. The team's "game manager" needs to understand the possible trade-offs involved in giving more weight to one thing than another. Execution, priorities and opportunity then look and feel like risk, strategy and advantage.

The "organization" of a business response is multi-dimensional and multi-layered in exactly the same way as is the team response in the game. Material and structural interdependencies are exercised in operational interactions -- and there is always a question of whether the networks of relationships are adequate against the real pressure of demand.

The adequacy of the interrelationships is a result of whether their components -- like links in a chain -- are all strong enough as a group to allow their collective effort to withstand the attempted intensity of response. What difference does a change to any one of the links, intentional or otherwise, make to the ability of the overall capability? Is it the same difference whether the response is a risk-response or a strategy-response, or a stretch for advantage?

II.

Business theory presumes that if the game keeps changing then the way to stay in it is to constantly regenerate advantages, because otherwise "the competition" will eliminate you. In effect, this suggests making intentional variety a big part of the game plan. But every business has some limit to its economy of scope that prevents it from basing its day-to-day health and competency on irregularity. This is because the business is, by definition, predicated on relationships with stakeholders. Managing the value and success of the relationship dictates that the organization have behavioral consistencies that require underlying operational continuities.

In the game of business, a business service is a managed and structural response to a requirement for supporting a need in a business relationship. (Why "structural"? In the same sense that services like the Army and Parcel Post are different from the Navy and Email: they shape organizational resources differently for action.) The purpose of the business in the stakeholder's world is to produce a particular outcome, and the business addresses that stakeholder with appropriate services to facilitate that outcome. The facilitation itself might be directed with emphasis on risk, on strategy or on advantage to the organization -- but regardless of which constraint it is under, its orientation is towards the outcome that the stakeholder needs.

The business service is itself operationally composed of interacting processes. The processes exploit some logical interaction of assets, configurations and functions -- often without knowing whether it has to generate that interaction from scratch or whether it is ready and available.

In the business game, when the stakeholder need presents demand, the business must "call the play" and execute it, relying on the presence, quality and coordination of the players in the formation to provide the real-time means for producing the required impact. It seem obvious when put that way, but that is precisely the point regarding business service management (BSM).

BSM brings classic "management" attention and intervention to the interdependencies that make logical, intentional production of appropriate responses reliable.

III.

Management always includes mechanisms for:
- visibility
- measurement
- analysis, and
- communication

which will be employed in tasks for:
- design
- development
- alerts
- control,
- evaluation, and
- change.

To put business responses under stronger management, the two major efforts in a BSM initiative are:
- to conceive and model business responses as services made of essential components and their relationships;
- to implement resources in a way that they are visible, sustainable and controllable as those essential components.

Complex? Yes. Controversial? No. Agreeing with the reason for BSM is no more difficult than is appreciating what kind of success a team would likely have if it couldn't keep the team organized on the field well enough to make the best use of its best players most of the time.

The play cannot be successful if:
- the maneuvers it hosts are not logically cooperative in how they influence the conditions on the field;
- the manuevers and their owners (the roles and functions) cannot cooperate effectively against the conditions without awareness of each other's dependencies and intent
- the formation (configuration) is not designed to position the manuevers for cooperation
- the players (assets) that incorporate the formation are not the right kind of players or are unreliably ready for the duty.

IV.

Since these ideas are nearly self-evident to any experienced manager of an important operation, why are businesses only now likely to find BSM as being a critical success factor?

First, the amount of work involved is quite substantial, given the investment already made in achieving repeatable accounting for business events along the lines established in earlier business eras. Attention has, for good reason, been elsewhere. Expertise for transforming to each facet of BSM has to coincide with available time and cost -- and the appropriate knowledge management was not until now "on top of" the ways to make BSM initiatives viably and meaningfully incremental, giving it a plausible entree.

But another answer is that companies are not only just now practicing "BSM"... What has fundamentally changed is the opportunity to practice it both cost-effectively and pragmatically, rather than mainly conceptually or experimentally in implementation guidelines or enlightened point-solutions. Technologies that support management tasks have dramatically emerged and/or matured, in ways that are compatible with service modeling. Prior to these developments, management teams knew that the interdependencies within stakeholder-facing business activities had critical influence, but there was relatively little that could be done about it in both a rapid and enterprise-wide fashion. But now, the proven managerial ability to broadly affect those things in real-time makes it virtually mandatory to do so, since having that ability eliminates the business case for accepting the risk, inefficiency and opportunity cost of not doing it.

A last, but not least, answer is that business paradigms have changed with the environment. Just as CRM was not in the regular vocabulary in pre-internet 1989 but dominated 2003, another re-oriented perspective on business dynamics is settling in, driven by more attention to managing performance than to managing costs. BSM promotes much greater alignment of the architecture and infrastructure for business processes. This improves resource cost-effectiveness, but more importantly it improves responsiveness, through which more advantage can be developed and sustained, producing better top-line outcomes at lower risk. Enterprise architects have argued this exact point for over twenty years; but the fire that has been lit in modern businesses is awareness of the gigantic liabilities of unmanaged change. For many businesses, processes actually put a leash on the danger cost posed to execution, only to reveal the danger change poses to investments. Through business services, the company makes responses rationally manageable for quality and cost levels. But the change that is imposed on the firm's current state by multiple stakeholders including governments, partners, customers and employees ratchets up the requirement for fast reconfigurability against error and obsolescence -- which means visibility and control of the service's many moving and interlocking parts.

Few teams would expect to win with a disorganized roster. Few businesses of any significant size or durability would rest their information operations on an unmanaged network. Likewise, where the kind of functional resilience and advantage that a business needs is dependent on capabilities that only come from savvy complexity, BSM must be instituted to stay on the playing field.

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

February 6, 2006

Surveying IT Governance

The concept of governance in business is not an overly complex concept, but its implementation can be dizzyingly elaborate. Surveying it very broadly, we find that it variously and passionately refers to accountability, alignment or control. However, these references are not competing with each other but instead reflect the richness of the problem that we can summarize at an even higher level: "management".

I.

Ever since Frederick Taylor, the science of good management has been characterised by a small number of factors all related to the same idea -- demonstrable effectiveness of resource, or what sometimes is just as well called resource optimization.

In order to optimally utilize resources, a few critical success factors of their management always pertain:
- definition of their conditions (clarity)
- measurability of their application (certainty)
- direction of their effort (relevance)

Over the years, there have been many ways to interpret and discuss each of these essential scientific qualities of the management effort -- arguably none more persistently than accountability, alignment and control. Typically, different particular roles in the organization's community -- such as sponsors, executives, operators or clients -- host and promote different interpretations, according to the responsibility within their respective roles. But this does not mean that they are separated or indifferent to each other. All interpretations can be inspired by some of the same key business issues -- such as whether resources are economical and why; whether outcomes are improvable and how; or whether advantage is sustainable and where.

Nonetheless, particular blends of roles and issues bring distinct sensitivities, or perspectives, to the observation of the resource impact on business performance. When it comes to handling IT as a business resource, the perspectives interpret topics like economy, improvement and advantage by assessing things to be managed -- for example, characteristics of the IT resource inventory like supply, configurations, and distribution; or characteristics of the IT resource deployments like capacity, processes, or access.

Having multiple perspectives is a good thing. Any one of them will usually catch something of importance that the others missed. For the sake of planning, these "catches" bring up interdependencies -- for example between supply and capacity -- that affect or exemplify the logic of expected benefits versus risks.

Revealing such logic is a breakthrough. The collective effect of these perspectives is that through their sustained diligence, they bring a regular visibility to the dynamics behind whether the resource impact is:
- good or bad (preferred),
- intentional or unintentional (prescribed), and
- correct or incorrect (allowed).

Formally interrelating their sustained diligence, Governance brings those three "dimensions" of impact to evaluate and coordinate the state of the business operation. The effectiveness of that is largely in revealing and reminding that each dimension can develop ad hoc and/or independently of the others, but that they need to be blended into a compatible set of conditions for supporting business goals. Decision-makers and designers of all kinds throughout the enterprise quickly engage the views, because in particular those two roles must assure that the business value of the resources emerges systematically in operations.

In other words, the effect of IT Governance is to institutionalize the business management of IT.

II.

Emphasizing a proactive stance, it is easy to appreciate that this effort at "managed assurance" is most often projected as "control". Maturing the assurance effort into repeatable and reliable success strategies, practitioners have collaborated for years on organizing and sharing their learnings by creating frameworks that:
- memorialize and increase awareness of significant assurance opportunities,
- guide selection and decision of priorities and methods, and
- establish terms and conventions for monitoring and analysis.

However, behind these frameworks for success, there are varying nuances to the idea of "control", ranging from influence to facilitation to command. Meanwhile, particular roles and circumstances generate a variety of individual business needs. Together, as opportunities and catalysts, these nuances and needs have combined in different ways to spawn different frameworks that all continue to be cultivated.

Over time, different frameworks can each grow out to a point where they overlap others; but if these frameworks are to provide reliable guidance, their overlaps need to be reconciled to ensure that the various frameworks do not work at cross-purposes, despite the intensity and complexity of how elaborate they may become.

Before worrying about that, perhaps there is an even more pressing problem in the organization: a seriously imbalanced mix of individual control efforts already actually implemented for the many aspects of IT activity that ought to be governed. Today, that imbalance may feature incompatible, inconsistent and/or variously unsustainable approaches - in which much of the organization is already invested financially, mechanically or politically. Aside from choosing and trusting a framework to make sense of that variety and envision "leveling it out", there is the substantial pragmatic challenge of herding the cats.

The current wisdom on attacking this problem is that governance should be instituted "top-down" in the organization. A key virtue of that approach is that it minimizes the chance that adopting governance will suffer a "two steps forward one step back" syndrome, because authority and accountability are more rigorously enforced.

But a key challenge in it is that governance itself must be done in the service of the type of progress that the overall business needs. DIfferent parts of the organization contribute to progress in different ways. And different organizations often need to make different kinds of progress.

This throws attention towards the idea that IT governance should not be one-size-fits-all. Put differently, IT governance should not be just a set of "controls that makes alignment for business accountable" -- rather, IT governance must be a competency that demonstrably solves the right business problems.

III.

One key to demystifying adoption of practical IT governance is to first see, in more generic terms, what it is that is being addressed.

We have the range of carefully labelled starting points including "control by" certain parties; "accountability to" certain parties; and, "alignment for" certain parties. But while these may indeed indicate the particular involvement of different roles, the first thing to consider is the commonality of their interests.

Much of the commonality can be expressed and contained through explicit policies and rules. These share the ability to consistently regulate decisions about real-time events -- and it is vitally important for multiple co-operating stakeholders to draw confidence from that. For most organizations, this issue of aligning all decision-making and production design to some standards is the major driver of adopting IT governance. It is a direct response to the need for reducing the "collateral damages" of the organization's complexity -- such as operational costs, errors and liabilities. In effect, standards or regulations represent the party for which the resource utilization is aligned. In the abstract, this party might just be be the "desired future version" of the current organization. In the concrete, it might be a customer, sponsor or other (like the government) stakeholder who has enough immediate influence on opportunities or constraints to be able to dicate the terms of operation. Here, for example, we see Sarbanes Oxley, ISO9000, CoBIT and other directives in force.

Likewise, consistency results from adopting widely-proved guidelines for essential management practices. While "best practices" are propagated because they correlate with successful outcomes, the true value of adopting them is that they include the highest degree of validated measurability -- which translates into predictable improvements in manageability. As such, they need not replace already-successful measurement-based management -- but for managers under excessive pressure from complexity, they accelerate the implementation of low-risk comprehensive measurement. Here, for example, we see ITIL, CMMI, and other instruments featured prominently.

But despite the meaningful differences between those distinct example directives above, they all have the same practical goal: managing the business's preferences, intentions and allowances regarding resource selection and deployment against demand.

This practical commonality doesn't make the challenges easier, but it reminds us that an organization's existing abilities and initiatives for those same management tasks should be pointed at the impending or mandated policies, standards or guidelines. Why? Not just as enterprise housekeeping but, recalling the primary management theme of effectiveness, so that business progress is more strongly enabled. Before that re-orientation is done, we don't know what else new is necessary.

IV.

With the more generic overview in place, it is easy to appreciate the scope of reasons and benefits usually described within the initiative for IT governance.

"IT governance is an integral part of enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization's IT sustains and extends the organization's strategies and objectives." As seen on its website, the IT Governance Institute (ITGI, at www.itgi.org) continues that introduction to IT governance with a short checklist of things that governance must cover:
- ensure that "IT is strategically aligned with the business and delivers value, its performance is measured, its resources properly allocated and its risks mitigated."

The scope of coverage indicates that the business reliance on IT requires broad organizational accountability. This makes sense particularly in the sense that the business is a customer of IT. But the nature of the actual governance problem is better suggested by the idea that IT utilization is aligned for business. In this latter sense, business is a function, and as the format and value of the function changes over time, governance must deftly support realignment of IT utilization for enabling and supporting the function.

In other words, without diving down into the weeds, this functional outlook gets more directly to the matter of how governance accomplishes what it should accomplish.

As a high-level frame of reference for thinking about governance, the following idea makes a basic assumption about the business's "return on management" -- namely, that managment is given the day-to-day responsibility to take the organization from the current state to the "planned to be" state.

In order to do that, management must generally focus on achieving clarity, certainty and relevance of the resources it handles. But it must specifically focus on influencing resource impacts by wedding the clarity (definition) to the utilization. We tend to think of governance as being about "how things are done," but the closest examination of what we mean by that shows we are more considering "what things are done". The decisions about those things tend to focus on whether they are appropriate, and on what they require.

Consequently, the crucial work of coordination that governance can execute revolves around managing in terms of the "As Intended" Definitions of resource utilization. These are covered in three broad areas that hierarchically comprise the value chain for resource utilization.

Top-down, the business value hierarchy is:
Value: Objectives and Portfolios that align resources to needs
Fit: Architecture and Standards that align resources to requirements
Quality: Assets and Projects that align resources to purpose

As a result, we can see the parallel impacts cascaded (top-down) as well:
- Performance;
- Risk; and,
- Capacity.

Understanding governance from this high-level functional perspective has three major advantages.

1. It is less confusing as to where and why issues such as costs (financial controls), mechanics (processes and support), and politics (decision rights and organization structure) fit into the scheme of things.

2. It also becomes more obvious that the uniqueness of any organization -- which is readily detectable at the level of costs, mechanics and politics -- in no way divorces it from the general opportunity to govern IT effectively in accordance with general principles.

3. Finally, it is more apparent that the multiple roles in an organization can identify goals and opportunities to collaborate on improving existing governance capabilities incrementally, while not violating the interest of a top-down view of enterprise-wide consistency.

IV.

Governance practitioners and supporters take advantage of the last point above. Their challenge is to figure out where to plug into governance, and why. This shows up on both the "supply" side of the it industry and on the "demand" side.

For example, Microsoft focuses on operational excellence, yet to establish a business case for its solutions it talks about three things to consider: save more money (deployment), make more money (productivity) and keep more money (efficient support). These benefits, to be produced with Microsoft functionality, come with legal and financial restrictions on the availability of Microsoft technology, and corporate stakeholders (both internal and external) place further boundaries around how production is allowed to generate the benefits. Governance, through its frameworks and models, is instrumental to connecting the allowances for supply and capacity to the allowances for production and impact. Decision-makers and production designers must actualize the recommended connections.

On the demand side, distinguished practitioners such as CIO Emeritus Len Tenner of Hewitt Associates caught what might be the single most important observation about IT governance, as introduced by authors Peter Weill and Jeanne Ross in their book "IT Governance". Said Tenner in his recap: "effective firms must customize IT Governance to match their organizational approach and business goals."

But this just reminds us that the hands-on challenge of doing IT Governance is for the organization's leaders to define, produce, deliver and support governance itself -- an ongoing, multidisciplinary, cross-functional effort at developing and maturing a competency.

Certainly not the last definition of that competency, but a pretty exemplary one, is from deep inside an office in a department of a non-profit organization whose success is also increasingly reliant on effective IT:

"IT Governance - A structure of relationships and processes to direct and control the enterprise in order to achieve the enterprise’s goals by adding value while balancing risk versus return over IT and its processes." (Austin Community College Internal Audit Office)

The message in offering that citation is that the phenomenon of IT Governance is not about an industry, a business model, a market segment or a product, and not even primarily about technology. Instead, it is primarily about a management discipline focused on a business resource.

The involvement in IT Governance must be championed not by "business people versus IT people", nor by "executives versus producers", nor "auditors versus employees". Instead, it must be championed by managers at all levels of the organization.

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

February 1, 2006

The Enterprise Logic of IT Investment

Managing the enterprise features such a high degree of complexity because by its nature the enterprise tries to grow amidst enormous possibilities of internal and external change.

The internal health of the organization, and the external growth of the business, both rely on great systemic coordination.

The overall view of the related dynamics is often shifting or obscure, and in learning to cope with the variations the enterprise focuses on how to adjust to the moment in ways that aim to sense future conditions and engineer future events.

The combination of increased awareness and increased ability protects its prospects for continued health and growth.

Visibility and controls are strong proactive correspondents to the desired awareness and ability. The enterprise's proactive stance on protecting its future opportunity is reflected in its vocabulary and institutions. It propagates its stance mainly through communications and procedures, and it formalizes those means in the way it promotes and tolerates management. But then it defends that formalization, and implements it, by deploying IT.

The high-level description of that enterprise management is fundamentally the same for most enterprises. In the following picture, the essential storyline of enterprise action is shown as a matrix of management topics that describe how the enterprise systemically associates its action with its expected challenges and desired outcomes.

Notes:
All of the terms in the illustration can be prefaced with the word "business". This is because the purpose of the idea or concern that each term represents is to support the business. As an example of how this applies, however: if "requirements" in the IT arena are under consideration, this illustration is about what the business needs to get from those requirements being handled in IT.

1. The semantic separation of Performance, Execution and Operation is crucial to understanding how the organization and its stakeholders recognize opportunities to affect the future. The table shows that each perspective has its own type of goal. Understanding the differences between the types of goals is superficially easy, since they tend to come from different sources. Only for example: standards may come from experts; requirements may come from partners or customers; and targets may come from executives or investors. If a change occurs to one of these goals, the point is to realize where it will have impact. Change to Standards will affect production. Change to Requirements will affect execution. Etc.

2. The Benefits column shows what the activity is intended to be all about. Additionally, it shows the critical linkage provided by process management and portfolio management. These two disciplines create the channel that converts operational investments into managed impact on business performance. (Shown in the Benefits column, the two disciplines are placeholders for the artifacts that they also represent; the enterprise typically wants to achieve and improve processes and portfolios as negotiable products or holdings, not just use them as conceptual models or tools.)

3. The difference between Production, Progress and Achievement is as follows: production is the shape of the activity; progress is the output of the activity; and achievement is the significance of the output in the context of what the organization is trying to deliver to its stakeholders. All three of these are factors that may be individually found "positive" or "negative" compared to expectations or plans. But that status may or may not directly correlate with the actual effect that the factor has on the economic prospects and risk prospects. The "systemic" nature of the enterprise is that success on one level increases the likelihood of sustainable success on the level above it. Negative factors decrease the stability of the enterprise, making it less able to proactively maintain suitable levels of desirable influence on future conditions.

4. Economic Prospects can be understood both literally and figuratively. To make this point clear, first assume for the sake of argument that all activity is about dollars. In this case, economy is about dollar consumption; capacity is about how powerful the available supply of dollars is versus spending needs; and profitability is about how many more dollars of better-than-previous-power have joined the supply. But in a second case, assume that all activity is about a different asset, such as "knowledge". In this case, economy would refer to the percent of the retained knowledge that has frequently high practicality; capacity refers to how much of it has frequently high relevance; and profitability would refer to how much more of the knowledge is usable by how many more users, compared to a previous time or population.

5. Risk Prospects identify the primary source of challenge to what the activity is trying to control. There are two kinds of comparisons to see here. One kind compares the Risk to the Measures, illustrating that the momentum and probable success of the as-measured activity is very sensitive to the risk. The other kind compares the Risk to the Benefit. The variability of the risk factors can alter the level of benefit and/or alter the degree to which the level of benefit matters to the economic prospect.

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

January 25, 2006

Selling the Change

You can lead a horse to water, but you can't make him drink.

The consulting industry that has built up around this challenge offers years of multidisciplinary research in its solution recommendations.

But in the center of the vast collective scope of the recommendation, a repeatedly confirmed synopsis appears, looking more or less like this:

- People have an innate sense of risk and reward, and they are willing to change their personal balance of them for a good reason.

- Giving people a reason to change requires more than just promising them additional tangible compensation. People want opportunity. The best opportunity you can give someone is support for them to be who they want to be.

- Part of that comes from clarity about what will be expected of them in a successful change. People need to see requirements that they feel are relevant and achievable. They need to see the difference between what they have already been responsible for and what they will next be responsible for.

- But the strategy for fostering change is to excite people about becoming a certain way or contributing themselves to something they believe in.

The excitement comes from communication. But the communication effort is not just information delivery.

Change envisions a future state and ascribes some "reality" to it by presuming that, on certain already manageable terms, individuals will make it happen. Communications to promote change must therefore answer some basic questions in a way that fosters the alignment of personal and organizational agendas.

That alignment revolves around two major concerns:
- What accountability is associated with the particular change?
- Do we believe the change is intrinsically do-able and worthwhile?

Those considerations are not in rank order here. Because they are each so basic, both concerns pertain to any given change. (But it's true that organizations more often change the way they tackle an unchanged objective, and less often change the objective itself. For that reason are the two concerns mentioned in this order here.)

As illustrated in the following picture, the connection of business vision to personal opportunity results from a "discussion" of the two concerns, in each of which the connection is logically fortified by the way key questions are answered. Negotiation to the answers may be more the rule than the exception.

Click here for enlarged image.

The above provides an overview of the key factors. Covering all of them is important, But getting right to the heart of the matter: for people to power the change, communications (as outlined above) must establish trust, visibility, roles and boundaries -- so that people feel empowered to take ownership of their decision to commit.

Violating those terms is a sure-fire way to undermine the motivation to change. As seen below, normal instruments of daily management need to be adequately focused on satisfying those terms.

In some ways these views are incomplete and have big spaces in them -- but if this much of the scenario isn't true as shown, then there's no reason to expect to be able to get people to change...

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

January 5, 2006

Infrastructure, Information and Innovation - Who's on First?

"Business improvement" is an easy ambition to have but often hard to act on effectively, because it is so vague. However, the beginning steps of defining it are well known -- they always include deciding what are the needs and requirements of the business.

Yet too often that yields to confusion bred by habitual thinking, political and religious energy, risk-aversion, and inexperience. Each of those different influences is a considerable threat to "improvement" if it distorts a constructive path of change. However, all of them can be dealt with through the same review of basics that help identify why anything should change.

The outcome of the review is clarity on what kind of change is most likely to constitute meaningful improvement.

I.

As a rule of thumb, needs are recognizable as what effect must be obtained from activity; requirements are recognizable as how the effects must be achieved.

This is how we can understand that even when "everything was done correctly", the result may be unusable or unacceptable. In such cases, the mistake is often that needs were not adequately translated into requirements because the nature (persistence, priority or timing) of the need was not strongly enough determined. This uncertainty allows the "wrong" requirements to be derived, because the requirements do not actually solve the right problem even though they drive downstream impacts inviting not only failure but the "law of unintended consequences".

Paralleling the importance of that distinction, the key difference between capability and competency is that capability addresses requirements while competency addresses needs.

Because of this difference, when "business needs" change it is the type and strength of competency that must first be determined.

On the other hand, business requirements may be changing even when needs are not, and this should be addressed with capabilty.

The message to the business improvement crowd is that the organization's leaders must confirm the right problem to solve before it decides "the right way" to solve anything.

Meanwhile, for managers the most interesting aspect of the relationship between needs and requirements is that an inability to satisfy requirements that support a need can actually force the need to change. That is, if a party's capabilities leave its problem effectively unsolvable, the party must then either reposition itself to make the problem irrelevant, or it must suffer consequences that will alter its circumstance in ways that most likely reset its agenda. Either way, the needs will have changed.

In effect, business actually predicates its success on "picking the right needs"... That is, its needs come from a position that the business takes in order to have certain advantages, and it typically organizes itself around the needs of the position. Thus, unless the position is intentionally changed, the business is actually reluctant to have needs change! This focus on a status quo encourages a mindset of, primarily, attention to planned capability over competency. But capability improvement will prove to be no more important than competency improvement.

II.

Business looks to "IT" to provide capability that is appropriate for needs. The business value of managing IT is in that it manages a "resource", which in this case involves managing both the quality and delivery of information and of technology. But the key responsibility of that management is not to select the "correct" information; rather it is to establish and operate technology that assures quality and delivery of information.

A strict understanding of that scope of responsibility makes it easy for us to identify that "information technology" is different from, but accompanied by, "information process".

Information process, for example, determines what information should exist, where it should exist, when, and why -- in utilization. Information technology is then employed to enact and defend those decisions. A typewriter doesn't decide what to put on the paper, but it enables putting the right thing on the page.

If we extend this idea by using customary business mantras, we ultimately also distinctly consider "information people". Information people determine whether information is valuable or not. They must determine which information (from that which is available) should be accepted, and what purpose demands the acceptance.

Information people operate with a chain of dependencies -- they need information process to make suitable information available, and process needs technology to provide practical information-supply. Thus each link in the chain offers an element of opportunity to the business activity relying on information. But likewise, since each link has its respective responsibility, a lack of capability can strike at any of the three points, disrupting their interdependencies.

Supporting the integrity of the chain requires a practice that addresses the risk factors especially pertinent to each part of the chain. These factors can differ radically from one link to another, and ultimately the approach to maintaining the chain's integrity is not just one of spot maintenance of the links but instead systematic and ecological balancing of overall stress.

Seen as the "requirements" arena, this approach has to be translated into a management practice. The practice must include -- and organize dynamic access to -- knowledge that spans the experience, expertise and expectations of the three points in the chain.

III.

That holistic perspective strongly affects how we understand the three most urgent management concerns of the business "performance" -- infrastructure, information and innovation.

In general, "performance" measures how much achievement occurred towards a target amount of progress. Ordinarily, management emphasizes execution of planned procedures when trying to improve achievement. But to really grasp the situation, we need to look at prerequisites for progress, understanding that execution simply exercizes the potential these prerequisites provide.

Infrastructure provides the environment in which things can get done, in the form of services and facilities that support processes. This makes information technology and infrastructure parallel concerns, but the components of an adequate infrastructure are clearly broader than just technology. Obviously, you cannot have a service or a facility without also incorporating decisions and procedures. The challenge is to coordinate the various success factors of a "service" or "facility" to assure their presence for users in the environment. (Thus, infrastructure all by itself already includes technology, process and people dimensions to manage.)

Information provides the description of states and events that distinguish what needs to be done. The decision about what needs to be done will matter not just because of its eventual outcome, but more because at any given time more than one thing might be do-able and the challenge is to make the optimal choice.

Innovation provides the opportunity to bring new solutions to problems and/or to solve new problems. This represents a party's ability to act beyond its previous limits, but on its own it does not automatically mean that there is a need to do so. Without context, innovation has little intrinsic business value, so first the challenge is to identify the context that represents a "necessary change".

Given the co-existence of these three problems -- assured presence, optimal choice, and necessary change -- a party must consider its ability to work on all three, which calls for both capacity and prioritization.

Capacity will involve both (a.) resources and (b.) the practices that direct and constrain their lifecycle. Practices will in effect generate the technology, information and people that are actually employed at any time for the purpose of business improvement (i.e., solving the three problems). Pragmatically, that overall employment effectively predetermines the capacity.

Priority will involve both (a.) importance and (b.) urgency. Urgency will be the bulk of the influence by which the business's activity shapes the environment in which it finds itself. Urgency is not about how fast and hard something is done. Rather, it is about how soon the party takes significant action on a need. Pragmatically, urgency doesn't make an action important; instead, the significance gives the urgency priority.

Resources, practices, importance and urgency are ingredients that must be blended into a solution for each of the three problems.

But to direct that blending, the right first move is to isolate what the most fundamental inhibitor of business improvement is at the time, and rank the problems accordingly.

IV.

For example, each prerequisite has a characteristic underying issue that dominates its intensity, persistence, and overall difficulty. That issue is a candidate inhibitor.

According to the basic purpose we've identified for each prerequisite:
- Infrastructure must work within the certainty of user demand
- Information must work within the complexity of the operating circumstances
- Innovation must work within the equilibrium of the environmental dynamics

Levels of certainty, complexity and equilibrium -- which can dramatically and suddenly vary -- must be consciously approached with an awareness of what kind of opportunities and risks they present to the business agenda. In that awareness, rating them individually and against each other as problems establishes a sense of what needs the most attention. Thereafter, the issue is to look at whether the existing capability to attend to a problem is already sufficient or needs to be modified.

This does not mean that each of the three prerequisites has a single unique issue to address. The reality is that each one (infrastructure, information and innovation) has its own flavors and ingredients of uncertainty, overcomplexity and disequilibrium that it may need to resolve.

But the business overview of the problems must try to reveal where the biggest bang for the buck is in directing its capacity and priority, and this takes the matter back to understanding the interdependencies that create the chain of throughput needed for the business to succeed with its agenda.

As businesses become more knowledge-driven, the view and prediction here is more systemic: if infrastructure cannot adequately address the level of demand, then information cannot adequately address the level of complexity, and innovation cannot adequately address the level of equilibrium.

Success looks different at each of the three different points, while success at all three points maximizes overall "throughput". This is the picture of business capability -- the ability to generate necessary effects in the required way. But what about competency?

Business competency exhibits the ability to produce what is necessary on demand, but it must largely concern itself first with being able to determine and understand what is necessary.

Necessity cannot be determined without a model that defines (a.) the intended effect of the business and (b.) how the structure of the business logically addresses the intended effect. If the business has decided what it intends to be, then it has a reference point for determining what conditions are compatible or incompatible with that intent.

This awareness may never even reach "perfect knowledge", but it doesn't need to be perfect -- rather only "good enough", for health and growth.

V.

Increasingly, business looks to "IT" to improve business competency. This is important in two major ways.

First, it represents a set of expectations of IT-based capability that may need to be validated before they can be considered reasonable.

Second, it becomes mandatory to distinguish but then logically relate "IT competency" and "business competency".

The idea that IT might "improve competency" is probably an unhelpful contraction of what should really be stated: "IT support of improvement in business competency." This way we initially (and properly) focus on how business competency is recognized, and then on how those terms translate into (business) requirements that IT can help to meet. To complete the thought process carefully, we finally describe how those business requirements compare to the model of IT activity in the business, and concentrate on aligning the IT model with the business requirements, so that IT's position has the "right needs" defined for decomposition into IT requirements.

Some may say, "but what about e-business?"

E-business, in the form of end-consumers using IT to directly interact with the business, puts more business pressure on the performance management of the IT infrastructure, but it does not fundamentally change the relationship of IT competency to business competency.

Instead, what is brought into high relief by ongoing e-business is the business's ability to position the IT infrastructure in a more valuable sustained position for consumers (business capability), along with the IT organization's ability to comprehensively support information process (IT capability).

However, the transformation from pre-e-business to post-e-business was a crucial demonstration of business competency in the marketplace, and the accompanying management reengineering of IT practice to incorporate the e-business needs is a parallel demonstration of IT competency.

How do we recognize the position of infrastructure, information and innovation in the realm of business competency?

As a baseline:
- Infrastructure calls on Architecture;
- Information calls on Predictive Analytics;
- Innovation calls on Prototyping.

These three disiplines share the common objective of designing operations for optimizing the two-way relationship of change to demand -- the two factors most critical to business survival.

Architecture, predictive analytics and prototyping all recognize change and demand as independent factors. Then they all attempt to identify the ways that change and demand affect each other -- and thereafter they provide direction (requirements) to the development and use of capability -- for meeting needs dictated by the influence (i.e., opportunities and risks) of the change-demand relationship.

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

December 9, 2005

Complication versus Complexity: getting Business Value from ITIL

Architecture is what you bring to the party when: (a.) what you want to build requires moving parts but (b.) the diversity of parts resists effective interaction.

Some may say that this is what engineering is for. But engineering determines how the parts should work together, whereas architecture determines what kind of parts should work together.

In that light, we can see that engineering and processes spend a lot of time with each other, organizing functions; meanwhile, architecture and assets spend a lot of time together, organizing resources. Both must make strong contributions to the whole. But it's not just the intensity of their contribution that counts. A special characteristic of architecture and engineering is that they are not about reducing complexity; instead, they are about reducing complication in order to exploit complexity.

Complication features lots of parts whose relationships inhibit the coherence of the whole. Complexity features lots of parts whose relationships enable the coherence of the whole.

I.

Within "operations", co-operation of parts is necessary for the same reason that it is in buildings: a structure is asked to enable functionality that requires its parts to support each other under the varying pressure of "customer" usage and environmental conditions. In operations, it's typical to see processes and systems as component parts.

In business terms, the support-problem that architecture addresses is a balancing act: there are constraints (or restrictions) on what parts are available, yet the blend of available parts must offer a way to provide persistent support of the expected business requirements. From the business perspective, this support is the operation's functional integrity, which depends on whether the quality of its parts supports the functionality demanded from the structure. The basic idea is not hard to grasp: in general, the components of an "automobile" are well known, but you can't make a good jeep from the parts that are best for a family sedan... When you need a jeep, even a perfectly good sedan won't do.

Operations view their underlying individual processes as structural components. Bringing together the aspects of availability, persistence and effectiveness, architecture's selection criteria define and drive utilization of components that are suitable in business terms as resources for operations.

Thanks to architecture, operations assume that the underlying processes can successfully co-operate under presure. This success fosters opportunity for the business. But the mandate for cooperative processes lies not in the opportunity but rather in the needs of the business.

In IT operations, management must coordinate the provision of IT resources against business need, through measurably meeting requirements for availability, persistence and effectiveness. The provision is structured with management processes, so it is logical that an architecture would organize the processes to be used.

II.

IT's management has an architectural reference for this.

ITIL (the IT Infrastructure Library) is generally describable as:
- a framework of
- processes that are
- combined to operate
- the management of IT
- as a business.

The framework directs the identification of types of processes appropriate to the business performance of IT management.

The concept of "business performance" revolves around the complex goal of:
- maximizing benefits and minimizing risks, from...
- an optimized balance of services and costs used to...
- efficiently respond to business requirements and business demand.

The output of that effort is a virtual "product" (provision).

When business needs are prioritized, decisions to act on the priorities creates demand. Response to the demand is allowed within certain tolerances which are identified as requirements. To ensure that provision is appropriate, operations must understand and work in terms of both the requirements and the demand. But what it produces from that must furthermore align with the needs of the business.

The complexity of that performance reflects a three-dimensional view of value that the business wants to receive from the IT management effort.
- benefit/risk ratios (quality) pertain to the choices that the business has for its supporting enablement
- service/cost ratios (economy) pertain to the effective supply-level of support
- response efficiency (availability) pertains to the reliability offered to the business.

The key corresponding challenges are:
- Change (versus quality)
- Expense (versus economy)
- Speed (versus availability)

The business looks for competitive advantage in those same three challenges. Its ability to exploit them repeatedly is what sustains the business in advantageous positions. But most businesses have to consciously make all three factors work together, as experience shows that they will otherwise mutually interfere.

III.

The proactive outlook on this need is most often now described as a business pursuit of agility, productivity and regulation based on operational support. These "business success factors" become objectives for operations.

Agility balances change and speed.
Productivity balances change and expense.
Regulation balances expense and speed.

On the flip side of the coin, the protective or pre-emptive outlook can be described as the following business pursuits: resilience, capacity, and continuity. Likewise, these become objectives for operations.

Resilience is a balance of change and speed.
Capacity is a balance of change and expense.
Continuity is a balance of expense and speed.

Using these as objectives, and keeping in mind that these are descriptions of the business itself, operations drive towards "performance" that creates those significant differences to the on-demand conditions experienced by business. Those differences are the "business value."

For operations, the question is, which processes should be used to support the effort to meet those objectives?

IV.

In ITIL, a set of key management processes for the business use of IT functionality (a.k.a. "services") are identified and labelled in a very consistent way, using a standardized vocabulary that is applied across all descriptions. The vocabulary is extremely important for distinguishing the processes relative to each other, showing clearly where the various processes share and don't share specific responsibilities.

But the vocabulary is not the framework. At a higher level of distinction, ITIL separates operational provision into categories such as "delivery" of product and "support" of product. Those general responsibilities are then articulated with up to five pertinent management processes, each -- according to objectives that represent the business demand and business requirements for delivery and support.

What we want to understand is how the ITIL-identified processes address the six objectives we have outlined above:
- agility, productivity and regulation; and...
- resilience, capacity, and continuity.

The reason for this mapping is to describe the generation of business value from the ITIL-designated processes.

Our value mapping requires that we take the background concepts given for the six objectives as our main perspective. Those concepts pertained to the business challenges that indicate "success factors" to be managed in the business. Value is perceived in terms of those success factors. Management processes support the performance of operations that generate the business value.

Among those factors, agility, productivity and regulation together tell a story of the business capability to exploit circumstances.
Meanwhile, resilience, capacity, and continuity together tell a story of the business capability to bring resources to the occasion.

Both stories are about business effectiveness in the path the business chooses to execute and meet the requirements of its mission. The success factors do not pick the path, but they provide terms by which to plan and assess it. Management processes should be contributing, accordingly, to the planning and assessment.

Giving a general assessment by "stories", we have the following setup of ITIL-named processes.

Now we can reiterate a related earlier observation in more detail. The business support-problem that this architecture addresses is a balancing act: there are constraints (or restrictions) on what processes are available, yet the blend of available processes must offer a way to provide persistent support of the expected requirements.

Blended support suggests process integration, but the more essential move is to orientate the processes to the same objective. Integration is one approach, but negotiation and collaboration are also useful and might initially be more practical.

On the left side of our grid we have processes that address the aspect of agreements and permissions that effectively predefine the usual responses to demand. This impact is what is in common across agility, productivity and regulation; it answers the question, "what are my optimal response options?"

On the right side we have processes that, largely through policies and risks, define the effective characteristics and sources of the resource supply. Running in common across resilience, capacity, and continuity (as we defined them in the discussion), the key question is "what can I count on using?"

Those questions make it even more evident that the management processes must "account to the business" -- by addressing the questions in both planning and assessment.

V.

Business needs come with constraints.

Everyone always wants to satisfy needs with something that has the legendary features of being fast, cheap and pretty -- but the solution most likely obtainable by the business may fall short, while its acceptability -- its value -- is no less described in terms of demand. Managing IT for business enablement can be a "high-performance" activity only when it addresses that demand.

Returning to the discussion's initial description of value, performance reflects a three-dimensional view of value that the business wants to experience from the IT management effort.
- benefit/risk ratios (quality) pertain to the choices that the business has for its supporting enablement
- service/cost ratios (economy) pertain to the effective supply-level of support
- response efficiency (availability) pertains to the reliability offered to the business.

Every business can relate to choice, supply-level, and reliability as the dimensions for evaluating anything from assets to resources, opportunities, and partners. The business always essentially tries to determine whether it has the preferred relationship with these things, and makes changes according to its findings. Detecting and metering the dynamics of value-delivery can be exhausting and esoteric at worst, but managing things towards business value begins with understanding groupings of efforts whose interactions logically produce impacts on desired conditions.

Within the ITIL framework, management processes improve important attributes of IT services themselves, such as service availability, service configuration, or service continuity. But it is the difference made through the service utilization by the business that then counts as improved business attributes -- including business availability, business continuity, etc.

VI.

Aside from details on the internal design of management processes, ITIL provides a perspective that identifies the IT organization as a managed producer/provider with a known customer. This responsibility sets up the compelling logic of the process groupings that ITIL presents. Yet most organizations still find it difficult to prioritize and maintain their ITIL adoption strategically. The substantial difficulties of developing the individual processes to an effective state are superceded by an even bigger challenge -- lack of a model of direct systemic impact on the character of the business, which is what drives the top line instead of the bottom line.

Top-line benefit is the strongest rationale for taking on the profound risks of organizational change associated with management process reorganizations, such as ITIL. Accordingly, the most important framework for the effort is a business value framework, which should then be the basis of managing the adoption initiative as well.

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

December 1, 2005

Governance: the Stakes

In an ongoing dialogue with colleague Dan Krimm, the future governance of the internet is the feature topic, and our cross chatter is working in two directions. One is to solidify the stance and urgency for protecting the breakthrough in information access that the internet provides our societies. The other is to give shape, and even a model, to the analysis of the stakeholder issues involved.

The latter is rife with complexity because it is currently more like sorting out a collision than it is like planning a development. Enough groups with enough special interests are already in the space with either enough momentum or enough determination to make it, amazingly, crowded -- not in terms of room to maneuver but instead in terms of how to maneuver. On second thought, to face up to this problem means getting ahead of the collisions, like air traffic control .

Recently Dan put a fine point on the general thrust of legal activity around internet governance. Said Dan, "As long as there is consumer demand for certain features, and someone willing to build the products with those features, and no law against building those features, there should be a market for them. In short, the hardware manufacturers are not the corps invested in content control, more the media and telecom corps. So consumer electronics corps tend to be open-design oriented, while RIAA/MPAA are trying to shut things down."

My riff on that, which I replied to Dan, went like this: " the hardware manufacturers are not the corps invested in content control, rather, the *content manufacturers* are the corp invested in hardware control."

Putting it that way, it's easy to start thinking that content manufacturers have two fish to fry: (1) distributing content specifically to increase its value, while having the means of distribution NOT decrease its value; and (2) creating content specifically to leverage the existing means of distribution.

Relative to each other, the first item leans towards regulation while the second leans towards innovation. But if we took that as an "axis" (regulation vs. innovation) then maybe another significant axis -- "liberties vs.security" -- would give us a social cross-reference to the operational issues...
Running with that, I get this:

We need say more than this, but this looks immediately useful as a way to organize the description of concerns that characterize any given stakeholder.

The thought now: use the tool to describe, in turn, the individual personal user, the business user, the content product manufacturer, the hardware product manufacturer, etc. -- and reveal the "interests" that need to be prioritized and/or reconciled.

Is a reconciliation necessary? For whom? As Dan puts it, there's an awful lot at stake -- too much to not pay attention. Just one of his examples: he notes that "the gist of it is that corporations are lobbying government for legislation that would increase their control over content transmission and CPU design... Some legislators are not averse to designing the technology with more control, because government could use that control as well. In other words, it's not just a free market here, but collusion of strategy between government and big business to build the Big Brother society..."

P.S.
How about the "space" within the more typical business enterprise? Governance has become a huge issue both in terms of the business functions and the enabling business infrastructure.

To the extent that a business has a strategy that drives its decisions and activity, the business's "special interest" now faces greater scrutiny by public and other authorities than ever before, who want to get a better grip on what the business does not just "in" the marketplace but to the marketplace.

And within the enterprise, the idea that multiple divisions, processes and managers -- all trying to hit performance targets -- will "share" the company's resource capacity is also under greater examination than ever. It would seem that these are situations which lend themselves just as well to decoding by the same framework as the one above.

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

November 30, 2005

Environment or Process: which helps Innovation more?

Looked at entirely dispassionately, environment is cultural, and process is political. Add to that the key thing that warrants being called "innovation" -- which is simply a quality of newness that is the difference that has significance.

In practical measure, an innovation is something that is unprecedented and has either compelled or attracted acceptance. But the "newness" is always entirely a matter of context. Organizations, therefore, should understand innovation in terms of whether their basic need is for a cultural change (which alters the way value is defined) or a political change (which alters the way value is pursued).

As for being helped more by environment (culture) or by process (politics), the issue is not so much about one versus the other, but instead about whether the alignment of the two -- a prerequisite for successful innovations -- is more likely to be accomplished by emphasizing one or the other.

Acknowledging that, the opportunity to foster innovation can readily differ from one area in an organization to another, and from one time to another in the organization's operations. That's why innovation opportunities must be managed.

Posted by Malcolm Ryder at 8:16 PM | Comments (0) | TrackBack

When Rules are required, Requirements rule

Business has a history of asking for IT to enable new capabilities, and IT has a history of giving the business those things while falling behind itself in the same progression of operational management improvements. So when the "non-expert" business users establish the norms that are acceptable for these capabilities, it is ironic that IT has to learn the capabilities from business.

For many years, consultants have had the capability of explaining the difference between business requirements, implementation requirements, and infrastructure requirements. This set the stage for also explaining the relationship of the three sets of requirements.

But the value of that capability would simply shift around according to who was the most influential sponsor (aka, the client) of the development project the consultant was working on. Meanwhile, the importance of aligning the different requirements was too difficult to prove except where enterprise architecture was taken seriously.

Now, as provided by today's IT, the visibility and control of operations is giving the business experiences and awarenesses that extend more "democratically", enterprise-wide.

As part of this awareness and experience, rules are much more in the foreground as stabilizers and optimizers for decision-making. Basically, rules describe the decisions that have been made and approved about how responsiveness to demand is to be implemented with risk and efficiency already factored in.

But because they are ultimately aimed at demand, rules derive their real significance from how they relate to requirements. So in fact it is requirements management that establishes the environment for effective rules management. Requirements will drive the need for aligning rules, but it will also drive the need to change them. Decisions about requirements themselves are always the most important issues to get right, while technology becomes a critical tactical factor in whether those decisions are actionable and thereby practically meaningful for business value.

Thus, because technology is "globally" increasing direct awareness and the ability to do something about it within the organization, it almost automatically becomes necessary, instead of optional, to manage rules strategically.

Michael Voelker, writing in the November 1, 2005 issue of Intelligent Enterprise, discusses Business-IT alignment in terms of how responsibility for managing business rules is balanced across the organization.

Such responsibility may be presumed even before the capabiity exists to live up to it. But with IT, the business can best help itself by ensuring proper support for IT production.

So, two key thoughts follow on that story. One is about management maturing from a special professional function into a general organizational competency, thanks to IT distributing the opportunity to decide effectively.

The other thought is about how increasing experience, enabled by IT, becomes expertise that loops back to the conception of what IT ought to be doing. When business uses IT to drive "better IT", both parties win.

In the case where IT allows the business to more freely allocate responsibility, the business gets something new, but the business viewpoint on what should be possible then feeds back to IT in ways that will change IT by making it more like a business. What we're seeing, in effect, is a practical iteration of enterprise architecture, with enterprise-wide adoption finally possible through more tangible terms.

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

October 19, 2005

The Art of Aligning Alignment

Business reaches necessary levels of performance by relying on processes. And meanwhile, most of the critical processes are now powered with IT. There is abundant evidence that from a planning perspective this is usually a good idea.

But ironically, this same chain of connections makes it persistently difficult to make and rely on strategic assumptions about performance. Why?
- Because of the complexity of existing operations, management often sets performance requirements without really knowing if it can rely on its processes to keep up with them. For this issue, management is looking for what it calls the alignment of strategy and execution.
- Meanwhile, another part of what underlies uncertainty is the quality of IT's enablement of the processes. For this issue, management is looking for what it calls the alignment of business and IT.

But business has now learned that the two types of alignment are interdependent; one rarely succeeds without the other. So the alignment of strategy and execution must constructively intersect with the alignment of business and IT, which at first adds more complexity while also being relatively new. So the necessary combination seriously challenges business management, particularly in terms of timing, funding and politics.

Without a clear view of the scope of the challenge, solutions are more likely than not to be under-developed versus the forces that can prevent them from ensuring sustained effective support. Additionally, it would be difficult to understand the sensitive trade-offs of starting out with one emphasis versus another.

Processes are at the intersection. Illustrating the scope of issues around the process shows that a small group of intensively defined management elements "parse" the complexities of aligment into different points of view. These elements are:
- objectives
- policies
- information, and
- resources.

When alignment stakeholders are surveyed for the visibility they have on these elements, it is not unusual that the elements are checkpoints which vary in completeness, in priority, in content, or in any mix of those three, amongst the stakeholders.

This means that the bases for alignment are likely missing supportive agreement. While authority can drive action forward anyway, consensus is much more important to sustained effectiveness.

Assuming a reasonable level of consensus recognition of the basic elements, the next thing to confidently establish is the way they combine to generate critical points of view on alignment. These points of view -- strategy, governance, planning and execution -- usually show up as functional issues that get measured and therefore make up the "performance" picture of management. In the picture below, the general separation of these viewpoints, resulting from the interplay of management elements, is mapped out for navigation.

As illustrated here:
- the policy element decisively intervenes in the presumed alignment of strategy and execution -- but the predisposition of strategy is critically influenced by objectives, while the predisposition of execution is critically influenced by information.
- The strategy point of view has a clear line of sight to objectives and policies, and tends to understand processes through that visibility.
- Because policies are dynamically involved with execution, and objectives are dynamically involved with governance, strategy likely influences the governance and execution points-of-view through its impact on policy and objectives -- impact that for better or worse is usually negotiated if it survives.

Each point of view, taken in turn, has the same kind of relationships with its contiguous elements.

Overall, the surprises are:
- that strategy and planning are so indirectly coupled, but this explains why comprehensive plans are so complex;
- that "Business-IT" alignment is not overtly signified at all, but this is because business is an "overlay" to the entire picture, while IT is an "underlay"; and,
- that process is so multidimensional, requiring coordination of as many as four elements before it should be considered stable and mature -- but this explains why despite automation and best practices, one size does not fit all.

A key aspect of the different points of view is that they typically have "owners". Because the points of view drive motivation, the issue of their cooperation is essentially a very high-level one. Cooperation stems from motivation, and the picture shows that motivation is affected by the management elements and also by the executive agenda. The four typical components of the executive agenda, which we consider to be executive "drivers", are Goals, Risks, Perspective and Competency. Taken all together, the four drivers from the executive agenda approach being a definition of the organizational culture, but in daily effect they are more or less political. In the way the drivers work together, they generate the points of view we discussed above, and thus they precondition the prospects for consensus.

For example, strategy represents an "alignment" of goals and competency (or it better!), while governance represents an alignment of goals and risks. If the understanding of competencies is too divergent from (and unrelated to) the understanding of risks, it becomes significantly more difficult to successfully configure goal-pursuit as strategy and governance, making defense of objectives hard to implement.

The surprise at the driver level is the role of perspective. Perspective should be looked at as the location of beliefs, expectations, and knowledge -- all of which are generally "organized", in ways that aggressively affect the interpretation of data as well as both planning and execution. It's not surprising that perspective is a driver, but instead that it is more critical to the alignment of planning and execution than are the other drivers.

In the big picture, it is tempting, but incorrect, to see "Business" on the left side and "IT" on the right side -- and then look for "alignment" across the middle. Instead, the problem of Business-IT alignment begins with defining what the phrase means, and the most reliable working definitions bring the picture into use as intended, to study the intersection of the two major kinds of alignment.

The typical problem that Business has with IT is that the impact of the use of IT disagrees with the requirements of supporting the objectives that represent business progress. But as big a problem as that is, it still understates the real need that the business has of IT.

Instead, for alignment with the business, the management of IT needs to focus on how IT's impacts strategically support the coordination of the drivers, points-of-view, and management elements shown in the integrated alignment picture.

Because there are at least those three concentric areas to affect, and four points within each area, there are a very large number of influences and cross-influences to establish and coordinate -- all in the face of potential change at any point, at any time. Clearly this will be anything but simple; but as a starting point for recognizing the challenge we at least can say that IT's management is likely wasted effort if it is not dedicated to the coordination represented in the picture of alignment.

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

September 26, 2005

Competency, Competing, and Strategic Behaviors

When we try to discuss organizational performance, it is often through the question of whether the organization's competencies prove to make its competitiveness effective. And these days, the problem of "competition" versus "competency" merits being called interesting especially because we've found out so much more about how being competent doesn't add up to being competitive despite the costs and lost sleep involved.

Sadly for the management teams of most large organizations, there seems to be no way to avoid spending a huge amount of money on the organization's becoming "more competent" -- because not spending the money almost guarantees that it won't happen. Meanwhile, becoming competent takes time and there's a risk of the competency being irrelevant by the time it matures.

What really helps, then, is to understand how investing in competency does begin adding up to being more successfully competitive.

I.

Ideally, it's possible to clearly state what makes up "competency", so that the necessary investments are well-exposed. Without being overly technical right away, most people would agree that in any given circumstance, competency generally means "effective behavior."

One especially intriguing look into the effective behavior issue is the Booz Allen & Hamilton model of organizational DNA, featured regularly in their publication strategy+business... Organizational DNA dwells on how organizational behavior springs from the internal "programming" of the organization, and suggests that reprogramming will invoke different behavior.

Back in the fourth quarter of 2000, Booz Allen stated, "What sets the top performers apart is the 'how' -- the way they organize and operate to realize their aspirations... The solution lies in changing the organizational environment to encourage decision-making that is aligned with the overall objectives of the company."

The Booz Allen model is aimed at producing solutions that improve organizational alignment with strategy. In this general vein, a typical presumption is that management decisions explicitly pursue an "optimal" prescribed behavior only approximated by real behavior awaiting improvement. Everyone is looking for the secret to improvement.

By 2005, extensive field testing of the DNA model allowed Booz Allen to confidently state:

"To change an organization effectively, concentrate on the deliberate design of four key organizational building blocks:

Decision Rights: the rules and mechanics that govern who makes which decisions -- and how.
Information: the metrics that measure performance, and the practices that transfer knowledge.
Motivators: the incentives, objectives, career alternatives, and other elements that drive people's behavior.
Structure: the overall organizational model, including the 'lines and boxes' of reporting relationships and job descriptions."

Naturally, there are many costs associated with the "before-and-after" reprogramming of each of those conditions... However, the focal point of the Booz Allen "DNA model" is more about the flow of what we often call "political capital". This initially appears in the emphasis on decision rights. But in fact, all of the DNA model's four building blocks have been included because they are (arguably) the factors most affecting decisions.

The DNA model points at the way that decisions (not just the rights) are distributed and made by everyone in the organization, with decisions being the driver of how the organization looks and behaves. While the changes the model supports are to affect the environment for decision-making, the point of the Booz Allen approach is to position and exploit decisions themselves as the generator of performance-critical behavior.

The big issue lurking under that idea is about the difference between how suggested corrective (.e., managed) changes to the environment affects performance and how "natural" changes do. Every day, a huge number of intentional but independently made decisions collectively and "naturally" alter the environment. In detailing that organizational environment, the Archestra view finds and describes a set of basic influences "accounting for" the organizational behavior as encountered by strategy. Since we describe that environment differently from the DNA model, the course of managing it could significantly differ as well.

II.

As does the Booz Allen DNA model, the Archestra account emphasizes that several essential functions underlie (i.e., both constrain and support) the organization's potential behavior at any point. And, when that potential behavior is realized, the behavior is the environment for what comes next. But our functions are different.

DNA says that this environment affects decision-making for better or worse. But the Archestra emphasis is that key performance decisions do not just wait for a friendly environment. Instead, strategic alignment means some decision-making -- not all -- has to work on how that behavior is realized from the underlying functions in the first place; while other decision-making is then critically responsible for whether the behavior executes strategy successfully.

To illustrate these two different layers of effects, first we directly call out the basic "modes" of organizational alignment that provide the environment in which strategy must survive.

Within these modes of alignment, there is a hierarchy of influence, with the most dominant at the top and the least at the bottom. In the interplay of these influences, "competency" leverages taxonomy and standards but is largely constrained by culture. Given that, one thing we can point out is that culture largely determines the competitiveness of a competency.

The alignment hierarchy also exposes an additional crucial dynamic. Namely, within the organization's overall functionality, external or exotic influences such as taxonomy or standards are more readily swapped in and out of the organization from one time to another than are more internal or intrinsic influences such as competency or culture. However, once in, external influences are significantly constrained by intrinsic ones.

In the picture, we see specifically what items the influences work on, noting that those items independently change all the time. Overall, the decisions that bring in and/or shape the four "alignment" influences produce the predisposition aspect of the behavioral environment.

III.

Meanwhile: another essential aspect of the organization's behavioral make-up consists of the way the organization responds to the circumstances that it believes it inhabits -- in short (and coining a term), its responsivity. Typically, this responsivity is what the alignment modes must work on, but when they arrive they find natural forces already at work.

The three key natural influencers of "responsivity" are:
- motivators which encourage certain action)
- generators (which enable and manage action)
- indicators (which suggest action)

More specifically, the interplay of those three influencers "maps" the intuitive dimension of responsivity as in the following picture:

Day to day the organization sees itself in a mirror, noticing key elements (of needs, options and requirements), and directly reacting to what it sees.

But the deeper issue is the way that those key elements are linked by the natural influencers, generating the overall intuitive responsivity -- so what are the origins of those influencers?

In the picture, those origins are awareness, execution, and assessment. The next step in discussing "effective behavior" examines those issues.

IV.

Our first illustration above details the underlying four parts of "predisposition". Likewise, the three underlying parts of "responsivity" shown in our second picture can be described more specifically. For that, one approach is to see the parts -- awareness, execution and assessment -- as tendencies or "characteristics" developed from particular organizational activities and observations.

Awareness is developed from the following factors:
- Decisioning
- Modeling
- Measuring
- Communication
The net effect of awareness is to create the "working image" that the enterprise will have of the circumstances within which it believes it operates. The working image presents options of varying attractiveness to the enterprise. The options are thus motivational. This four-tier hierarchy of "awareness factors" also features, from bottom to top, increasing complexity in the development of the working image.

Execution is developed from the following factors:
- innovation
- collaboration
- optimization
- change
The net effect of execution is to proceduralize activity in the cause of "recognized progress." Understandably, these tend to be the major issues on everyone's operational management agenda. The four factors are stacked relative to each other with the most reactive activity (towards progress) at the bottom and the most proactive at the top. All of the factors are about exploiting requirements, and all of them are at risk without "alignment". Arranged hierarchically, each of these four factors is critically dependent on the factor below it in order to be successful at generating maximum impact.

Assessment is developed from the following:
- Value
- Performance
- Quality
- Risk
The net effect of assessment is to establish the meaning of the "current state" and thus validate or challenge the existing perception of needs. In the context of progress (from execution), assessment tries to understand whether the difference achieved is important enough (or not) to defend the means by which it was gained or to change them. While each of the four factors is a kind of importance per se, they are hierarchically ordered with the issue on top being the most indicative of (i.e., directly relevant to) a specific strategy and the one at the bottom being least so (although perhaps more relevant in general to all strategies).

Summarized from the viewpoint of strategy, awareness must offer encouragement; execution must offer enablement; and assessment must offer clear ideas.

V.

The combination of a working image of circumstances, recognized progress, and an accepted meaning of the current state characterizes the intuitive dimension of responsivity. Again, day to day, the organization sees itself in a mirror made up of those aspects and reacts to what it sees.

But for a full appreciation of how that version of awareness, execution and assessment might really play out as behaviors, the following view gives another perspective crucially important to performance management:

As featured above, behavior is coordinated by approvals, assignments and accounting. Together, they make up the political dimension of responsivity, mediating the otherwise "intuitive" responsivity of the organization and intervening between predisposition and actual results.

The most prevalent characteristic of this coordination is that it is negotiated -- not once-and-for-all, but repeatedly and without guarantee of consistency, due to the continual and irregular influence of internal and external change on the organization. Yet the political formatting of responsivity is what most organizations believe will spawn "effectiveness"...

Since this means that the underpinning assumptions and conditions of the strategy might vary beyond expectations, the organization must grapple with how strongly a policy of adherence to strategy will be enforced. Successful enforcement means resolving the tension between the organization's predisposition and its politics. Even more importantly, since intuitive responsivity is continuously forceful at setting things in motion, the balance of predisposition and politics must "train" the intuition towards the strategy instead of away from it.

VI.

Given the above pictures of predisposition and responsivity, our full account of organizational behavior is based on how the two things affect each other.

From a management standpoint, effective Predisposition presents its influences with dependencies summarized as follows:
- Culture's function of granting permissions involves the relative strength of permission granted
- Competency's orchestration of abilities involves the maturity of the resulting combination
- Standards' presentation of rules involves the degree of adoption generated for those rules
- Taxonomy's offer of definitions involves the stability of those definitions across time and place.

Management can deliberately attend to those dependencies. The current predisposition constrains the likely effectiveness of the functions that make up intuitive responsivity -- by the way that strength, maturity, adoption and stablity are established for each function.

On the other hand, political responsivity will counter-offer different criteria of acceptability and importance to shape behavior, whic can pose a significant problem. If positions, assets or stakes are challenged in any combination, their owners may push for settlements, using approvals, assignments or accounting that either ignore effective predisposition or must attempt to change its underlying terms.

Consequently, if politics compromise the optimal predisposition, then the predisposition will compromise the intuitive responsivity that is the real environment for strategy.

As outlined by these worksheets for detailing intuitive responsivity, very many variables can be changed. Management's challenge is to know where, when and why changes occur -- and to control them by type and degree for benefit to supporting the strategy:
- Awareness details, which combine to envision current states
- Execution details, which combine to create future states
- Assessment details, which combine to determine overall status

VII.

In the intuitive responsivity arena, the awareness aspect's hierarchy of factors bears a superficial resemblance to the Booz Allen DNA model, especially in its inclusion of decisioning. But... the set of awareness factors does not Instead, it presupposes that most decisions have both traction and persistence only when the other three "awareness" factors support them, so if you want a new decision to succeed then you have to "tune" the other factors to support it.

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

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 21, 2005

The Objective of Setting Objectives

Working through an approvals process?

"The gap between your personal culture and your corporate culture is what will keep you sane -- or drive you crazy." That's the caution that Steve Andriole from Villanova gives in a great January 24, 2005 article titled Politics, Culture & You.

By pointing out that approvals take place on terms that can as easily be philosophically-based as research-based, Andriole highlights the difference between appearance and reality when it comes to "objectivity". Objectives may make up the known framework for decision-making, but where did the objectives come from?

This is an important issue because an "objective" is, in the practical sense, a purposeful intent -- and the reasons behind that purpose may or may not agree with the motivation behind a new proposal. What's the difference here? Intent simply announces a type and direction of change; but real purpose is about "why" and may even be unannounced.

Now add to this that assessment and evaluation are also different. Evaluation will look for a rational decision based on fixed criteria; but assessment will weigh that decision in a context larger than the scope of the proposal. Approvals lean heavily on assessment.

That said, a proposal will be assessed not just by terms that measure alignment with intent, but also that measure compatibility with the purpose(s) of management objectives. This puts the sponsor of the proposal on the spot -- to understand whether the likely impact of the proposed change really aligns with the value system of the ultimate decision makers.

One way of pointing at this issue is through testing for "favorable demand" -- an approach used by experts such as Charles Chandler of the firm Assumption Analysis. Chandler outlines this amongst three keys to creating objectives that turn out to be reliable and actionable for both sponsors and approvers. He emphasizes that much of what is critical to an approval is "imbedded" in an organization and needs to be carefully exposed as part of shepherding new initiatives and proposals.

Along those same lines, Andriole shows that the implicit and explicit influences are at the personal level as well as the corporate level. By bringing this awareness to the foreground, Andriole and Chandler show why a change that would enable a strategy so often really needs a separate strategy for getting itself approved.

[Click here for a more extensive look into the culture around strategy...]

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

September 20, 2005

Maturing Performance Improvement

Organizations exist in order to enable value to be created from investments.

In this sense, the most general acknowledgement of their improvement sees an increase in the organization's ability to enable value-creation, and/or an increase in the benefits actually obtained through the organization.

Naturally, an executive of the organization has the responsibility to see that the purpose is actually fulfilled by using the organization. But the management of the organization must be primarily about ensuring that the organization is fit for the task of pursuing the purpose -- so this is the focus of management's idea of improvement.

I.

Although "fit-to-purpose" seems like a straightforward, uncomplicated idea, the practical lexicon of "enterprise improvement" consists of many overlapping concepts, and managing improvement likewise consists of many overlapping perspectives such as value, performance and risk. Applying and blending these effectively, without having complexity become counter-productive, is the big challenge to making their influence into improvement as opposed to just change.

In sorting out the overlaps, the conceptual or semantic distinctions allow different roles in the organization to identify the particular issues to adopt as their respective responsibilities -- thereby generating a basis for designing both the infrastructure and processes to actually improve.

Commonly, however, responsibilities for an issue will still overlap after the sorting out has been done. Where more than one role is actively responsible for something, the need is for clarity on how the collaboration is effective for the responsibility.

Similar to the executive and managerial bents, these responsibilities can be readily seen from two points of view: one on requirements, and one on dependencies.

Improvement Requirements:
- Goal (motive) for improvement: such as growth, security, recovery
- Quality (degree) of improvement: maturity, scope, effectiveness

Improvement Dependencies:
- Models (means) for improvement: strategy, governance, architecture
- Deliverables (features) of improvement: agility, competency, continuity, efficiency

II.

In that setup, goals assume that deliverables will enable them, and models prescribe how quality of enablement will be achieved.

However, the listing leaves us with explaining how the two hottest terms in management today fit in -- alignment and performance.

What's universally agreed on is that both things must be managed and both things must be improved. If alignment leads to better performance, and better performance delivers better value, then the emphasis is a no-brainer. But...it's just that the implementation drives everyone nuts.

Relief begins when the situation is thought of slightly differently: better coordination leads to better execution, and better execution delivers intended impact more reliably. In this description, it is more readily apparent at each step that accountability works with planning to influence improvement.

But meanwhile, there are decisions to be made such as whether alignment is to be chased through strategy or through governance or architecture. The different modes affect the organization's potential fit-to-purpose in different ways -- or they should.

For example, coordination (the structural fit) should benefit in different ways.
- Strategy should identify and communicate the target values and why they are targets, thus defining objectives.
- Governance should define policies and programs for linking actions to opportunities as risk-managed capabilities.
- Architecture should methodically specify the integrating and configuring of resources into infrastructure.

Likewise, execution (the practical fit) should benefit in different ways:
- Strategized objectives should influence workload optimization
- Governed capability should influence availability and approval of response
- Architected infrastructure should influence economy versus scope and consistency versus flexibility

Finally, intended impact (the logical fit) should benefit in different ways:
- Strategy should maximize operational focus
- Governance should maximize manageability of compliance to requirements
- Architecture should maximize capacity for repeatability and effectiveness.

When a plan articulates the intended impact and can prescribe (or predict) underlying support (or success) factors at the execution and coordination stages, alignment is being drawn up. But once the alignment drawing is done and everyone sees "what" alignment is, actually making it happen is the daily problem of "how".

III.

This is where "performance" wades into the picture, because the success of making alignment happen is seen as a harbinger of greater things to come. The alignment effort -- especially if conducted as a program -- is executed against certain desirable outcomes, and the degree to which it reaches those outcomes will be looked at as "performance" to be managed. But in the bigger scheme of things, final business outcomes (such as transactions, product launches or contract signings) are being rated against targets and this is "performance" too. The question for both executives and managers is how the performance of the alignment effort is affecting the performance of the business in terms of final outcomes...
Is more alignment closely preceding stronger outcomes?

IV.

The strongest history of argument in favor of alignment driving increased final benefits is usually found in two locations: the Continuous Improvement literature, and the Maturity Model literature. In both instances, the thesis is not just that alignment is a performance "good-to-have", but instead a performance "must-have".

Competition and economics drive the argument in the continuous improvement (CI) camps; the expense of providing a competitively advantageous product is mitigated through proactive quality measures. Meanwhile, complexity and competency stoke the maturity modelers (MM); meeting the multiple obligations of a contracted role is tackled through systematically calibrating defined levels of expectation versus defined levels of effectiveness. Both CI and MM have the perspective of "engineering" improved business outcomes.

With maturity models, however, the problem has developed that there are so many different ones which are seemingly interlinked that it is difficult to understand which ones to use or where to start amongst them.

For example: using a web search engine, one can easily trace consultative literature in IT performance from analysts, researchers, service providers and vendors, to organize a collection such as this:

- Howe School of Technology Management: Luftman and Dell, the Strategic Alignment Maturity Model
- Pink Elephant: J. Duffy, the Strategic Alignment Maturity Model
- Forrester Research: the Strategy Alignment Maturity Model (April 2005)
- InfoTech Research Group (IT BusinessEdge): the IT Governance Maturity Model
- Gartner Group RAS Services: the IT Management (ITSM) Process Maturity Model

With this collection, one finds that:
- the top maturity level of IT service management calls for business alignment
- the top maturity level of business alignment calls for governance
- the top maturity level of governance calls for strategy alignment
- the top maturity level for strategy alignment calls for ...

These interdependencies pose a difficult question. Does maturity in one area depend on maturity in another area (and if so, how much is enough?) -- or does "maturity" in one area simply require a program in another area to be implemented?

Practical experience says that different roles take on different areas of maturation, and the ad-hoc recipe of the interdependencies calls for them to leverage each other's progress. Ideally, synergy develops amongst the different roles, and if so then the most interesting observation will be that the "culture" of the working environment will be intentionally evolving -- whereas the typical approach to this interconnection has usually been to develop a "process".

What management likely needs, to fully exploit the kind of clarity that maturity models can offer, is a communications mechanism that is able to express and correlate the cultural issues and events of the role-collaborations. These cultural phenomena may be the most truthful "performance indicators" -- ones that can be used as inputs into the efforts to optimize the organizational design for its purpose.

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

September 18, 2005

Aligning Execution and Performance, with Process

Recently the difference between "outputs" and "outcomes" has been a major topic in maturing the management of performance. It is becoming clearer that performance pertains to outcomes while execution pertains to outputs. But if performance depends on execution, then the key question is, how do outputs drive outcomes?

When we say "performance", what differs it from our idea of execution is our intent to talk about how close the impact of execution came to what we wanted and/or expected.

When we say "execution", we're trying to point at the way that things got done on the way to that impact.

But noting the difference, we should also add that explaining the output doesn't explain why it has the impact that it does. We should also ask what makes the impact a probable companion of the output. What we'll find is that the role of a process is to make that probability as high as necessary.

I.

Our most typical perspective on performance assumes that outcomes have prerequisite underlying outputs -- and thus that missing, defective, or incorrect outputs "account for" poor performance.

Solving those problems of omissions, defects and errors takes us to investigating whether the means of execution are properly coordinated. But beyond that, we also need to know whether the conducted execution was aimed in the right direction.

Consequently, solving performance problems, there are two major areas of solution investigation -- both falling under the heading of alignment:

1. Quality: of actual procedural integrations
2. Effectiveness: of actual influence on conditions

II.

Take the "quality" area first. Following the typical advice, procedure investigations would look into the connections between people, processes and technology. In one way, this is intuitively correct thinking; an organization can almost always be described in terms of the way it designs, selects and deploys those three fundamental "resources" for execution. But in more than one way this is a fairly awkward approach unlikely to lead to proper solutions.

One problem is that the three items -- people, process and technology -- are not defined on the same logical "plane". If we were instead to normalize the way they are managed, we would have at least a two-tier set of items with the lower tier being people-events-tools and the upper tier being workgroup-process-system.

The second problem is that execution requires not only "resources" in the sense of items that can be cataloged as assets and "qualified" for duty; rather, execution requires a configuration of resources, which creates the functional environment for execution called infrastructure.

Simply described, infrastructure includes facilities and services for operations. What we've been learning more and more is that infrastructure is an idea that must both shape and accomodate the dynamics of the operating environment, and thus become less exclusively a set of fixed objects and more inclusively a set of controls that direct access and navigation to and amongst facilities and services.

The overview of necessary connections within the infrastructure means that we look at the following configuration and control-related issues:
- people-to-people connections: including workflow and communications
- people-to-systems connections: including applications
- system-to-system connections: including platforms

What this does is to indicate how procedural alignment (and its quality) must be composed for execution, meanwhile making it much more explicitly clear that two organizations with the same "resources" can get drastically different "results" (outputs) from their interconnection and utilization.

III.

Next take the "effectiveness" area. The influence of outputs on prevailing conditions largely depends on how the outputs are actually used. What this means is that it is most logical to understand execution as "production" and then understand the value of that production in terms of how management "markets and manages" the products. Since the value of the products comes mainly from their ability to satisfy important demands, the main perspective of practical use for solving the influence-oriented alignment problem is one of demand management.

What we've been learning about demand is that it must be seen in two ways -- as defined need, and also as defined requirements -- thus the fulfillment of demand is always subject to revision in two directions. The usual situation, though, is that a given party with one need might send that same need to two different parties, and find that each party will differently interpret the need into requirements.

Simply described, demand management by the receiving party defines or discovers demand, assesses it, prioritizes it, fulfills it, and tracks it. In support of that, it includes all the following mechanisms, each of which has an output:
- requests
- analysis
- policies
- routing
- assigning
- monitoring

With the key issue being how those mechanisms are all required to address the particular need, what this does is to indicate how directional alignment (and its effectiveness) must be composed for execution. Meanwhile, those mechanisms all rely on the infrastructure.

As a way of defining the mode of influence that outputs have on outcomes, a process states that "if the need is... then our response will be..." and it organizes the response according to requirements. Meanwhile, by putting that stake in the ground, the process challenges circumstances to prove that other requirements might be necessary or better than these in meeting the need.

IV.

By finding that resources and outputs per se do not determine outcomes, we find that "production" procedures and "product" direction must be managed both separately and together, because they can change independently but must be related for meeting demand. In focusing on their underlying dependencies for the sake of making improvements, we recognize "infrastructure" and "process" as areas in which management creates alignment between execution and performance.

Posted by Malcolm Ryder at 8:00 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 4, 2005

Culture as Infrastructure for Strategy

Companies often refer to having and using a value system as the regular guiding influence of their culture on their operations.

We know that value systems are backgrounds for approvals, and it's easy to imagine a collection of associated approval processes representing the "system" of the values. In that case, regardless of the particular values targeted, the first purpose of the processes must be to manage the dynamics of approvals, dynamics that exist whether processes do or not. But how do processes get to know about those dynamics and thus recognize the inputs to use?

To identify and communicate about the dynamics, thus initially making them manageable, a value framework should already be in hand. But what does this framework look like?

I.

Creating the framework means taking a broad view of "approvals" -- we need to think in terms of what is accepted regarding the organization's actions and conditions. Naturally, this might involve a range of things like targets, standards and other definitions of desired states. In fact, determining those definitions is more important than the aspect of processes, because definitions must precede processes.

Nonetheless, the current surge of interest in performance management scorecards has everyone looking at a type of operational framework.

The good news is that performance is being talked about in terms of strategy being the value-definer for actions (operations). Seen by organizations as a driver of performance, strategy is wanted for its ability to define the difference that creates advantage -- the most high-level desired state.

But the bad news is that the actual results of actions -- which trigger followup decisions -- are often still not taken in a primarily strategic context but instead in a different (and strategically indifferent) way of defining value, such as cost control, timing, or compliance. The followup decisions -- especially about optimizing processes -- thus may not be aligned with the strategy although they are still reinforcing accepted notions of value.

Typically it's said that when strategy fails it is because of its execution, not because of its design. Organizations have plenty of hustle and flow, but evidently it's not enough. This makes us more deeply consider how it is that the execution would "make the difference" that strategy prescribes. What is it about the strategy and about the execution that makes their connection successful?

II.

This thought inspires us to consider the "quality" of the strategy in a certain way -- in terms of its effectiveness, its fit to its purpose, or in other words, its usability.

Since strategies don't just execute themselves, we have to examine the capabilities of the organization that is responsible for the execution -- both when we're planning before-the-fact and evaluating after-the-fact.

We can't take this notion of "capabilities" for granted: the most distinctive aspect of the word's meaning is "potential". What if the organization is not yet ready, or willing, or able?

Capability - A talent or ability that has potential for development or use... The capacity to be used, treated, or developed for a specific purpose. -- American Heritage Dictionary

Embracing this definition highlights an issue of compatibility between:
- the mechanism used to develop the ability -- namely, management;
and,
- the "raw material" to be shaped -- namely, the organization.

As a matter of strategy, managers direct the decisions and activity of their organizations according to objectives and policies. But even without a strategy, they manage that way as a matter of "best practices" in accountability. As a result, they not only exert a style but also formalize the operating environment in a way that we usually refer to as its "culture". The question is whether this culture results in appropriate organizational capability.

III.

Actual practice can easily fall short. Management style is usually expected to bringing energy, integrity and focus to execution. The natural focus is on maintaining a real-time match of requirements and abilities. And accountability for "performance" keeps the heat on management constantly. Unfortunately, accountability's concerns with "management style" can be counter-productive. Consider virtually any "Top Ten Management Issues" list from the last few years: too often it places heavy emphasis on the individual manager's activity inputs (awareness, decisions and intents) and hammers away on improvement there -- while comparatively neglecting the overall environmental outcomes also created (such as degrees of coordination, capacity, and complexity).

The complicated outcomes collectively called culture are so hard to grasp as a "whole" that we usually have to think of them the way we do a "climate". Climates require adaptation efforts, not control efforts. Through adaptation, some things are more likely to succeed in certain climates (or cultures) than in others. Here, the issue is the great extent to which management style (not the strategy) creates the climate -- through the way it handles objectives and policies.

IV.

Management intends to construct "effective" organizations. To count as a success, management style needs to make an organization that is compatible with the strategy but is also compatible with the climate that the management style itself creates.

We need to be able to discuss management's responsibility for adaptations -- for alignment -- as a counterpart to accountability for performance. Strategic compatibility -- a.k.a., alignment -- means that the culture must not inhibit the organization's approach to meeting objectives.

Pragmatically speaking, the "culture" is a description of how the management style has typically reconciled the opportunities to act and the approval of the actions.

Describing this reconciliation makes us consider both the nature of the organization's opportunities (in particular their sponsors, types, and locations) and the reasons for approving them (impact, importance, urgency). Here, the problem we encounter is that organizations have predispositions that are institutionalized largely through their managers, -- which creates potentialy high resistance to change. To illustrate that, the table below is a device for "mapping" the incumbent pragmatic culture, as typically under the control of managers.

Three aspects of approval make up the formula for describing, respectively, the sponsor, type and location of an opportunity. Each aspect represents a point of consideration and measurement, which may involve a precedent, a rule, a belief, a status, or some other quality that might function as a decisive criterion. Against the items in this mapping, both objectives and policies consider any potential change by asking the question "Why?" The terms shown within the table make it easy to see the many points at which existing objectives and policy could either frustrate or compete with new, different ones being introduced. Getting and sustaining "consensus" support across enough (much less all) of these points of precedent is never guaranteed. Where differences remain unresolved between the current and proposed circumstances, going ahead with the proposition carries risk. Therefore, to begin realizing the opportunity, someone must authorize and support the risk.

But this still leaves a gap to execution unless the organization is effectively mobilized.

V.

And to mobilize further across the gap to organizational effectiveness, management wants to deliberately rely on the culture as an "infrastructure".

Again, strategic compatibility -- a.k.a., alignment -- means that the culture must not inhibit the organization's approach to meeting objectives. That is, alignment needs management's combination of (reconciled) objectives and policies to provide a stable interface that the organization's members can use to consistently identify, anticipate and leverage opportunities and approvals for strategic action.

Strategy management -- through which execution is directed and linked to the difference that creates advantage -- faces the big question: Where does the consistency and stability come from?

"Architecture" is where we normally look to find a disciplined approach to building that compatibility. An architecture provides an integrated set of design and construction principles for developing a structure. Its principles guide the discovery and qualification of components needed to build a structure, and furthermore they guide support for the actual building effort. Those activities are commonly formulated into a production method.

When applied to making an environment conducive for (strategic) performance, the architecture's goal is to "produce" an infrastructure from that environment, which the organization will use as its interface for execution.

That's the hypothesis. Can the culture really be leveraged as a practical infrastructure, describing and guiding processes and agreements needed for desirable performance outcomes from the organization? If this is to happen, first the development of the interface must be managed.

VI.

An architecture in practical use is very often noted for, or even characterized by, both a style and method of construction that it generates. A challenge for managers is to use the architecture to find effective construction styles and methods, instead of imposing styles and methods exotically or incongruously on the organization.

One of the simplest forms of architecture is a framework, something that provides a neutral reference and gets its value from being that way. Arguably, a framework is most often used to guide a construction methodology, by providing all production participants with a common way to coordinate their different perspectives.

To provide guidance, a framework offers dimensions. A dimension is a perspective on the various different properties of something -- in this case on the various properties of that environment envisioned for executing the strategy. The purpose of the framework is to describe key dimensions in relation to each other -- which effectively evokes, classifies and arranges success factors for the properties, giving them higher recognition and attention.

That said, a dimension might be hypothetical (a "what-if"), or it might be discovered by trial and error. Accordingly, some of the framework might consist of theoretical factors; and some of it might feature empirically validated ones.

In the case of an organization's strategic alignment, the framework's job is to bring explicit consistency first to reconciling objectives withpolicies, and thereafter the various reconciliations with each other. In practice, a methodology exercizes this consistency, producing regularity (dynamic structure) in operations.

Managers work from that situation to develop the execution potential of the organization in that environment. Successful outcomes encourage repetition and reinforcement of their related management events; and the overall "learning" informs further progressive development.

VII.

The interpretation of the culture into an infrastructure provides the logical foundation needed for building execution that can focus on the differences that create advantage. Focused on making the difference, opportunities must be important, and approvals must be rational -- but they both must leverage the culture for sustained support.

That scenario depends on management's ability to associate opportunities and approvals with perspectives that coordinate the organization with the operational environment.

Guiding the construction of those associations, a framework offers dimensions for describing the terms of reconciliation that combine objectives and policies with each other. But the framework dimensions must account for the dynamics of the construction.

The diagram above highights the basic problem that management encounters in moving from opportunity to approval to action: - goals are the desired future conditions. They can represent the "why" of an idea, but they are constrained by the mandated support of the current state. - opportunities are the proposed "realization" of goals. They can represent the "how" of an idea, but the reality of opportunities is constrained by how the organization is allowed to function.

These realities of mandates and tolerances -- which come from various pressures including financial, political and intellectual ones -- complicate the (procedural) determination of just how "important" or "rational" things are.

The diagram above illustrates reconciliation -- showing the true direction of influences when the incumbent organization will be the resource for the execution of a strategy.

For strategic alignment, the picture raises the question of whether the objectives and policies initially in hand must be compromised or not on the way to execution. Although we intend to derive requirements from objectives and then execute on requirements, we can't get that done until incumbent policies and abilities have had their say.

VIII.

This multi-variable equation may go through many iterations of "if...then" before being resolved -- whereupon finally the resolution can be executed; but the question is whether the resolution is adequate to the task of realizing the strategy. Is the execution, as based on the resolution, capable of solving the right problem?

In that light, it's clear that the organizational ability finally offered to the strategy must be developed for the strategy in the intermediary stage.

In handling risks and priorities, a progressive development effort in "strategic capability" should incorporate four coordination practices:
- business analysis,
- change management,
- resource optimization, and
- assessment.

These each provide a perspective that is part of "framing the culture". Each of these steps brings the incumbent organization closer to alignment with the needs of the strategy, but all four of them must be directed at the particular strategy instead of merely at the desire to come up with something approved to do.

Meanwhile, each step also tries to coordinate the organization with the operational properties of the environment:
- rules,
- knowledge,
- events, and
- communication.

As part of the framework, the properties will complete the stable reference picture of the "cultural" dynamics.

Management can use the framework to research and specify expectations, preferences, responsibilities and roles that directly address the elements of the strategy. This provides an opportunity to formally communicate the value system that the strategy needs for getting organizational alignment.

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

September 1, 2005

IT Operations Intelligence - The Business Logic of the CMDB

Without question, business is overwhelmingly predicated on the ability to service needs through leveraging IT resources.

The ever increasing frequency in the variation of business needs means that there must be an increasingly intelligent mechanism for determining the current appropriateness of the available resource for the need, on demand.

I.

Technical advances have made it economical to store and communicate increasingly vast amounts of descriptive data about resources. It is now feasible to at least federate myriad descriptions into a single logical reference database.

But a key issue is how to actually increase the effective intelligence of the usage mechanism, which means increasing its ability to determine the relevance of the data in qualifying the resource for active assignment. Meanwhile, an accompanying problem is of course to ensure and confirm the availability of appropriate resources.

The sensible thing to do about those issues is to use the information to develop profiles of resources that allow quick identification and anticipation of productive associations with existing and predicted business needs.

But with the pace of change and the proliferation of business process variations, that would be a logically improbable achievement unless there was some framework of business demand that could help to define and anticipate the most likely requirements that resources need to meet -- thereby bringing order to the task of vetting the ocean of descriptive data by relevancy.

II.

For example, a business process makes functional requests that require the support of appropriate resources; this offers a step towards making a framework (or frame of reference). The functional requests establish what is appropriate by specifying resource characteristics that are known or predicted success factors. In reality, that specification may just as likely be discovered through trial and error (i.e., testing) as it is proactively designed. Still, in either case, any given resource can (at least hypothetically) be certified for its compatibility to the functions of a business process.

Then, by cross referencing multiple business processes, it will eventually become evident that a given type of resource applies to the range of constructive assignments. Patterns of both common and exceptional functional dependencies on the given resource-type emerge in more or less architectural perspective. Particular instances of a type of resource can then be audited and rated within their type or class.

Conversely, preventing and remedying destructive (or counterproductive) resource assignments means determining in timely fashion that an existing or probable mismatch of resource characteristics is imminent versus the expected demand.

Related to that, another challenge is that a resource, as a discrete unit, may not have all of the characteristics necessary to meet the requirements. In this case, its relationship with other complementary resources may allow it to offer a virtually complete profile for the specifications of the business need. Here, an accompanying problem can be that existing inter-resource relationships may actually reduce the effective availability of a discrete resource for duty, by too strongly capturing the resource within a virtual profile that is inappropriate for the current demand.

III.

Creating the composite of a resource's functional assignments and inter-resource relationships, the characteristics making up the functional profile of the resource are its configuration.

In this light, a defined configuration's lifecycle, from inception to retirement, is consequential only to the degree that at any time it's current phase is associated with business demand.

That association -- seen in terms of whether the resource is both appropriate and available -- translates into quality and capacity management issues mainly significant for addressing the performance of the business processes being served.

But the configuration itself -- seen in terms of the patterns of its utilization -- translates into access and impact management issues addressing the measurable value of creating, deploying, modifying or retiring the configuration in the face of feasible alternatives.

IV.

We can support management decisioning through storing descriptions in a configuration management database (CMDB) and analytically processing them.

As the nexus of business process management and asset value management, configuration management uses and controls the view of resources that evolves in those two dimensions -- emerging as an explanation of how to translate the IT architecture from an investment to a benefit.

Just as strategic product management connects market requirements to engineering, configuration management strategically connects business process requirements to asset management. The connection can be expressed as responsibilities that formalize the major intersections or "coordinates" of the two dimensions.

As seen in the following framework of such responsibilities, the dimensions are:
- the utilization performance spectrum (as in market or business process) ranging from enabling to strategic -- i.e. from a willingness to exploit the resource, to a need to optimize it;
- the production value spectrum (as in product or asset) ranging from planned to actual -- i.e., from initial discovery of an appropriate asset to proactive release of the asset (into production).

(click here for enlargement.)

While the framework does not intend to presribe any overall method for managing resource information, it does provide a context that presents resource description data as business intelligence. As an example of the implications of the framework, the illustration further observes that the intelligence can be approached from the general operational perspective of aligning resource versions with business practices that operations logically direct through usage accounts and usage models -- providing effective management of services.

Note: in this framework, the idea of "discovery" is important to the purpose of communicating that whether assets are built, borrowed or bought, the key business production issue is for the business process to find an appropriate available asset for use as a resource.

Posted by Malcolm Ryder at 8:58 PM | Comments (0) | TrackBack

August 29, 2005

Balancing Governance and Strategy with Portfolios

I.

Old-timers and enthusiasts in the camera buff crowd know about the old twin-lens cameras. Back in the day, the camera had two lenses. One lens let you see what you wanted to take a picture of. The other lens let the film see what it was going to take a picture of. The problem was that because the lenses were in two different places, the film didn't always see the same thing that you saw; and the proof of that would come up in the actual picture produced.

If your business is spending a lot of time looking at things through the lens called "ROI", what follows below is for you.

II.

Strategy would be pretty uninteresting if it didn't promise to enhance the state of the business.

Of course, a lot of things can fit under the umbrella of "enhanced states"... Typically, strategy talks about a future condition making the business either more immediately valuable or more secure in its ability to become more valuable. So naturally, the circumstances that strategy tends to address include business inhibitors to resolve, or business opportunities to exploit. The business idea of value is in managing those resolutions and exploits in the desirable direction.

None of this is news, but sometimes it helps to restate the obvious as a way of bringing a line of thought back into focus. This is a good thing to do whenever discussions about something press the notion of that "something" being "strategic" or not.

Did someone say "value"? Much of the time, business discussions decide that something is strategic if it delivers "ROI" -- or at least the assumption is that it better deliver ROI if it is strategic.

This view makes it seem practically easy to distinguish the non-strategic from the strategic, while it allows that the problem of actually determining the ROI might still be a bit gnarly. But a neglected problem, in practice, is that at this very point in the train of thought people too often forget that the actual strategy might be pretty complicated, too.

Why is this a problem? Because, without the framework of the strategy, it is too easy to mistake ROI for actual strategic value. How can that be? Easy: the only payback that is by agreement "strategic" is payback that promotes the objectives defined in the strategy -- yet not consulting the strategy won't prevent getting a payback anyway.

One of those lenses -- ROI or strategy -- is going to generate the picture you get, regardless of what the other lens sees. The trick is to put them in the right positions, and try to get them to agree.

III.

The real point of the exercise for projecting ROI is to maximize approval of the affordability of whatever effort is made. If "strategic" approval, or strategic justification, is the name of the ultimate game, then we must insist on being able to recognize value even if the net cost of the effort doesn't reach zero.

Through example, let's look closer at what this really means. Often there is a set of efforts that are just called "keep the lights on" efforts. These are not usually considered to be "strategic" efforts, although no rational executive would allow them to be ignored -- because of course if the lights are out then nothing else is likely to get done. Clearly, keeping the lights on is critical, and the value of doing that is enablement of something else. But what is the ROI of keeping the lights on?

The point is that ROI is an idea that should "inform" investment but probably should not dictate it. Something more important than ROI should be in control... namely, value. Meanwhile, the main thing to care about regarding investments is that a strategy must be invested in or it likely won't be realized.

IV.

Investments are commitments, so they link the strategy to the reality of managing the business.

With that said, the investment portfolio jumps into the scene.

But what is portfolio management? In "ROI and IT Investment", Tom Pisello of Alinean (via SearchCIO.com) states: "dollars are appropriately distributed between risky and stable investments according to a [portfolio owner's] profile and goals."

Heads up: the most important word in the whole definition is "appropriately"... Along with that, the key thing to understand is that a portfolio is not supposed to determine what is appropriate -- rather, it is supposed to ensure that commitments are in line with what has already been defined to be "appropriate".

Normally, that definition of "appropriate" will come from two sources: outcomes defined by strategy, and constraints defined by governance. What most businesses are after is outcomes that are opportunities, and constraints that are only minimally inhibitors.

This especially makes sense when the constraints and outcomes are aligned explicitly enough for managers to see and explain where their commitments can make the desired difference. The alignment will include prioritizations and trade-offs that decide how much opportunities and inhibitors are respectively allowed to influence actions.

In this situation, portfolios express what is "appropriate" by mapping the alignment of governance and strategy.

V.

Tom Pisello's key points about investing (i.e., commitment) logically start with the task of developing a view that also generates the elements of a strategy:

- Companies need an industry analysis to understand how new initiatives will achieve competitive gain.

As he sees it, IT governance then steps in, fulfilling two tall orders...

- CIOs have a solid grasp of business issues and communicate IT value across the executive team.

Then the portfolio steps in...

- Technology executives have a holistic view of all IT projects and resources across the enterprise.

It might at first seem unlikely that "communicating IT value" would be convincing without the accountability provided by a portfolio, so is this step out of sequence? No -- there is an even more fundamental value-based view to include before the portfolio is constructed: architecture. For the moment let's ourselves just assume that architecture is placed in the mix during governance.

The final two items from Pisello together describe a gatekeeper function:

- Companies take new investment analysis from that business-need perspective first.

- Companies need a foundation of credible third-party ROI analysis on current and proposed projects.

Notably, business-need establishes why a proposed investment should be analyzed at all, while ROI analysis can provide a take on what the economic impact of the commitment might be. However, this is radically different from determining the economic impact of the outcome. There may be no more important thing to understand about a portfolio than this distinction.

Governance and Strategy are two lenses of the same camera. In managing commitments, how does the portfolio assure alignment of governance and strategy?

VI.
We already noticed that architecture is the base level of description for "IT value". This is the case because the technology product and the management agenda together called "I.T." have a single essential purpose: to provide a structured operational environment designed for business functions. Without this purpose, IT is simply another collection of assets. With the purpose, IT is a resource.

But the ability to actively translate that environmental support into business functionality means modeling the assignment of the existing resources to meet the necessary business priorities and trade-offs. Effectively, the demand on the resources must be modeled.

Portfolios represent assets as resources, and represent needs as demand, and synchronize the two, bringing the influence of governance into alignment with the influence of strategy.

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

August 18, 2005

A Management Support System for IT Service Value

Very recently I received an invitation from a colleague, Eugen Oetringer from EDS in the Netherlands, to study (and share commentary on) an IT Strategy Management Process design.

The most prominent feature of the design, in my first viewing, is the solution that it proposes to the practical problem of just-in-time research that is inherent in conducting service delivery while coping with change and diversity in IT operations. In fact, the design's emphasis on the responsibilities for "development" and "production" anchors its concepts in terminology that is inherently compatible with addressing Business clients in terms of specified quality and value. The noted challenge is that specifications are forwarded into operational environments that are often not built or managed to ensure successful communication. The consequence of that challenge is that alignment is forfeited or damaged between development and actual production, the second link (after specification to development) in the enterprise's value delivery chain.

Also at first reading, it seems equally valid to consider the design as a governance model instead of as a strategy management process. But for the sake of retaining appreciation of the scope of the design's importance, it may be more useful to emphasize that a process for managing the execution of strategy will have:
- a model that guides it,
- a performance objective that relies on compliance, and
- technologies that support the practical implementation of the model.

Eugen's design explicitly details those items in the context of accountability to business needs and policies, thus linking it conceptually with governance.

That said, the design's primary objective of describing how to bridge the gap between development and production winds up exploring how knowledge management supports change management in order to align IT with the business. One of the most important points to take away from the design is that "strategy" is a set of knowledge to be managed, and cultural adoption of the strategy is a result of empowering users to leverage the knowledge in order to adapt.

What does the support of this leverage look like? It is strategy lifecycle management. As the author puts it, "The IT Strategy Management Process takes the strategy from the owner, runs it through an approval workflow, publishes it to the target audience, drives for compliance, takes the feedback from the user communities, provides the feedback to the owner and drives the owner to release an updated version in a central repository."

The whitepaper reviewed above is here, and its parent book from the same author, published by Van Haren Publishing, is titled "The IT Strategy Management Process: Supporting IT Services through Effective Knowledge Management".

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

August 13, 2005

Business-IT Alignment: Three Levels of Change

It's most commonly said that the alignment of IT and Business focuses on the way that IT "delivers business value". Because of the pace and intensity of change within and around the business, the alignment effort emphasizes the need to define and protect both the deliverables and the integrity of the delivery path.

Said more carefully, IT delivers support of the value-capture modes of the business. This clarification points out that business value is not just "created at the IT point" and then run through a gauntlet of business issues on a delivery path.

But even that should be put more precisely. Instead, interlinked value-creating modes in a "value chain" are managed by the business, and IT is managed distinctively at each link, thus affecting the way that business value is ultimately realized.

Viewing that value chain as a hierarchy of dependencies lets us associate certain changes with different depths or levels of intervention, while still seeing that changes can simultaneously and independently occur on all levels. The challenge of alignment is to identify and coordinate these changes.

From the business point of view, change in the business affects the integrity and performance (i.e. success) of that "value chain" on three general levels.

One change level involves the definition of the basic components that are used to construct the business's production tools and procedures. Change alters the quality of the components.

Another and higher level involves the arrangement of the components into the various forms of facilities, resources and locations that the business uses in daily execution. Change alters these forms.

The highest level involves the agreements and expectations by which the business executes its activity towards goals, opportunity, and stakeholders. Change redirects activity and the demands it makes on underlying levels.

The following tabular diagram illustrates the active business elements in the management of the value chain versus change.
- A software application is taken as an example of IT being managed for alignment.
- As shown by the far left column and the center arrow, management expectations drive and constrain the cultivation of value at each link or level.
- These business expectations bear particular ways that IT functionality is developed into business resources.
- In turn, the effectiveness of those approaches is leveraged through operational management that works to confirm and conform the IT utilization to the business expectations.

Alignment must be seen as a business success factor if change across these levels is going to be strategic instead of merely opportunistic. Because the different levels and types of change are each independently sensitive to the strengths, weaknesses, opportunities and threats of the organization, management must continually view and assess the benefits and risks that various changes present to the value chain -- specifically, lowering the risk of driving benefits to the business bottom line.

Posted by Malcolm Ryder at 8:20 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)

August 5, 2005

Value Capture through Execution

What is the real point of an IT business case?

Most proposed changes to the IT infrastructure of a business are intended to make "execution" better. Better execution goes by many names: productivity, efficiency, resilience, intelligence, and more. Since a proposed change typically competes for attention and support against other proposals, the idea of "better" cannot be separated from the sense of what is "necessary"... This means that agreement on priorities must occur, and the black arts of winning agreement commence.

Certainly, the job of presenting a business case is to win the agreement, just as a prosecutor or defense lawyer is out to win. Yet in competition, these adversaries are unified in taking the same piece of strategic advice: "Don't confuse your issue with facts!" In other words, they openly give each other permission to exercise poetic license. But if your business decides to accept this modus operandi from its managers, then it should also just dispense with the requirement to argue in terms of ROI, as well.

In fact, the ROI bit is often misguided, anyway. If building engineers were held only to the standards that ROI calculators so often are, we've have to conduct the business mainly in large disposable tents. Why build a business case that won't stand up?

Instead of ROI, the business case should be argued on value. Strictly speaking, value is what you call the importance of a difference. If that importance is measurable in dollars then so much the better; but since the dollars come from the value, you first have to make the value . And just how is that done? A business case must be able to identify and convey the value generation. To do that, it has to start with a logical understanding of the phenomenon.

Let's start that with a solid working definition. Execution is: the pursuit of a goal, as based on certain enablers (means), in the context of desired types of achievement.

Organizing activity in terms of execution is the typical result of planning. Plans therefore might be prescriptions, formulas, methods, programs, or other designs for interaction and interdependency of activities.

According to the achievement level realized in execution, we say that a certain "performance" has occurred.

According to the importance of that performance in its context, we say that "value" has been generated.

The most straightforward example of a practical context is an objective. That brings us to the key point: that value accumulates towards an objective, and different types of value may collectively apply to a given objective. (For example, imagine watching various contributions of cash, supplies and services push up the red dye in the big "thermometer" poster used to advertise progress in a fundraising campaign...)

The objective represents a concern such as a perceived business need -- essentially, a strategically critical success factor of the way the business believes it must be or act in order to generate "business success". The most straightforward description of the business success is (when properly defined) the mission statement. Usually, a mission depends on several different things coordinating and cooperating effectively, which indicates that there is a variety of ways to add value. At any time, based on the collective effect of those things, the status of the pursuit may thus be deemed more-or-less "successful".

From that perspective, the proposal's idea about changing the way that the business is enabled to execute must always be, logically, about:
- improving the value of its performance, which means...
- improving the achievement of its underlying execution, which means...
- improving the effects of its enablement.

Therefore, any enablement option is meaningful because of its presumed and targeted effects; this describes the basic level of discussion of a business case for an enablement proposal.

Will the witness please answer the question!
Typically, enablement is seen as a deployment of resources, with the now classic categorization of resources being people/process/technology. Of course, there are other resources -- such as time, money and permission -- that are equally critical. But here, the main point is that investment in enablement will be directly attached to ways that resources are affected (moved, added, changed, combined, deleted), and those ways will be described in a plan. The resource view of the investment, however, is merely the left side of the proposal...

The right side must attach the investment directly to the execution that will drive "performance." How? Since value is derived from execution-in-context, and since the context is about what kind of difference is made, then what must be understood is the difference claimed to be addressed by the type of enablement proposed for funding.

As described by example of the following chart, this is a general perspective on planning and justification. The chart gives answers to the question "what is it about the business that the proposed enablement will affect, and how?" The answers to "what" are (across the top) aspects of the business for which improvement is a desired benefit. The answers to "how" are (down the left side) itemized issues that represent success factors addressed in the planning for performance.

In viewing this chart, it is important to remember that the overall business goal is not "value" but instead that the goal is a "mission success" -- a success that is predicated on the value added, by execution, towards business benefits. These benefits (across the top), which are high-priority for the business, are thus understood to be "objectives"... Finally, in our scenario, where the proposal is going to bring a "new" configuration of technology to the existing situation, the IT organization gains more power to enable the business -- which makes the IT organization more successful; therefore, the types of enablement that the proposal identifies are logically seen as "objectives" (down the left side) of the IT organization. This lets us understand why funding the proposal is an investment in both the business objectives and the IT objectives.

What's clear from the above is the investment idea of value for money. Each of the issues in the chart (such as exposure, efficiency or capacity) is an opportunity to generate value, using the support of funding. What's important about the detailed logic of the discussion is that "value" is not left casually misrepresented by so-called ROI. Instead, value is something showing explicitly why the proposal makes sense; and in turn, that provides more logical support for economic impacts that are associated with the proposal. Without establishing the logic of the value-generation, calculations of economic impact are speculative.

Punchline: ROI does not validate the business case; instead, the business case validates the ROI.

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

August 4, 2005

How Maturity Models Drive Timely Value-Capture

The most basic problem of IT alignment with Business is the need for IT to improve business capabilities within the business's ability to pay.

Of course, the ability to pay is supposed to be a product of good capabilities, so... the question is this: how far in advance of its payoff can we afford the initial capability improvement?

This reminds me of the promise of cold fusion, wherein two key things are at stake. One, the nuclear reaction must produce more energy than it consumes. Two, the reaction must be manageable, as in non-destructive in room-temperature conditions.

In the business scenario, money is the energy, and change-impact is the risk of disruption, while the existing infrastructure is the "room temperature"... And there are big ambitions that come along with that scenario; but are they any more viable than cold fusion, or is it still mostly hype?

Here's one ambition: most capability improvement is "funded" in advance; let's imagine that the net economic gain from the ultimate improvement is as simple as subtracting its cost from the price of selling the capability.

Here's another: most risk of change-impact is prioritized by severity of interference posed to designated parties; let's imagine that the attractive new capabilities are usually really well siloed.

Now, when I snap my fingers, wake up… that hot new capability and its economic value boosting powers are the children of complexity and integration, not simplicity and separation. Why?

Likely, because the capability is, operationally, a process that is orchestrated and optimized across multiple functions, events, occasions, and/or organizations. That's a lot of opportunity for interference. And the net dollar gain tends to be reached by gradual accumulation of payback, not all at once. That's time during which the unexpected can happen.

So, while we're waiting for the dollar gain to pile up, we're carrying a lot of risk. There is an initial risk of disruption to existing conditions, and there is additional risk of discontinuity and error in the downstream run-time exercising of the new capability itself. Hmmm...

Naturally, we want some kind of quality measures to be in effect to minimize the risks -- particularly since taking the risks and losing will cost more money in the form of needed recoveries and remedies -- thereby eroding the presumed, potential, net gain.

Unfortunately, this game is much more about choosing the right risks than it is about avoiding them. The issue at hand is to choose the risks that must come with the desired changes, but to also manage those risks to the point where the probability of them hurting us is minimized. The risk doesn't go away; it just becomes more contained. That's the quality assurance.

What then about productivity? Generally, since a new capability comes with preconditions, and those preconditions are risky, then practically speaking, the capability becomes available to the extent that the risk is managed away from the scheme for productivity (in both the development and use of the capability). The question is, what is the level of manageability that can currently be exerted on the preconditions? The degree of manageability will impose a *constraint* on what kind and amount of influence the capability can have -- influence that directly drives the type and amount of value that can be generated. If value is generated in a smaller and slower way, there is not as much to redeem for economic gain, and it's not clear that the capability will ultimately generate "more energy than it consumes".

A maturity model directly addresses the problem of determining how to balance the risk, cost and productivity associated with making the new capability available.

The model proposes a universe of factors making up the full scope of complexity pertinent to the capability; those are the preconditions. Further, the model helps segment that universe of factors into various combinations. Different blends of factors -- featuring their types and intensities -- associate with the kind of influence the capability can render under their role as circumstances.

This segmenting allows a user of the model to think in terms of when a particular influence (that is, a possible outcome of the capability) needs to already be in hand, and to then begin investigating (in the segments) what it will take to reach that level from the current circumstances. And each kind of influence may turn out to require that a certain minimum degree of manageability be applied to its underpinning factors. In anticipating net gains, we can imagine what the capability's target influence might be worth, but the manageability behind it determines the cost and risk levels that will be active, making the influence feasible and viable or not.

As an example, let's say that the desired capability is "locomotion"... There are three interesting influences or aspects of that capability: speed, safety and reliability. The ability to generate maximum value (and associated economic gain) through this capability calls for all three aspects to be maximized. But initially, there simply may not be a realistic possibility of hitting all three at top levels. On the way from the initial development of the capability, one or two aspects may progress ahead of the others.

And what propels the progress? Here again there are multiple factors involved, such as capital, negotiating skills, science and technique, and other resources commonly needed for development. These development factors can, individually or in combination, affect the progress of support for speed, and/or safety, and/or reliability. The key issue is, what is the operational ability to apply these development factors against the different aspects of the locomotion capability?

It is always tempting to think of mastering the capability in terms of being expertly comprehensive. But this is not the basis of the capability's value to the business, and therefore it should not drive the roadmap for progress in mastering (i.e., maturing) the capability. Instead, a business-level prioritization must kick in.

Now let's say that for some reason the early desired use of the locomotion capability is for the purpose of shipping cargo. In this purpose, reliability, and possibly safety, might outweigh the importance of speed. But if the main purpose for the capability is to shorten personal travel time, then of course speed might at first outweigh safety and largely outweigh reliability.

Further, for example, if we're selling shipping, we can attribute dollar-importance to those factors (and their combinations) that most strongly enable that aspect of the overall locomotion capability. As a shipper, we might not prioritize speed, and instead look at the requirements and costs to develop and maintain reliability so that we can start shipping and billing for that sooner.

Later, with proceeds from our shipping business, we can invest in adding speed and perhaps expanding operations into personal transportation as well as shipping.

We shape our buildings, and then our buildings shape us. --Winston Churchill

Having been reshaped by our buildings, what should we expect when we build again? Through us, the previous building will have *indirectly shaped* the new building, and isn't that how our operations environment evolves?

What our example shows is how maturity models help to map out a managed evolution that creates value at each stage along the way.

Posted by Malcolm Ryder at 6:34 PM | Comments (0) | TrackBack

July 27, 2005

Performance Improvement requires Change Management

Performance Management is a concept best defined by business solution developers. That is, it is based on a definition of a problem called performance, and by focusing on a theory of the problem it derives many approaches and components of "solution"...

In a comparison of myriad definitions from vendors, analysts and industry journalists, the working common denominator appears to be "management of the alignment of people and technology to improve the effectiveness of their run-time support of business objectives."

One of the more significant notes about that consensus is that it does not include "processes" in its grasp. This might be for any of several (debatable) reasons, such as:
- business process management (BPM) is thought to be a peer of performance management rather than a part of it
- solving process problems is not thought to improve the solution of performance problems.

While both of those notions seem unlikely to be true, what makes them provocative is the way they force us to defend our theory of the "performance" problem. Indeed, since process management has already had intensive attention for years through automation and reengineering initiatives, the current idea that the "performance" problem has remained unsolved lends credibility to the sense that a focus on process is at best necessary but insufficient. The suggestion, then, is that a focus on performance is at least more important than, if not actually an alternative to, process management.

Put as simply as possible, the difference between process management and performance management is, respectively, the difference between "how to" and "how well"...

Defining the performance problem as "how well" readily explains the collection of interests addressed by performance management.

At the core of the problem theory, there is a set of target levels of activity impact or event impact.

The impacts are meaningful in any of several ways (contexts):
- financial
- legal
- operational

Standards or benchmarks are established and adopted to set impact targets in any of those contexts.

The compliance of operational outcomes with the impact standards is continuously monitored, which provides alerts and data for supporting further management decisions.

The fundamental issue is therefore how to manage impact targets and manage impact compliance.

This two-pronged management requirement means:
- deciding on what specific examples, mechanisms, and evaluation models to implement regarding targets, and
- doing likewise regarding compliance to the targets.

Given that perspective, it isn't surprising to hear lessons learned such as that offered in Intelligent Enterprise by former corporate planning chief and Hackett Group cofounder David Axson:

"you can put all sorts of policies and processes in place to try to achieve compliance, but if [that] doesn't change practices and behavior, your investment in compliance [initiatives] is of marginal value..."

And why is this a predictable outcome?

While policies deliver explicit guidelines and definitions to identify priorities and permissions, their effect is essentially environmental, leaving inhabitants with the politics and preferences of adapting to the environment -- in other words, with the latitude to not comply.

And while processes prescribe the rules of activity, they don't set the motivation. And the more complexity exists in the design of a process, the more opportunities there are for motivation to vary from what is minimally required by the process to meet its execution requirements -- in other words, to not meet the "standards" for support.

The punchline is that if "performance" is essentially the degree to which execution meets impact targets, and execution is a variable phenomenon driven by behavioral issues, then there is a two-tier prerequisite to performance improvement:

- successfully managing performance (to meet targets) will be critically dependent on deliberately managing the changes that affect behavior; and...

- successfully changing the impact targets (to define "improvement") will specifically require managing behavioral adaptations to the perceived opportunities and risks of the "working landscape" offered by the new environment that compliance prescribes.

So what about technology? How does that play into the situation?

The two dominant ways that technology affects the situation are procedural automation and communications. Typically, business requirements for speed and accuracy in work flows mean that people depend on the efficiency gained through technology to "effectively" initiate, intervene and interact. However, leveraging technology functionalities offers appropriate impacts when in the right hands, and risks inappropriate impacts in the wrong hands. What makes this particularly important is the pervasiveness of the technology. Consequently, the secret to technology's role in its alignment with people is in how the administration of the technology allows the organizational structure to drive value by meeting targets. That is, technology is a critical environmental factor of organizational behaviors, affecting behaviors while also asking for behaviors to adapt to it.

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

July 22, 2005

Needs versus Requirements: the battle of Why versus How

There are many different enablers of higher performance in business, including capital, relationships, knowledge, position, tools and others. Of the more tangible ones amongst those various enablers, the alignment of tools (technologies) to the business still features the most vivid stories of uncertainty here in the post-dotcom period.

For most kinds of businesses, acquisition of technology has only one essentially distinctive purpose: to secure relatively uncontested on-demand access to the functionality of the technology, within the desired timeframe. Business interest in technology acquisition is not hard to understand at all, but the experience of acquisiton too often leads to buyer's remorse. What's worse, the same kind of failures occur year after year, as if we can't learn from the past. How do we get past this problem?

The marketplace offers truly great opportunity for technology access. But each of the key touchpoints in this access -- technologies, vendors, groups of users, and capital -- runs day-to-day on an agenda independent of the others.

Meanwhile, a company targeting technology access is running day-to-day on a mix of divers operations and users that generates many disparate demands, both planned and ad-hoc.

The result: supply and demand do not "self-organize" into well-matched sets. The connections have to be planned.

A technology access plan always navigates a path from the options provided at the access touchpoints to the necessities generated amongst the many company demands.

Normally, the path laid out will try to explain why the ultimate access to the targeted technology will be successful. But this level of concern is not the right place to start. Rather, the starting line is back where the "necessity" for the proposed access is being formulated and accepted.

Failure to clarify that formulation and its terms of acceptance will lead to technology implementations that fail to be adopted by the targeted users. Naturally, this adoption failure eliminates most of the basis on which productivity and ROI was predicated, while also ramping up sunk costs, contingency/recovery costs, and opportunity costs to fearsome levels.

The political fallout of the situation can be summed up as reactions to failed expectations of the implementation. For that reason, understanding the ideas about "necessity" that drove the implementation must involve the psychology of the expectations.

This explanation of "necessity" begins with the problem of identifying goals and assessing opportunities. Their combination is the basis of the behaviors that characterize the approach to the implementation.

These behaviors are mainly directed by beliefs, which are typically set forth as requirements and priorities.

Let's see how behaviors and beliefs interact to generate the perspective on "necessity":

This exposes the bases of how value is being attributed to whatever happens next. A key point to note here is that not all decision makers start at the same question in this matrix, and multiple stakeholders (different participating decision-makers) may not agree on the answer to any given question.

Such variety of perspective must be reconciled if the path to adoption is going to be successfully completed. Furthermore, it is important to not leave any of the matrix's four questions unanswered -- which partly explains why reconciliation will be challenging: no one gets let off the hook. To make the point even clearer, let's look at how this fundamental matrix translates into management-speak such as approval criteria:

Now it starts to emerge how so many business cases and other justifications produced may not logically account for adoption of the implementation even though they support approval to do it. The approval criteria (goals, capabilities, resources and effects) tend to test the current state of acceptance about specified conditions. This current acceptance is based on the interaction of factors that generate the "working versions" of reality and desire. (For example, consultants who provide assessments normally work in these terms, ofering a chance to validate or audit the presumed current state versus the "actual" current state, thus gauging a client's "readiness" and/or a tool's "compatibility".) By logically connecting the issues (clockwise within the matrix) from Goals (top left) to Effects, a comfort level is reached for approval, based on a story of "how this makes sense".

But the remaining problem, which is demonstrated by implementations that fail to be adopted, is the problem of "why" the implementation makes sense.

The key to exposing this is to understand that implementations work when they corespond to the behaviors that the company wants. And we know that behaviors are directed by beliefs, so the expectations of the implementation must correspond to beliefs. To represent this correspondence -- and get to the root of the "necessity" thought to exist -- the company must be willing to understand and agree on the terms of "why", which are more about the company itself and explain what the imlementation is actually supposed to address:

Again moving clockwise, from Motivations on around to Benefits, can the company confirm the logical links all the way around, and in particular, is the last link -- betwen the benefits and the motivation -- revealing something that can be attributed to the impact of the implemented technology?

The vocabulary of our last matrix challenges the specification of the implementation to describe enablement and support in terms of the company, but will reveal whether the company knows itself well enough to successfully adopt an implementation with reason to presume effectiveness. This is particularly critical in cases featuring multiple stakeholders, who hold the adoption cards rather than the approval cards.

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

June 28, 2005

Productivity versus Competency

Which comes first, productivity or competency?

If the question is hard to answer, it's because the two things are easy to confuse when we're under the gun. That's a problem because when we don't know the difference between them, our activity can amount to less than the needed achievement, and missed objectives can trigger remedial efforts that actually "solve" the wrong problem.

Productivity, as our pals at McKinsey state it, is a ratio of inputs to outputs. Without having to say more, that points us directly at whatever the process is between the inputs and outputs. Naturally, improving processes would be the right step towards improving productivity. And for most organizations, getting process religion is virtually indistinguishable from their promises to become more "competent". By equating process and competency, this view proposes that competency underlies productivity. Its point of view is about "competently conducting high-quality processes."

But meanwhile, is that all there is to the role and measure of competency? Not really; the scope of its significance is far greater.

The simple, generic difference between process and competency is that a process is a prescribed pattern of activity, whereas a competency is a confirmed ability to act appropriately to the circumstances. This is a case of lurking synecdoche, where it's important to note that a square is a rectangle but a rectangle is not necessarily a square. A process is a way to demonstrate a competency, but competency is not always necessarily demonstrated in the form of a process. In fact, competency can be demonstrated simply by "judgement" -- that is, by decisions that put (and maintain) you in the right place at the right time.

Granted, the intuitive (or at least conventional) ideas of competency are usually about demonstrating that one is "up to the task". But the idea of "effective" is a better way to go to that point. Effectiveness is a determination that must be able to express the value of the result regardless of the mechanism that produced it; thus effectiveness allows a wide range of sources not restricted to competency. "Winning ugly" (a fact of life) tells us that we only assume effectiveness requires competency...

When you get down to it, competency is something that should be understood on its own terms, and only thereafter related to other circumstances such as a particular task or the pursuit of a given objective.

So, let's remove productivity, process and effectiveness from the foreground, and get a good direct look at competency.

One of the most persistent aspects of the meaning of "competency" is "fitness to the occasion", or alignment. This still makes us think about the ability to appropriately execute in the occasion.

But it turns out that the fitness in competency is much more about the kind of solution that fits the problem solver, rather than the kind of problem that is challenging the solver. It's the difference between "being great at using hammers to solve problems" versus "being great at solving problem type X"... There's more than one way to skin a cat, but not all solutions to a problem are equal, and not all solvers are capable of the same kinds of solutions. The key issue is whether the organization is capable of bringing the solution that we believe is most appropriate to the problem.

Considering "capability" as opposed to "task", fitness is a great word because it involves addressing the variables that together describe the nature of a circumstance. Below, the diagram shows the variables that need to be addressed by business competency. The actual competency of a given organization will be the blended capabilities it can bring via innovation, productivity, standards and expertise. The particular blend it brings will be more suited to certain situations than to others, and the challenge is to identify which situations actually "net out" in alignment with the organization given its actual competency. The situations that do align might be visible and interesting to the organization, but they might not -- and organizations can also mis-direct their competency.

The level of abstraction of this framework allows it to be ported across disciplines and to be very scalable to circumstances. The abstraction emphasizes that competency is inherently (internally) established on unchanging fundamentals, while ideally applied (externally) as a matter of reasoned choice.

In the picture, the sides of the square are the characteristics against which the organization positions itself in its target circumstance (e.g., in a market or relationship), while the corners are where (and how) requirements are met. In effect, the corners link the sides together in issues that the organization should address to assure relevance or fit, and thus set up to drive value.

Failure at the corners is risky -- it leaves the relationships of the sides arbitrary or irrational, and it makes the organization's offerings to the sides unpredictable and/or unproductive. Accordingly, in the organization's current circumstances, such difficulties should be examined as if they are symptoms of failure at the corners.

The sides must be developed as well: poor determination of the sides will result in a mis-fit or disoriented organization.

Techniques for improvement at the corners and sides are varied, including learning, collaborating, partnering, and others... Those capability-enhancement techniques may themselves be executed through processes that are developed, measured and matured through improvement initiatives.

Consequently, for most organizations, a combination of a capability maturity model and a scorecard is great instrumentation (yet not exhaustive) for managing competency. Typically these are employed in "performance management" efforts. But in light of the above, it is clear that the overall goal is to be able to pre-emptively gauge risks to effectiveness.

Thus we understand that the competency issue is not fundamentally about productivity, but instead is about risk management. And in turn, the riddle is solved: productivity and competency are complementary but they are not causally related; instead, they are correlated.

Posted by Malcolm Ryder at 8:08 PM | Comments (0) | TrackBack

June 26, 2005

Can Collaboration Improve Processes?

Processes live on the communication of critical information about events. Can collaboration do for processes what infrastructure does for systems?

We normally rely on "process" to maximize our chance to leverage a perceived opportunity. Yet sometimes the process doesn't get the job done for us. A mismatch of some kind occurs between what the process can deliver and what satisfies the requirement of the situation.

Knowing that can happen, we've all had moments when we could use some extra help, but the help that was available wasn't the help that we wanted, and we faced a trade-off. At times like that, our instinctive aversion to risk often overrides the willingness to change for gain -- and either we fall back on an existing substitute approach or we let the opportunity go by.

In the parlance of value and performance, that's a comparison of opportunity cost versus effectiveness. At the trade-off moment in the scenario, we're "forecasting", not experiencing, both sides of the trade-off -- pain versus gain -- and this means that the expectations we form become the virtual reality to which we respond. We pin our sense of "effectiveness" on the expectation, and the risk is that we'll therefore underachieve.

Effectiveness is really a measure of how well opportunity has been exploited. But because our ability to assess opportunity cost shapes our perception of opportunity itself, it changes what we think we can do. Consequently, that assessment ability is actually one of the decisive terms of our probable ultimate effectiveness.

What does this mean about process? When we feel that we need help beyond the current process, we are usually thinking either that:
- the process requirements are beyond our own range of ability, and/or...
- the opportunity requirements are beyond the range of the process.

It follows that when our operation is hampered by either of those problems, the two main types of help are:
- bringing added execution capabilities to the process; and
- supplementing the process with "more processes".

What we have to realize is that in either of those two cases, something other than "process" might be the missing piece of our effort. How does the missing piece change things?

The essential purpose of a process is to make causality manageable and practical. But in order to get effectiveness from this, the results of the management must be relevant to the occasion at hand. The occasion asks the process to make certain things happen, and the process must leverage available resources to generate appropriate results. The available resources are, in effect, the environment of the process.

This is similar to the relationship between a system and its infrastructure. A system manages the interoperability of components, but this succeeds only because the system can draw on an underlying infrastructure that supports the system's functions. The infrastructure is the "environment" of the system.

Improving the supporting environment can add more execution capabilities. This can be approached in two ways:
- enrich the environment so that it offers more choices that are useful to the process or system; or
- optimize the environment for a particular process or system.

In the case of processes, how is that done? Looking under a process, the main visible infrastructure elements are knowledge, instruments, agents and rules.

Knowledge: brings the ability to proactively determine the likely impact of choices and conditions

Instruments: bring the tools appropriate for making decisions and for manipulating conditions based on decisions

Agents: bring the positioning and skills necessary to leverage conditions towards targeted states, primarily through use of the instruments

Rules: bring the terms of acceptability for types of actions per condition.

Systemically blended, the four elements create a process component that can convert a defined type of input in a predictable way. Correspondingly, because the conversion is predictable, the output may also be predictable.

But the essential responsibility of a process is to do the input conversion in a certain way, not to generate a uniquely specified output.

That sounds wrong, but we know it is actually true -- because experience has already shown that for us to obtain a specified result our own current processes are not the only way:
- there is "luck";
- there are alternative processes; and...
- beyond luck and process there is "service", where someone else handles the issue altogether in a way we are not responsible for...

The main reasons we use processes ourselves, with the responsibility for their output, are:
- to minimize uncertainty, and...
- to maximize autonomy.

Thus, if we run into a process deficiency, and we need to improve effectiveness in the face of the pain-vs.-gain trade-off, then certainty and autonomy are at stake.

In general, infrastructure supports the process vis-a-vis uncertainty and autonomy.
- For minimizing uncertainty, infrastructure features "configuration" that assures conditions critical to relating targeted events internal to a process.
- For maximizing autonomy, infrastructure features management control of the resources needed to maintain the components of the process.

With those effects, the process assurance fortifies its permission to execute -- a privilege often dependent on whether the infrastructure is tolerated by the customers and sponsors of the process. (For example: some consumers won't authorize delivery through ground transportation; some programmer/analysts won't authorize processing through a certain database management system; some messengers won't authorize transmission through a certain channel; etc.)

This is the context in which we should consider the prospect of collaboration as an "improvement"...In terms of processes, will collaboration have to help minimize uncertainty, maximize autonomy, and leverage permission?

The key thing to keep in mind is that the goal is to improve the effectiveness of the process, not necessarily to change the process itself.

By improving the environment of the process, its effectiveness can be improved. Collaboration can improve the process environment by making the management of resources better for the process.

By definition, collaboration means that two parties are working together (co-labor). In using collaboration for process effectiveness improvement, the point of the collaboration is to have the different parties each become part of the same process by their literally "co-operating" the process towards the given goal.

Defining responsibilities is a critical part of designing systemic co-operation. This design directs how the underlying elements are blended to generate the process components. In this co-operation, collaboration specifically begins when the roles of individual parties are accountable for the elements that make up process components: knowledge, instruments, agents and rules. Responsibilities then relate the roles to each other as a "process infrastructure".

To increase effectiveness, collaboration can attend to supporting multiple processes, and/or it can support optimizing any given process to certain requirements.

In particular, process optimization refers to the process being able to dynamically select and orchestrate the best resources for operating against real-time requirements. As a managed activity, collaboration is part of that orchestration.

By leveraging the availability and scale of a larger community of resources, collaboration produces an infrastructure (i.e. functional environment) in a way that allows the process valuable freedom from customary constraints of resource availability and scale that otherwise might leave the process short of capability to fulfill real-time requirements.

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

June 18, 2005

My Daddy Spent Two Weeks at the Strategy Table, and All I Got was this Lousy KPI

Here's a story for IT management, but bear with me.

Marketing guru Seth Godin was annoyed by companies just not trying hard enough, so he busted them -- leaving them with the JSLogan strategy teaser Would You Rather Have Great Marketing and Sales or A Great Product?

Well, let's see.

First let's assume that there is a difference between a customer (someone who buys something) and a user (who is just someone that somehow already has something). Products often have WAY more users than there are customers.

Great marketing often creates customers. Mediocre products often get rid of them.

Great products do not create customers; great products keep them.

But the problem isn't really dealt with unless you include the issue of sales. If you don't need sales, then you're just in a whole different game than if you do need sales.

Marketing doesn't create sales. Products don't create sales.
Customers create sales. (Remember? It's their money, and they have to give it to you or there is no sale!)

If you need sales, you want your marketing to get out there and create those customers, so that they'll have a chance to create sales.

If you don't need sales, then you can use your resources instead to produce great products.

So if you had to choose, which is more important?

This seems like just a game, but when you think about it, don't most companies ask themselves "Why can't we have both?" And for any company that does ask the question, the problem quickly arises of having the issues competing against each other, forced by the boundaries of the budget and the hurry-up of more competition from outside.

Strategy then tries to work out the problem, providing the rationale for deciding relative importance. Prioritizing is always annoying when it means that you have to play the choose your pain game. But without prioritizing, there's little point in trying to "manage performance", and without managing performance there is little point in strategy...

The challenge in prioritizing is that it requires a lot of logic, and faulty logic will probably leave you with any of three good performance inhibitors:
- focussed on the wrong problem
- replacing action with debate, or
- trying to get from point A to point C without going through point B!

So, thinking through the activity measurements you use now, especialy the ones you call "productivity", how many of them are dedicated to faulty logic? Are they trying to show products creating customers?

Now how about this: are they trying to show IT creating business results?

IT doesn't create business results; business relationships create business conditions conducive to events that produce business results. IT supports business relationships. Is anyone measuring the relationship support? How about the business conditions? What are the forms of relationship support provided by IT? If those forms are not known or understood, then how can an activity measurement possibly be a key indicator of performance?

There are three ways to spin off from this story.

One: bad strategy, which comes from bad logic, is a bad thing.If it cranks out misguided KPIs, and you put a lot of energy into executing on those KPIs, you'll redline your organization. Better go check out the performance logic in the strategy.

Two: IT doesn't only support relationships. Obviously, technology has the power to directly create environments too, meaning "conditions", in which relationships can grow and prosper. Likewise, technology can directly create "events" by empowering certain things to happen that otherwise just couldn't... But the business logic of these things is that your company assigns technology to do those tricks and leverage them in the context of the purpose of the relationships -- so they are basically forms of relationship support.

And three: internal relationships that build the company count too. The parts of the organization that do marketing, or sales, product development, etc., all consist of key relationships driving their respective results, and IT must support those relationships. Strategy doesn't make the suport of one less important than of another. Instead, strategy tailors the particular way of supporting each one, by declaring what characteristics of each one are currently most necessary.

So, once that KPI (key performance indicator) is presented in the IT plan, it's worth "auditing" it to be sure that it is really about solving the right problem.

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

June 16, 2005

Linking Business Performance and IT Performance

Usually this subject starts off with the word "alignment" in the banner, which amounts to a freebie in getting folks' attention. Why resist here?

The idea of "linking" instead of aligning comes from the sense of correlating Business results and IT results, just as we would say "evidence shows that the consumption of lots of butter is linked to weight gains" or that "drug abuse is linked to higher crime rates".

Correlation generates something we can call the tension of implied causality. The challenge is to see through the implication and find out where the correlation is coming from.

If we take the word "performance" to mean "the degree to which functional outcomes have achieved targeted levels", right away it becomes important to see what distinguishes the IT targets from the business targets.

The business-side follow-up to that step is to ask, "in what way are the targets of the IT functions relevant to the business?"

Examining relevancy turns out to be the breakthrough. For any business, there is a general way to describe its functional ambitions.
- Every business needs opportunity, and operations with which to pursue them.
- In the face of market forces, the business must be concerned with supporting both the operations and opportunity, and also with transforming them as necessary.

The key business question is, given those two facts, what does IT do that matters?

As shown here, IT contributes to establishing and protecting the ability of the business to leverage the environment that it is in. With IT's contributions, the business can develop itself against requirements at an acceptable level of risk. The business has four really big stories to tell.

Each of the four stories -- Agility, Effectiveness, Deployment and Availability -- represents a major capability of the business functionality that responds to a critical requirement. IT's role is to "provide for" (not simply to supply or deliver) the capability. For the tactical capability to support business operation, the business looks at IT's contributions to Availability, such as through service management. A strategic capability, such as for transforming opportunity by exercising a competitive competency, tells the business to look at IT's contributions to Effectiveness, such as through BPM. IT would likely bring Change Management contributions to Deployment, allowing risk-controlled reconfigurations of workgroups and systems to enable transformation of operations. And so forth.

The punchline of this picture is that, seen through targeted contributions to business capability, IT performance is "linked" to business performance in a way that is best discussed as IT's business value.

IT's strategy for making those contributions is not the same thing as the business strategy, but the business strategy will impose priorities and weights on the four general capabilities, and IT will then strategically respond to that. By understanding how those business weights and priorities originate, IT managers can be more proactive in foreseeing and recommending IT contributions that are strategically sustainable and valuable.

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

June 15, 2005

Business-IT Convergence? What happened to Alignment?

CIO Magazine, covering thinking from their CIO's Perspectives on Enterprise Value conference, reports that we've gotten ourselves into another semantic knot. But not a tough one. The debate pits "convergence" versus "alignment". Is Convergence the new and improved Alignment? Is it time to change horses again?

Perhaps what's going on here, in this overall discussion, is just reverse-engineering the underlying systems of a good plan...

Alignment (noun) is a process having the objective of real-time structural compatibility. But convergence (noun) is an event, literally a co-incident, with the characteristic of having critical influence on the state or direction towards some outcome (which is why we care to notice it).

Fundamentally, alignment emphasizes compatibility -- essentially, "usefulness". Convergence emphasizes concurrence -- essentially, "agreement".

But the two-ton idea casting a shadow over both alignment and convergence is "Integration". What hasn't changed with the terms-du-jour is a goal of integrating whatever is called "business strategy" with whatever is called "IT strategy". What has changed is that we now can usually distinguish the need to have operational motives align from the need to have operational outputs converge.

As we move into performance management, we kick things up a level where we then start working on the problem of "making outputs align" and "making objectives converge"; but we already call that "planning."

Posted by Malcolm Ryder at 6:50 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 24, 2005

Optimizing Performance Capacity

Concepts like the Balanced Scorecard have shown that the notion of business performance should be built on a logical foundation of contributions identified from multiple corporate perspectives.

The BSC perspectives -- which describe the overall set of interactions between a workforce, the process designs, the market requirements, and the economy -- give a good account of the "biology" of the business.

The organic flavor of the Balanced Scorecard (BSC) set a benchmark of expectations about a management team's ability to describe the underlying complexity of operational effectiveness. It neither downplayed the complexity, nor asked for overwhelmingly detailed intelligence. Furthermore, it had strong intuitive appeal to the virtuous management desire to "take care of the business" in terms of health and prosperity, not just wins and dollars.

Yet with amazing consistency, senior executives cite the same two shortcomings in the attempt to adopt of the BSC. On the one hand, it didn't tell companies how to accomplish the linkages that it described; and on the other hand it wasn't a boon to profitability within the short and brutal cycles of typical "performance measurement." Some companies get it done anyway, but most who try don't.

Understanding that the BSC consciousness is institutionalized in evolutionary fashion helps to put these shortcomings in perspective (no pun intended). In a sense, the major focus of the BSC is accountability. It provides a guide to constructing the explanation of why things worked the way they did. As management tries to attribute outcomes more consistently to the "biological fundamentals" represented by the BSC's four perspectives, it is actually trying to account for how health drives performance.

More often, though, management is pressed to describe how competency drives performance, and this is a view that is coming into focus more rapidly now than before. Due to the distinctive pressures of the current business climate, the major issues controlling the dynamics of the business outcomes are strategy, efficiency, and governance.

The following graphic shows why this is the case: the three high-level variables or "levers" of corporate management are
- direction and purpose against market shifts;
- bandwidth; against the economy; and,
- permission under regulatory constraints.
When any one of those three variables changes, there is a corresponding risk or opportunity created in the three management concerns that link them together -- those links being priority, availablity, and authority (as seen below):

Those management links are the very ones that obviously dominate the decisions about what to do, what to change and what to stop -- in other words, they are the internal business drivers that put competencies like strategy, efficiency and governance into play. The goal is to optimize their balance so that the overall response capacity of the organization can be held at a maximum.

In sum, reviewing events according to this view accounts for how the organization is brought to a state that is best for business agility and continuity.

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

Aligning Operations and Strategy

"So, you know how to get there, right?"

In business, results rule. Understanding the results of operations is typically the dominant issue in management communications between different levels and departments of a company.

This accumulated understanding is key to synchronizing operations throughout the enterprise; and by providing end-to-end support for fulfilling business requests, that synchronicity allows current priorities to be a successfully demanding driver of operations.

But different parts of the organization respond to different kinds of requests. Over time, if a common awareness of objectives is lost, the request-driven results being observed more easily diverge from strategy, and those results are then much harder to use as representations or predictors of future performance.

To minimize or prevent this divergence, the organization needs a shared and consistent view of the big picture -- consistency that provides an on-demand ability to refresh the awareness of shared objectives, across the multiple parties involved in the pursuit and across the multiple occasions in which action must be prioritized.

"Honey, please stop and ask for directions..."

The organization's most consistent view of a strategy comes not from the analysis of results but from the enterprise-wide publication of the plan.

Drawn from that awareness, a management-grade depiction of planned organizational readiness would cover the state of the organization spanning all possible states to all actual states.

Put that way, the task first seems to require a prohibitively large amount of descriptive information; yet ordinarily the company fully attends to getting that scope of information by capturing it through processes and the systems that host those processes. With the numerous information sources, creating the "big picture" is not done through brute force but instead through compiling surgical slices of observations that are each shaped by a particular point-of-view. Because there can be an almost unlimited variety in the points-of-view, the classic problem is to prioritize them, and then to coordinate the ones that are most important. The compilation is a model.

This model helps to reveal, remedy, and support key interdependencies amongst the differing responsibilities and authorities that run the business day-to-day. Consequently, it is seen as a critical success factor in understanding how the organization is really functioning.

But what is the model's prevailing logic for coordinating those differing views? Is the logic oriented towards explaining results or towards monitoring objectives?

"Are you sure we can get there from here?"

We want to say that the logic must be oriented to both... but this rarely happens except in product management or in project management.

Outside of those two domains, there still needs to be a framework in which operations are synchronized in a way that can account for both objectives and results, while allowing changing priorities to be flexibly accommodated.

This framework must take into account the different perspectives on organizational readiness that are usually established by managers. The question: what is the organization ready for? In taking responsibilities for issues ranging from all possible to all actual states, "management" sees selected, authorized, and assigned states.

But while managers are doing that, operations must make things happen through the front-lines perspective on current demand versus its capabilities to respond. The operational perspective recognizes and must handle constraints that appear in another spectrum of concerns -- going from demand, to associated requirements, to response options, and then final responses.

A key management problem is that organizational readiness and operational perspective can develop independently of each other as separate pre-dispositions -- without productively converging or co-operating. This source of misalignment must be rigorously minimized.

"Okay that's it. Gimme the keys."

The Archestra framework cross-references the organizational and operational issues.

On the organizational side, the problem is to correctly determine the positioning of the organizational unit within the implications of the strategy. On the operational side, the problem is to identify the availability factors that underpin decisions and responses.

When organizational positioning and operational availability are reconciled, the proper throughput of energies is established for objectives to drive results. Alignment solutions must provide support for the intersection of positioning and availability.

Copyright 2004 M. Ryder
Click here for an enlarged detail of the populated framework, showing the reconciliation touchpoints.
For a review of how to develop solution models from the framework, contact me via email.

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

May 20, 2005

Who is IT's customer?

It's the spring of 2005, and this week's reading was similar to most prior weeks in that analysts and consultants pointed IT towards achieving more strategic delivery of value by focusing on the "customer". But as usual, there is a buffet of choices about who the IT customer actually is: direct, indirect, internal, external, and more, and mixes of them to boot. Does this make the original question to unwieldy to be helpful?

As a preface to answering, it's worth noting that there are different reasons for IT in a business because there are different kinds of businesses. It's reasonable to assume that the focus of IT should "default" to the needs of the business model.

This assumption makes the discussion begin with how those needs are articulated into supporting operations that IT enables, producing the satisfaction of the needs.

How does the business define and measure that satisfaction?

One perspective looks at results that represent the concrete outputs mandated for delivery to stakeholders. The stakeholders include customers, employees, shareholders, and basically any other "business partners" who measurably and intentionally contribute to the protection, health and growth of the designated business.

Another perspective looks at the functional mechanism for the production of those outputs. This mechanism includes the resources, systems and fulfillment processes that day-to-day generate the business deliverables within established costs, priorities and locations.

We're used to seeing assessment techniques that hold IT "accountable" -- sometimes for the results, but sometimes for production. Those assessments have a lot in common, though, because the implications of doing any of them is always the same. They investigate whether IT's impact is:
- desirable;
- optional; and/or
- exclusively or uniquely due to IT.

With those facts in hand, the next stage of consideration is:
- should any of those impact characteristics change?
- who cares if they do or don't?
- why do they care?
- how much do we care about who cares?

Imagine not asking those last four questions: omitting them leaves no way at all to determine a connection of IT to business strategy. This argues that there is a level on which what IT does is promoting things either towards or away from strategy, but that there is a different level on which the business actually responds to the opportunity given it by IT and closes the deal in the form of measurable value delivered and gained.

That level is... business management. And this means that business managers are the direct customer of IT. To make this point more strongly, let's look at what it means to be a "customer".

As a customer, you have what we'll call a need. Your need is based on the desire to have and use a capability of some kind for yourself. To satisfy that need, you search for and acquire an enabler of that capability. The enabler is what we call a "product". The way that the enabler works for you is what distinguishes it as one kind of product versus another kind. Typically, what IT provides is an impact that can be delivered as a product. The impact may be delivered in the form of a tool or a service (and therefore note that a "service" is a product). Once the recipient starts doing something with the impact/product, the capability exercized by that user becomes the sign of the "customer's" presence.

If we look at a business, and we think of how IT gets used, we usually come up with multiple types and populations of users. But if we imagine removing IT impacts (the enabling "product") from any of those user-groups, the effects on the business will be most crippling when IT impacts are removed from managers. Why? Because the success of the business is fundamentally predicated on targeted functional organization, not on labor output -- and at a fairly low threshold of combined speed and size, competitively sustaining the organization is virtually impossible without IT-enabled management.

So, if we assume that the business must have IT, then it is easy to see who is the primary "customer" of that IT.

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

May 11, 2005

The new architecture of Business alignment: Services

This discussion is one in a long series about how Business derives value from IT.

In this discussion, Business is wondering how IT can better support the functional capacity that Business needs in order to address its market requirements.

This functional capacity decomposes into qualities, economies and availabilities derived from the arrangement and interactivity of "components" of information technology.

But here is where the going gets gnarly. The notion of components is meaningless unless components are given roles that explain their reason for being involved and that effectively issue design requirements for the components. Examples of roles would be support functions that make up data communication, information management, or event synchronization.

Architecture manages the design of both the components and their relationships, according to their roles. Given that, the superceding business issue is to agree on what kind of effects the roles are supporting.

Establishing the value of roles

Rather than listing an undifferentiated universe of "important business effects", effects should be classified according to the way the business recognizes value being generated.

These classes of effects make sense when they logically discriminate the conditions in which a given effect has a certain type of value.

Generally, the business needs to run in certain conditions, and in those given conditions it needs to do certain things to a certain effect. This means we should take into consideration a difference between environmental values and operational values. They need to be respected separately because they can change independently of each other.

Despite that, IT implementations are often asked to solve both problems -- that is, to create the conditions and to prosecute functions in the conditions that they created.

After all, that is precisely the holy grail of "automation". Think of it this way: we ask a Hum-Vee to make inhibiting terrain navigable so that we can transport something through it in the Hum-Vee. Likewise, we ask radar to guide missiles. We ask spreadsheets to derive answers. We ask process modelers to write executable code. Or as the guys at Sun Microsystems used to like to say, we want the network to bethe computer...

Since we admit that we mainly like technology because we like automation, it's understandable that we might struggle with separating the environmental aspect and the operational aspect. We don't like the environment and the operation to be separate.

Engineering the effectiveness

Annoyingly, they don't readily cooperate with us unless we intervene in a big way.

The latest industry-level intervention -- the new zenith of automation -- is utility computing. Utility computing does things to the computing environment that makes the environment more worth doing things in.

As noted by Quocirca (and found via Silicon.com), "vendors such as IBM, Microsoft, Oracle and HP use terms as diverse as 'on demand', 'agile business', 'grid computing' and 'adaptive infrastructure' to describe their visions of utility computing, but the general push is similar, even if the rhetoric is different."

Despite the similarities, there are really two different pushes: one is about IT serving the business, and the other is about the business serving its market.

This starts to remind me of a typical "value chain" -- in which several different roles correspond to fulfill an order for a deliverable of known (or at least agreed-upon) effective value. We already know that value chains are actually complex and asynchronous, distributed over time and space. But then they are brought to the task of fulfillment specifically by agreements amongst them to also collaboratively operate a supply chain.

The value chain is how we can catalog the classes of effects. For example, printing a finished report at my desk, developed from live raw data stored in a computer in Switzerland, means invoking a value chain with links that can:
- understand and accept my request
- decompose it into subrequests
- farm out the subrequests to producers
- produce the components of the deliverable
- coordinate those production artifacts in the desired format
- route the resulting compound product to me.

In fact, each link in the value chain can represent a certain class of services, resulting from supplier and consumer agreements (about effects) typically made at each link.

But for the chain to finally deliver value, alignment of the services is needed, meaning that the success of the precedent service reliably promotes the success of the subsequent one. So it seems reasonable to ask more carefully what "success" means in both cases.

When it comes to services, the specific issue of "providing for" is crucially important to understand: a supplier may or may not be the creator of the product or operator of the production effort that we expect to be the "deliverable" gained by the consumer. But the supplier arranges for the deliverable to be received by the consumer, more or less on demand. The agreements that constitute the "service" also include definitions of when the demand will be respected by the supplier. That is, the demand itself must satisfy certain criteria, just as the deliverable must.

As consumers, though, one thing we always want is the maximum convenience in navigating the value chain to reach our fulfillment. I like exotically designed plastic pens, but I have no interest in being involved in the original oil-drilling that is making them available.

As suppliers, we want to maximize the economy of scope of our influence in the value chain. I don't want to be both a distributor and a manufacturer if I can get better "ROI" just being a distributor.

And the zinger is that at every link there is competition both for demand and for supply. I'm not the only one who wants to use the oil, and not everyone wants plastic pens.

Making it all workable

This is where an architecture of services kicks in.

The business purpose for architecture is to instantiate a value chain as an environment of several infrastructures -- that is, an environment that allows supply chains to be dynamically constructed from networks of value chains, for fulfilling demanded deliverables. By any name, this is basically what the Business wants the capability to do.

This is also where the difference emerges amongst the vendor spins on SOA. They differently prioritize the need for this environment.

For example, consider a business's current strategic priorities in its relations to its market. Does the business's current degree of automation allow the desired level of:
- Business capacity? (agile business)
- How about responsiveness? (on demand)
- How about risk? (grid)
- How about change? (adaptive infrastructure)

Now, for whichever of the above types, what is it that the Business thinks is suffering from an underlying undersupply of automation?
- Horsepower?
- Applications?
- Security?
- Continuity?
- other?

Role-based IT "components" will be conceived to support whatever issues the business has from combinations of concerns like the above. There are many many possible combinations... which tells us that there will be a wide array of value chains designed.

For now it seems that each link in each value chain might have its own optimal definition, which challenges the idea that a link can be shared by two chains (e.g like a node shared by two paths...) and threatens to dis-integrate infrastructures instead of integrating them. And should the infrastructure for a service link exploit a particular architecture to ensure its optimization?

Because we're already accustomed to having a network of networks (the internet), we can already abstractly imagine an architecture of architectures. But the complexity of that makes a unified environment seem quite far off into the future.

To make this struggle immediately less aggravating for the Business, we have the concept of services.

The practical usefulness of this concept is that it lets us represent a situation in which a "supplier" and a "consumer" agree on what are the salient characteristics of an "effect" -- and also agree on the terms of providing for that effect -- thus mapping the value chain. The question is, with more than one value chain at stake, how hard will it be to manage all the services desired?

The key to meeting this challenge would seem to be a broker that can discover, qualify and select advertised services. And this makes the service qualification process the heart of the new architecture.

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

May 4, 2005

Revisiting the Operations Trinity - People, Process and Technology

The "holy trinity" of operational effectiveness has, and will go on having, a long tenure. Getting people, process and technology working together is the goal and advice of nearly every expert on business systems; and it's one of the most familiar mantras of management.

The conventional advice about coordinating this triplet is the kind of expertise that is more recounted experience than it is privileged knowledge. What it describes is predictable "common sense" from the point of view that effective business action results from careful process designs being operationalized by the right people using technology appropriately. This is a familiar line of sight.

But in an alternative and somewhat more formalized view, people, processes and technology are each considered "business assets" that need to be managed. Company departments want to "own" stuff. Their logic for dividing responsibilities and authorities into sub-units of the organization presses forward a requirement to control the internal distribution of enabling assets -- even moreso than effective business action calls for the integration of the assets. Ironically, this "control" creates inconsistencies and silos that frustrate enterprise visibility of resources. Additionally, it leads to duplication of efforts to integrate them as described above.

Although those "component" integrations and "asset" allocations each have a loose end of their own, they are often believed to be resolved with each other in settling the question: "how do we get 'finance' to support 'engineering' ?" This kind of reconciliation produces some number of agreements indicating what to worry about no further or what need not be fought over. A balance of political and economical concerns might be struck. But that doesn't instruct on how to align our famous triplets for successfully driving business value...

Mixing Apples and Oranges

Thus, despite the easy rhythm of the mantra, its suggested coordination can't be taken for granted.

Here's a third problem: processes are complex constructions created by the business, that institutionalize certain behavioral characteristics of the business.Unlike people and technology, processes do not simply arrive autonomously intact into the business action scenario. So, to "align" them with people and technology, how do we proceed? What transformations are necessary in order to blend them together?

These days, thanks to ASPs and "built-in best practices", we're tempted to think and even say that most processes actually are selected off the rack and then tailored to the business. In that way, it appears that processes are in an asset class that also includes already-skilled people and pre-formulated technology. The idea is that the business doesn't design people or technology, and increasingly it really doesn't design the process either -- rather, it chooses, customizes and "implements" all three of them.

But to hold that position, it's necessary to be fairly explicit about what is covered by each term. For example, is "technology" supposed to include homegrown applications, printers from HP and hammers from Sears? With that breadth, talking about coordinating technology with processes and people doesn't advance any particular idea very much in the direction of better management. Instead, it just reiterates the common-sense awareness of a need -- namely, to somehow organize their interaction in an accountable way.

Ordinarily, the advice regarding blending these items does specify what form of each one is in question, and go on from there to promote a coordination methodology. The point is that we have to decide what each term of the holy trinity really is or really means, before we can know what to do about it.

We know that each term attempts to identify an essential building block of a capacity to operate (on business requirements). Each term of the triplet is at least a placeholder for some fundamental item.

What if we logically "normalize" the people/process/technology triplets, so that the scope of each placeholder is inherently comparable to that of each other's? Wouldn't that generally help clarify what kinds of management will be called on to guide and sustain their coordination? Let's try.

Processes are actually complex constructions of choreographed events. In effect, processes are a description of how to use events based mainly on where and when they should occur.

Likewise, the choreography of people describes how their positions relative to each other are "prefigured" to support certain interactions. Assignments create this arrangement.

Choreographing technology means deploying it in a way that its on-demand availability gives real-time support for functions. Configuration prescribes this situation.

Coordinating levels of management

Those observations give a new version of the triplet to use: People/Events/Technology is the new component-level triplet. Once we start this, we can follow suit as in the chart below, which summarizes the overall business view of the architecture for operational business value:

Copyright 2004 M. Ryder

Assignments/Processes/Configurations become infrastructure-level identifiers related to the more "atomic" elements of people/events/technology.

A key outcome of that "normalization" is that it clarifies the management coordination steps up to the necessary levels of value, such as a third level -- a production level -- where Relationships, Operations and Resources live. This is the level on which the business starts defining the conditions that strategically support the type of opportunities it deems "valuable" (or literally, value enabling). But stepping up to this level is not just a simple matter of promoting "assignments" as relationships, "processes" as operations, or "configurations" as resources.

Instead, relationships, operations and resources are each perspectives, with each given perspective addressing all three of the elements on the level below. Relationships present requirements to the coordination of assignments, processes and configurations. Likewise, Operations present requirements, and Resources yet another set of requirements.

The requirements are generated from objectives that have been established for each of the perspectives. The objectives represent the business's idea of how it can develop and sustain advantaged positions for growing and changing -- or in other words to benefit from competing, from producing, and from consuming or exchanging assets. This points to one even higher level of consideration.

At the fourth and higher level of concern, we find the business defining itself as an entity, through identifying Accounts, Services and Portfolios -- managing them separately and in relation to each other, for bridging market-level demand and supply.

Here again, each higher level item is a perspective on all of the items in the level below. Accounts establishes an agenda for relationships, for operations, and for resources. Likewise, the Services and Portfolios perspectives establish their respective agendas for each item in the level below.

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

May 2, 2005

Driving Strategy to Success

Executives and business experts are generally agreeing that improvement in profitable competitiveness must now come from taking measures beyond cost-cutting. Profitable competitiveness is their basic idea of good performance. It reinforces the idea that the business should organize how it competes according to the chance of profit; so, changes in the perceived sources of profit should change the competitive strategy.

What should stay under very close examination, naturally, is the idea of these "profit sources". In one view, the strategy should actually create and/or secure the sources; this is a fundamental part of understanding the quality of the strategy. Another part concerns how usable the strategy is by the organization, for the purpose of creating and securing profit sources.

Accordingly, as the conventional idea of performance management goes increasingly mainstream, what we see talked about is that companies are increasingly concerned with the ability to "execute" the strategy. Naming the problem in that way intuitively makes sense, given the outlook described above. But to solve the problem, it first needs to be defined in a different way.

To begin the redefinition, let's dump the word "execute" and use the word "drive". To illustrate why this makes sense, let's imagine that we're competing in a autorace on a difficult closed-loop track. One of the key things we need for success is a car that "handles" well enough for us to actually make each section of the track "conform" to what we need to get out of it. For example, a steeply banked curve is an area where a poor-handling car will fail to keep us positioned the way we need to be throughout the curve, and we may fly off the curve against the crashwall or at least lose crucial time recovering from poor position in the curve. But in an excellent example of relativity, a great-handling car is said to "flatten" the curve because it can hold us in the optimal position throughout the entire curve, for least risk and highest speed (combined). The great thing to see about this is that although the actual physical curve of the track does not change shape in either case, the effective shape of the curve does change along with how we can handle it. Our great-handling car re-shapes the curve to our needs.

Strategy is like that great-handling car. With it, we can reshape the entire "track" into an optimum competitive environment. But that assumes our own compatibility with the car, which in turn assumes that we are ourselves capable of operating the car appropriately.

If performance is a measure of profitable competitiveness, and we rely on strategy to establish that performance, then the strategy's reliance on our operational compatibility and capability is clearly 50% of the "source" of the competitiveness. The strategy is designed to reshape the environment (so there's the other 50%), but that effect won't occur if we, the driver, do not or cannot use the strategy in accordance with its design.

So, let's use that conventional working definition of "performance", in which managing performance improvement means increasing profitable competitiveness. That means doing something that might best be called co-opting the strategy. Literally, to co-opt means "to take or assume for one's own use; to appropriate..."

This idea includes a couple of great things that are useful to us. For one, it immediately suggests that a good strategy can be built, bought or borrowed; naturally it can be home grown but it doesn't have to be.

The other thing is even more interesting: think of "co-opt" as relating to the strategy through a combination of "co-operating" with it and "adopting" it. To co-opt a strategy, you cooperate with its intent and you adopt the strategy's attitude towards the environment that it wants to reshape.

Now we see the issue of strategy in light of a more tangible performance management agenda. When the organization's behavior shows that the organization wants to do what the strategy wants to do, the organization is driving the strategy, and the profitable competitiveness premised (if not promised) by the strategy is more likely to be demonstrated.

For managers, seeing that the organization drives the strategy is probably a much more important perspective on things than is the evangelical idea that "strategy drives the organization."

In co-opting the strategy, cooperation with the strategy's intent must be a desire of the organization, and this is likely cultivated through incentives or there will be much less persistence to it. However, adopting the strategy's attitude towards the business's operating environment is even more essential, since this attitude is what reshapes the environment to the business's purpose. The reshaping is where strategy actually creates and secures the sources of profit. Without adoption, no strategy can take credit for any success. Thus, strategy adoption is something that must be at or near the top of a manager's agenda, and we must develop clarity on how the particular and various managers should actively and practically repond to that priority.

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

April 27, 2005

ITIL - avoiding ITIL implementation mythologies

A consensus exists that ITIL - the defacto standard reference for IT service management - is a library of descriptions of "best practices". But it is crucial to note that in those descriptions, there is content pertaining to several different issues, three of them for example being objectives, practices, and processes. Just saying "best practices" does not logically mean that all three issues are best, nor understood, nor self-fulfilling for an organization. Saying "best recommendations" is more likely to the point.

It's an understandable urge to acquire the best "solutions" that makes some organizations try to force-fit ITIL -- acquiring by forcing themselves to fit ITIL's apparent prescriptions of behavior. Unfortunately, that doesn't work unless everyone wants it to. Meanwhile, organizations can't just simply run an "ITIL.EXE" installation wizard.

This calls for revisiting the idea of "implementation" on a fundamental level. Strictly speaking, implementation means *applying* something (an implement!), as a practical function within an existing operation. Our corporate experience with most large "applications" is that they must be customized to the targeted operational environment before they can "go live" and survive to deliver ROI. But the whole trick to that is to first understand whether the application must be customized to the current environment or to a future environment, or somehow to both. The IT organization, as run by its managers, *is* the environment. The dynamics of that environment are all about people and the reasons why people will do things.

Therefore, the typical prerequisite elements of "implementation" are always "target, commit, adapt", respectively meaning (1) the goal to adopt the implement; (2) the commitment to the necessary level of operational performance; and (3) the ability to adapt to using the implement.

Put differently, the necessary trio of implementation success factors is strategy, maturity models, and change management. Without this trio there is no rational roadmap available to guide the evolution of the organization from its pre-ITIL orientation to its ITIL-orientation. To create this roadmap, organizations may or may not need outside help, but the point is for organizations to embrace the concept of ITIL-orientation as opposed to ITIL-installation.

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

April 25, 2005

The ROI of Management

The essential function of a business is to process resources to generate value in a targeted market. Generally, the profit results from exchanging the delivery of specific benefits of that processing for something else more valuable.

To sustain this ability over time, the business must be able to regenerate and refocus resources in accordance with the changing requirements of competitive demand in the market.

This means that the capability to execute is the result of an ongoing investment, and the capability itself is a return on that investment. Let's call this the capability return on investment, or CROI.

Because market demand forms competitively, the business must anticipate the conditions in which the exchange of benefits for reward is probable. Organizing around the probability is the concern of strategy.

For the purpose of instituting practice of this organizational effort, Strategy is formulated in Plans.

The business goal is then to have execution of the plans generate a profit return on the investment -- or PROI.

Shifting markets mean that PROI relies on CROI. But the likelihood that execution will drive profits rests on the likelihood that the underlying resource-processing will have the characteristics needed to establish -- on demand -- appropriate delivery of benefits for the current opportunity presented by the market.

This makes capacity and coordination the key characteristics of execution, while strategy directs the execution.
- Capacity provides immediate breathing and maneuvering room in the set of options for resource allocation and application. Growth is the increase in capacity that is effectively applied to opportunity.
- Coordination provides constructive throughput of the impacts of resource deployment, from the initial decision through runtime activity. Alignment is the increase in coordination that ensures operations meet requirements.

Those key characteristics of execution mean that PROI from execution mandates a use of resources that both results in and leverages growth and alignment.

In turn, the criticality of appropriate usage mandates direct management of utilization to comply with strategic direction. The degree of compliance realized is called "performance."

Thus, in order for CROI to drive PROI on a long-term basis, performance must support strategy by establishing compliance through growth and alignment.

This understanding is the basis of the Archestra Management Framework.

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

April 13, 2005

Strategy, Architecture, and Performance

A business is an organization that exists to convert resources into assets at a pace faster than the assets lose superior value to the resources.

Meanwhile, markets define the value of the asset. Move the asset to a different market, and its value gets regenerated from scratch by the new market, with a likely (but not necessarily) different result.

If that is true, then against that backdrop all businesses have the same deep questions about driving business performance.
- Market model: how do I get a position to capture the value that a market can generate?
- Business model: how do I optimize the resource-conversion potential, for delivering assets into that value-making mark