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.