June 22, 2010
Social Networking
Leadership effectiveness requires followership.
Following requires accepting an extrinsic agenda.
Acceptance requires accomodating the agenda within a disposition.
The disposition is a point of view from within a network of influences.
Change management must generate a disposition favorable to leadership.
It is said, "Individuals do not evolve; individuals change, and populations evolve."
Posted by Malcolm Ryder at 10:51 PM
June 19, 2010
Forecast: Partly Cloudy
This makes it obvious why tools like I.T. (information technology) are not just helping business, but instead are an integral part of the "body" of business, as much as are people. Said differently, I.T. management has reasonably been a critical concern of the management of the internal "corporation" of the business.
While "internal IT" has evolved dramatically through several generations of computing, the essential organization of people and "IT" has not really changed: IT is part of the environment in which work is done.
However, generating the environment has not always been done exclusively from internal resources. Outsourcing is old news. And increasing technological advances based on use of the internet make it even more likely that the business will find opportunities to have production environments generated and/or hosted externally. Currently, the trend is mostly for external organizations to research and develop new web-based production environments first. While those external environments may then be shared by other businesses, the know-how for building such environments is also growing in, or migrating to, internal IT operations. As such, these new types of environments, called "clouds" are appearing in both external (usually shared or "tenanted") and internal (usually private) variants, with privacy having a big lead in preference over sharing.
Companies that do not already have a "cloud" environment do already have an environment subject to a vast array of managerial concerns that address costs, engineering, and other factors that are decisive of the range, reach and utility of the environment's functionality in actual use. The different types of concerns also cut across the "levels" of structuring that compose the environment, which means that the overall management complex can be difficult to balance; when balance more or less exists, no one is especially excited to upset it -- and moving from that status quo to something different easily runs into a lot of resistance.
Yet in general, the reasons to make the move from a non-cloud environment to a cloud environment are business reasons: the two primary issues ultimately addressed by IT management of the work environment are economy of scope and economy of scale. If either one cannot be solved and sustained to the business's satisfaction, then there will be changes made of some kind. Economy of scope must be considered first, because it more closely relates to the reality of variety in the business's requirements. Normally, an internal non-cloud environment is tamed by managing the three key factors of its dynamics: demand, operation, and capacity. Management approaches focus strongly on the interrelationship of the three. Even the most general schema involves the following approach (as diagrammed)for packaging the Users' environmental leveraging as services:
Put simply, without capacity, demand cannot be met, and without operations, there is no way to meet demand with capacity. Assuming this challenge is adequately addressed, there is always the matter of whether any of those key factors will change, so everyone is concerned about changes getting the upper hand. That set of conditions precedes the actual achievement level of economies of scale. Without economy of scale, the structural components of the environment do not "add up" well in the business perspective.
Good design helps to bring resources that are capable of supporting adequate economy of scale, but the actual deployment and utilization of the resources is what finally drives, and surfaces as, "economy". If not attended in a mature way, the dynamics of economy are more difficult to manage than the attributes of systems that can run at large scale:
Posted by Malcolm Ryder at 1:05 PM
August 13, 2009
Why Business Processes drive Customization... and what to do about it
Customization of business processes means that there is more "precision" in the targeted effort to succeed. But in situations where support may not be up to speed and where targets may change, this precision comes at a high cost of achieving readiness and warding off eventual irrelevance, making it just as risky as it may be attractive.
The general sense of "customization" compares against three basic options for the formations of a business process.
Option 1: One-Size-Fits-All
For business processes, this is a myth, because “business” is primarily about accommodating multiple relationships and requirements, not primarily about manufacturing a standard product. The “process” must support what business “is about”. Relationships tend to be privileged, not indifferently available.
Option 2: Specialization
Sometimes incorrectly called “customization”, specialization is different: it means variations on a single theme. The theme has standard requirements; the fulfillment is where the variety occurs.
Option 3: Customization
Customization begins in the requirements, not in the fulfillment of them.
There are three reasons why requirements may be “custom”:
- Cost structures
- Competitive Innovation
- Capability Immaturity
Three reasons why requirements may be custom, not generic.
Cost Structures:
- Satisfying customers is not profitable if it is too expensive; different organizations (different suppliers, and different consumers) have different cashflows
Competitive Innovation:
- Existing customers, to decide to stick around, need to feel that the relationship is fresh and current
- Potential customers need a reason to prefer one provider over another
Capability Immaturity:
- The time available to use for improving capability may not be in synch (priority, availability) with other resources
Three reasons why requirements may be "custom", explained.
Cost Structures:
- Lack of visibility on true economic impacts puts operations on a risk-aversion basis seen in typical micro-management approches
Competitive Innovation:
- High rate of change is necessary to sustain improvisations that generate necessary nw effects or advantages
Capability Immaturity:
- Required performance level outstrips currently available supporting mechanisms, forcing risky workarounds.
How to mitigate or avoid customization.
Micro-management:
- An operational performance model allows activity to be prioritized and weighed by differential contribution to goals and thus by ROI perspective. (For example, the 80/20 rule.) Relieves pressure to dwell on the microscopic. Define objectives, CSFs and KPIs. Switch to “trust-and-verify” mode.
Improvisations:
- Linking process models to knowledge management allows standardized roles to be able to move quickly and differently on incoming information, without re-organizations.
Workarounds:
- Organizing around known best practices clarifies ways to structurally reduce risk and to more rationally divide the labor required to meet performance targets. Such greater clarity allows managers to make the compelling business case for additional help to cover properly allocated responsibilities.
When to Customize.
Considering the above notes, executives should still project the likely value of customizations. The punchline is that it cannot be taken for granted that customization is the best path to take, neither in the short run nor the long. Customization proposals that withstand comparison to the above considerations should be given even more enthusiasm than usual, as they probably then point at nearly unique opportunities to do something strategically important to the business.
Posted by Malcolm Ryder at 10:37 AM
March 8, 2009
Networking Social Behaviors
With the help of the McKinsey gang, important thinkers such as Soumitra Dutta and Matthew Fraser of INSEAD are hosting discussions about how the internet and the recession might collide. Their angle: "When Job Seekers Invade Facebook". In their conversation starter, Facebook is offered as a venue that has its own culture, now threatened with an alien influence that could change the nature of social networking.
This is a somewhat romantic notion, best held by facebook's marketing and legal teams but not a plausible or fact-based reality. The concern wouldn't be how social networks behave; rather, it would be how social behaviors are networked.
Interestingly, it brings up the question of how much a given tool can control its users, versus how much design can flex to assure that the tool is fit to its purpose. What's not clear is that there is any cultural "end state" of facebook that represents its purpose. Instead, both on the surface and in theory, facebook is one of multiple grand collaborative experiments to discover what social "connectivity" really includes, with social propriety being a necessary but secondary concern. This experimentation seems likely to show ongoing morphing in what we see being social networking, but it hardly seems likely that a horde of unemployed invaders at one site will change social networking into something it is not already.
The dominant feature of the most popular social networking tools is that they are gateways to fundamentally public environments where privacy policy controls get applied. But the trick is that the policy applications are done based on personal preferences, and the personal preferences reflect many different cultures. It is unlikely that any one culture actually governs a social network unless the network's environment is administered according to some dominant policy model that proxies a culture. The default condition is that public spaces (like facebook) are polycultural, and that the less polycultural the space is made, the more constitutionally private it becomes -- just like a club. Punchline: unless internet economics eliminate the chance for more new "price"-free gateways, it is not social networking that will change, but instead the variety of social network venues.
There is some counter-thought to this that insists on some "critical mass" of members for a social network to be seen as useful -- and therefore in some Darwinian way likely to survive. This presupposes that the "natural" limit on the number of networks is a small number, since most networks won't offer enough richness to be worth the troulble. But I think this oversimplifies things by assuming (arbitrarily) that the "richness" (value) of a member of the network must be measured by the interconnections within that network. Real life shows that assumption to be silly; incredibly valuable people join and use networks on a very limited basis all the time; and, some small networks can be incredibly powerful, like the smoke filled back rooms of old. We'll remember that these smaller ones tend to be more private.
Rather, some members who are not "rich" when they join public networks have the ambition that they can achieve some richness within the network. That is precisely the current sex appeal of the term "networking", as used for painting in broad strokes; well, fine, as long as we don't pretend that social networking is actually hostage to any network.
Posted by Malcolm Ryder at 9:07 AM
February 19, 2009
Innovation Revisited, Kinda
Wharton's project with the Nightly Business Report convened a panel to select the top 30 innovations of the last 30 years. A key problem for the panel was to have a working definition of "innovation". And the next key problem was to rate the importance of innovations against each other.
Listing signature characteristics of "importance", the panel came up with this:
-Impact quality of life
-fulfill a compelling need
-solve a problem
-exhibit a "wow" factor
-change the way business is conducted
-increase efficiency
-spark new innovations
-create a new industry
Like many lists, this is a collection of "notables" that leaves open the matter of which ones may overlap or compete with each other. That might not matter except that the list is one of competitive "qualifiers" or "criteria", so we need to know when to apply them, and when not. It doesn't make sense that all of them would apply to every issue thought of as an innovation, so it's fair to imagine that some kind of categorization is implicit in the list. To investigate that, let's reorganize the list a bit.
1a. Impact quality of life
1b. create a new industry
1c. change the way business is conducted
2a. fulfill a compelling need
2b. solve a problem
3a. spark new innovations
3b. exhibit a "wow" factor
4. increase efficiency
Group 1 clearly shows what we want innovation to affect. Life, industry and business are of course strongly interconnected because they co-exist in a shared environment, and they co-operate in the creation of that environment.
Group 2 clearly shows "how" we want the innovation to affect any of the members of Group 1.
Group 3 clearly, but somewhat abstractly, represents a sense of "why" -- of whether the innovation is compelling due to the "push" of its character (sparking) or the "pull" of its character. (And these would not necessarily exclude each other.)
And Group 4 is a throwaway. The mystical attracton of "efficiency" might be nicely appreciated as a need to avoid waste or resistance; but at best this is a type of micro-problem to be solved, and at best it should be a member of a list of various things dealt with by group member 2b. Additionally, the different members of Group 1 probably have some micro-problems in common, but (for example) surely the idea of inefficiency versus "quality of life" is not the same as inefficiency versus "new industry". So going ahead, we'll drop it (at least until the other worthy micro-problems, from various perspectives, are also identified).
What the new grouping offers is three dimensions of consideration -- the what, how, and why -- that ought to account for the competitive inclusion of each given innovation in the Top 30 list. 3-D space is of course a framework, and with a framework in hand it should also be possible to anticipate (predict), find (detect), and position other issues that would be candidates or actuals of "innovation"...
We don't know exactly how much the panel may have made decisions this way -- whether explicitly by agreed formula, or intuitively. But for the panel, there was also the prior matter of defining an "innovation" in the first place. Their definition was as follows: "It's something new that creates new opportunities for growth and development", which resulted in "a list dominated by technological and medical advancements".
Let's go back to that loose end of "inefficiency", though. With this panel, it seems either clear or feared that inefficiency is a major thorn in the side -- perhaps the single most aggravating barrier to innovation itself? This would be an indicator that innovation is perceived almost entirely in the context of an already known or targeted outcome, objective or goal. What else could the context be?
For one, conspicuously absent from the list is both (a.) specific unprecedented "concepts" and (b.) virtually all "fine art". In other words, nothing having to do with the evolution or revolution of consciousness made the top 30 list. Granted, the initial invitation to compile the list most likely did not try to attract a range of candidates that included those two. However, aside from entertainment value, what is the point or use of a Top 30 list? There will be those who study the list in order to try to understand where innovation comes from. And for that very reason, it is critical to survey as well the growth and development of the mind that we will eventually watch, hire, or follow because we expect innovation from it. It was Einstein, wasn't it, who said that "To raise new questions, new possibilities, to regard old problems from a new angle requires creative imagination and marks real advances in science... The significant problems we face cannot be solved at the same level of thinking we were at when we created them." The most important innovation(s) would be ones that allow, or even force, us to think in a different way than we did before.
And another take on context involves the ability to undertand growth and development not as checkpoints towards a known or certain end, but instead as evidence of new potential and/or capability despite being accompanied by uncertainty. Normally we reserve the term "innovation" for something that we can retrospectively view; but the difference here is that the desired certainty need not be about what comes "next" due to the innovation. Instead, it can be about "what became different" from a past known or shown to be obsolete. In this sense, a surprise encounter with something that already exists, but that is a clear alternative that might then be adopted, makes the adoption itself an innovation, and should be understood alongside our interest in inventions.
Posted by Malcolm Ryder at 8:53 AM
November 1, 2008
What Matters versus What Counts, Encore
Any time you're busy with analysis, construction or movement, you're working on "distinctions". Such efforts generally result in ideas like Part X not Part Y or more vs. less; newer vs. older; or near vs. far (and here vs. there) ... These general differences each go on to be both specified and named with much more precision, for particular situations.
These efforts aren't happening by accident. So we often take it for granted that we should really bother seriously with their outcomes. But this default attitude might be a mistake.
Now that John Bogle's new book Enough is published, one of the fundamental concepts underlying archestra's separated definitions of "value" versus "worth" will be in the spotlight on a multinational basis for a while.
Outside of the book, but to recap archestra notes, there are a number of ways to summarize the working idea involved, such as the three cases below. In all of them, there is the underlying base dynamic that some kind of effort, let's call it work, is producing some measured distinction -- more... better... enough, or whatever -- that didn't exist before the work was done.
But all of the cases point at the need for understanding that unless we know what matters, counting by that measure is always possible but risks being (at least) irrelevant or even (at most) irresponsible.
The Who Cares Case: In this instance, unless a distinction causes us to consider each element it creates in some way different from before, the distinction would not be "significant"... But if the distinction is significant then we say it has value. Still, the value that it has may be irrelevant to some parties, while crucial to other parties. So that same value has a different worth to one party versus the other. The problem, then, is in diligent pursuit of a worthless value.
The Hero Case: in this instance, the usual reference is the old saying "it's not whether you win or lose, it's how you play the game." On that note, first consider the ersatz "Government Employee's Credo" which says:
We the Willing,
Led by the Unknowing,
are doing the Impossible
for the Ungrateful.We have done so much,
for so long,
with so little,
that we are now Qualified
to do Anything
with Nothing.
The issue being described, by the largely "invisible" public service workforce, is really the issue of character, which is often described as "the quality you choose to exemplify when nobody is watching". This is pointing at the decision to pursue the correct value, especially in the face of substantial opportunity (or worse, pressure such as from politics, greed or fear) to avoid responsibility for pursuing it.
The Do the Right Work versus Do the Work Right Case: In this case, the issue comes up in so-called "performance" measures, where confusion between compliance and progress is rife. The classic examples today are problems such as "learning to test well" versus "acquiring actionable knowledge"; the pre-crash share price of Enron; and of course the ever popular joining up with the legions of "the unhappy rich". Scorekeeping is seemingly inevitable, but there's nothing better than keeping the wrong kind of score to put new clothes on the emperor.
In short, value is what counts, but worth is what matters. Sadly, so much of what appears to be valuable can easily turn out to be worthless.
Posted by Malcolm Ryder at 9:33 AM
August 16, 2008
Why Leading Thinkers Won't Be Thought Leaders
In the ideas game, cutting edge thinkers are typically too far ahead of the approval criteria for implementers, and since "thought leaders" derive their credibility from the probability of implementations occurring, most leading thinkers don't become thought leaders.
To get probability on their side, leading thinkers usually have to choose to think about something that approvers already want to implement.
This certainly distresses the notion of "innovation", except within the sense of "infusing the accepted with newness". But that is not an outright knock on anything; it simply points to a reason for having the notion of "pragmatic innovation".
Much leading thought throughout history has been pretty rapidly dismissed as "impractical", which of course should have meant "unable to be put into practice"... But with 20/20 hindsight we are able to know at least that what is undoable for one outfit is merely inconvenient for another. And yet another may have no resistance to the idea at all and let it rip, wherefore the popular "disruptiveness" tag in the vocabulary of the betting pundits who track ersatz innovators.
Thought leadership is safe. It doesn't carry along with it the stockades, burnings-at-the-stake, smear campaigns, or other proven techniques used to enlighten leading thinkers about their impracticality. In fact, when you get right down to it, thought leaders are "voted into office", more or less like successful consultants, which means that they are the product of followers, not vice versa. This explains why the best-known thought leaders hardly ever have a hardluck story about finding followers...
In the other camp, leading thinkers sprout of their own accord and may carry on for quite some time with no followers at all. Some leading thinkers get lucky: they wind up being befriended either by a thought leader or by an influential producer who can spell "pragmatic" but isn't worried about it for the time being. But conventionally, the bridge between leading thinkers and thought leaders is the kind of engineering called "R&D".
The problem is that if R&D is not funded well enough, then the bridge may not reach all the way across. So the issue mainly comes down to who will sponsor the way that the R&D is adequately funded.
Leading thinkers really are often into fundraising, but a lot of fundraisers aren't any good at it. In a healthy organization that wants to be progressive as well, the case for funding thought leaders is not so hard to make, but the exceptional organization strategizes funding of its leading thinkers.
Posted by Malcolm Ryder at 9:28 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
July 5, 2008
Beyond the Spin: Measure What You Give
Does your organization really measure what you give, or does it mainly spin what you measure?
Bruce MacEwen's industry-leading website Adam Smith, Esquire offers an opportunity to gaze into the abyss of metrics and walk away without jumping. In the article
"How High Quality Are Your Lawyers? (How Can You Tell?)"
a close reading shows contrasting business models contesting notions of "performance @ cost" and "value @ quality". In the competitive situation covered, one upstart model strategically goes after a chunk of the opponent's business by bringing customers the performance/cost equation, surprisingly leaving the traditionalist competitor to justify how pricing for that same chunk of business could rationally be based on value/quality. What makes this all interesting, notes MacEwen, is the idea that 99% of what the traditionalist does is what the upstart can steal away.
For those of us who fell out of the old hot habit of saying "disruptive innovation" once a month, this looks like news, but not new news. Still, there are some fresh perspectives worth bringing to this contest.
As seen in the diagram below, the different models above are easily distinguished by what they actually offer, making it inappropriate (for managers) and intellectually dishonest (to customers) for either of them to masquerade as the other. Customers buying into cost/performance are investing in the promise of efficiency, while those buying into value/quality are investing in the promise of reliability.
In MacEwen's article, we are sensitized to the problem that high-prestige value/quality law service firms institutionalize a significant unmanaged cost in the form of "available overachievers", against which these firms then build a hedge by charging premium prices beyond rational evidence of economy for the customer. But what is sold as the justification for this pricing? Their quality?
To be sure of avoiding management posturing, "quality" here must mean only one thing: adherence to the promised appropriateness of the deliverable versus the stated need. Consider that meaning against the question of what it takes to get quality: the value/quality firm proposes that by exceptional capability they eliminate the risk of not getting quality. Therefore, the key variable that this firm actually addresses is unpredictability in the customer's need. As an operational tactic, the value/quality firm hoards talent in order to avoid outsourcing and to presume agility.
But the cost/performance firm basically argues (by demonstration) that legal work requires only competency to sufficiently meet most stated needs -- not a matter of being exceptional but instead simply correct for the task, which eliminates unnecessary effort from the equation right off the bat. Of course this presumes a degree of predictability in scope of need -- and agreement on the scope becomes the main feature.
The discussion above intends no effort to offer a wisened critique of law firm strategy. That said, on the surface there are no truly important differences between marketing professional services in law versus other disciplines where subject matter expertise is the raw material and advice is the product.
Idiosyncracies in the legal services industry will of course provoke distinctive problems and solutions there, yet these are probably driven more by the state of mind of the customer - which is the underlying important difference because it is the competitive arena. Oversimplifying MacEwen's article, the difference between the value/quality firm and the cost/performance firm is that the former sells confidence while the latter sells credibility.
Are there spats? One accusing the other of con games, and the other accusing the first of being incredible? MacEwen's article says yes; but what is further interesting (per evidence of the illustration above) is the opportunity that both types of firms can objectively profile themselves on common ground (efficiency, capability, reliability and acceptability) -- and use those profiles to determine how to optimally segment and grow a shared market. When they don't do that, you can bet it isn't because the customers don't care.
Posted by Malcolm Ryder at 9:59 AM
June 18, 2008
When is "value" not valuable?
A wonderful discussion on Bruce MacEwen's website Adam Smith, Esquire included this challenging note from Paul Lippe about what logic is available to explain the connection between quality and value. While he questions "reputation" as an indication of warm fuzzies like "quality", he also kicks off his note citing the less fuzzy implication that better performance presumes to justify higher price:
"I'd be curious if anyone can come forth with any data to show that in fact (as opposed to in repute) more expensive law firms produce better results, e.g. can it be shown that the investment banks who had the largest losses on their mortgage portfolios were served by lower reputation law firms?Once this conversation settles down, I will start a separate string (and perhaps a wiki to really pull something together) on what I consider to be the core issue: how can we develop a definition of VALUE in legal services that is meaningful and useful, and not simply measuring inputs like hours spent, diligence of lawyers, law school attended or reputation of the firm. With such a definition of value, I think we could expect that some lawyers' reputations and income would go up, but some would not."
Let's dig into that overall observation by making the undercurrents obvious.
- "Value" is a label for the significant distinctions attributed to something. "Value" in professional services is 3-dimensional, at minimum. A certain method of co-operation with the customer interacts with a certain type of target outcome at a certain level of effective cost to the customer. The method, outcome, and customer cost are variables, each having a range of acceptability, which in turn allows some universe of acceptable overall impact to sprout from their combination. Now, from that dynamic, some professional service providers are great at being predictably consistent within a smaller universe (range of impacts) that the customer prefers. Some are great at being agile enough to cover a larger universe, keeping up with a customer who has more volatile preferences. And there are several other "flavors" of competency that a service provider may have. Ultimately the provider wants to be paid for the competency, and then be paid even more for a competitively greater level of competency. But the customer wants to pay for customer satisfaction, which is something different. And what mediates the balance of the two things is often just culture. I wouldn't choose to drive a perfectly good Tercel to the White House Christmas Ball, but I could; and I wouldn't choose to drive a Bentley to the 7-Eleven, but I could. In fact, I could use either car to get to either destination.
- That's all well and good in theory, but in practice the realization of the potential value is hugely affected by the ability of the customer to appropriately and effectively align to it. (There is even plenty of historical evidence that customers sometimes buy based on how they wanna be seen, not based on how they really are.) That reality is the "forest". Relentless pursuit of profit is the bulldozer that strips the forest. Atomic metrical inputs like law schools and hours spent risk merely being "trees", where excessive attention obscures the view of the forest and therefore obscures the proper understanding of the value. Profit and arbitrary metrics actually must not dominate an analysis of value. Instead, value, properly identified, can be correlated with profits and other interesting measures, and the correlations may be revealing or even exciting.
- The final point from the above is that it is probably important to use rigor in discussing value, because "value" is not a reliable synonym for other things that deserve their own names, such as "competency" and "satisfaction", and "culture". It's important to know what is actually being taken into consideration and not gloss over things for convenience, because otherwise we find out too late that we're actually sitting on some key coordinate that does not allow us to "get there from here" (i.e., to the necessary value) on time. Meanwhile -- if we would like to elevate the discussion of value from the 3-D space of CustomerCost /Outcome/Method to the 3-D space of Competency/CustomerSat/Culture, while remembering to map the current coordinates in both spaces, well that's fine.
Posted by Malcolm Ryder at 12:17 PM
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 efficiencyProduction : 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
I'ma Get Open Source on Yo' Ass
Yahoo joins Google and builds a nonprofit to run OpenSocial so that the OpenSocial developers can have a freezone for exchanging "intellectual property assets" without a moola market. As the Associated Press stated on the Yahoo website, "the idea behind the Google-initiated OpenSocial platform is to create a common coding standard for the ['social tools'] applications so they work on hundreds of Web sites."
We decided to look up the meaning of "tools" to be confident of the richness in the breaking story. Using Yahoo's search engine, we kept coming up with entries like this exemplary one from Dictionary.com:
tool - noun: a person manipulated by another for the latter's own ends
No avoiding the thought that Yahoo would now be Google's tool; so we used Google's "Web Definition" search functon to see what happened. The search on "define tool" ripped in under two seconds to the most appropriate place we can think of, the socially open Urban Dictionary:
1. tool 4455 votes up, 517 votes down
One who lacks the mental capacity to know he is being used. A fool. A cretin. Characterized by low intelligence and/or self-steem.
3. tool 1708 votes up, 443 votes down
someone who is a complete idiot/ one who is used by other people, and usually dosen't even realize it/ someone who can't think for themselves/ an asshat.
People who wear huge logos on their shirts are tools.
This would be a good moment to mention that Google has given up its rights to the OpenSocial branding, as part of the deal. No fools in Gtown central.
Clearly you can be a tool without being a social tool; so how wack it is that three of the most powerful companies in the free world are aggregating the tools. This might make them social, but a better question is this: does going social on a social network make you a tool if you weren't one already?
The sports pages of the conventional business press can be expected to focus on that, backhandedly, in their ongoing coverage of the market strategy smackdown between the G force and MondoSoft. But of course, that's hardly the key story.
The key story will be the one that inevitably will break on the non-profit NPR when someone looking for a job at Google tries to sue Google for using their social site residue as an excuse to not hire them -- residue found on hundreds of websites thanks to the easy proliferation path of OpenSocial.
"So, Mr. Lovitz; how do you explain your involvement in this August 2007... occasion... at the Omega Hip VIP room?"
"Uhh... Acting!"
Posted by Malcolm Ryder at 6:42 PM
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:
- Effectiveness is usually a measure of the degree to which an actual outcome matches a desired outcome.
- But the outcome is a strength of reaction to an impact generated by some agent.
- 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).
- The cause of the observed level of impact is a state or an output.
- The agent of that state or output is a quality level of process.
- The runrate of the process consumes inputs.
- 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
November 8, 2007
Knowledge Workers : the wisdom of the Crowd?
No great company can expect to compete without a great stockpile of knowledge and, therefore, knowledge workers. Question: the more k-workers, the merrier, right? Answer: it depends.
The concept of the "knowledge-driven organization" is the strategic rallying flag for businesses bred amongst the Information Society. But that enthusiasm doesn't automatically translate from ambition to reality. Faced with the pressure of quarterly earnings reports, many companies can't decide whether the daunting task of becoming knowledge-driven is a "do" or a "die".
Yet most career hierarchies in an organization -- a.k.a., "success" ladders -- are marketed with the idea of "demonstrated expertise." This ought to mean that careers are the channel by which organizations actually apply the knowledge in residence. In turn, that ought to mean that organizations are already inherently knowledge-driven. If that's the case, today's idea of knowledge management being something new must indicate something that has heretofore been missing. So where's the gap, and why?
The reality is, careers are fundamentally about influence, not knowledge; and most careers are promoted on the basis of power; and typically the power is manifest in "productivity", not "skill", and productivity is measured in outputs, not inputs. Just as athleticism gets you on the team but not necessarily off the bench, for most players the primary key is to fit into a prescribed position -- which translates into measurable productivity good or bad. And as the authors of Mass Career Customization (Harvard Business School Press) describe it, the positions that typically matter in an organization's career tracks are management. Net: when it comes to career success in the organization, the way management itself is prescribed or defined will generally trump knowledge. This puts knowledge workers in the position of needing a strategy to make management repeatedly buy into their knowledge.
Cathleen Benko and Anne Weisberg, two executives of Deloitte, hit the issue from two directions in their book. One direction looks right at productivity through the lens of performance results associated with female executives. The distinctively superior results that the authors find there inspire the question of which female qualities are so naturally more productive. The implication is that innate qualities of women produce higher performance in the corporate ladder. But what evidence of these qualities makes the qualities explicit? Why would these same qualities generally drive corporate success, and can men practice them too?
At this point it's worth pointing out that most careers, really, are built on making one's decisions agreeable, not on intellectual athleticism -- but then again only smart women seem to have big corporate careers. The classic dilemma of these smart women has been, how smart is it to have a life outside of the company if we want a strong career inside the company?
Benko and Weisberg's discussion gives some answers to that, but it still leaves us (intentionally) with the idea that even for those workers with these better female qualities (one notable mention is about "multitasking" as a woman's talent) a corporate ladder is hostile territory, whereas a new and trademarked model -- a lattice -- will promote and keep more women (and likewise men) in a profile that drives business performance. Mass Career Customization (MCC) offers a way to make the important "career" qualities explicit and "tunable" like the different ranges of a graphical sound equalizer. The trick is to get the company to accept these tunings, or profiles, and the book is largely an explanation of how and why the company should.
The issue of knowledgeworkers intersecting organizational structure is the very singular topic of the Benko-Weisberg book. The issue amounts to more than one thing, but the most consistent thing it amounts to is a view of organizational structure managing knowledge workers as assets. One major reference used by the authors is (click here if you want it) the Deloitte Enterprise Value Matrix, and the book's major offering -- MCC and an alternative to the corporate ladder -- is given an ROI argument by being presented through a Deloitte-style framework.
A dispassionate reading of the Deloitte matrix reveals it to be an internal pipelining of assets from resource cost to strategic investment. But there is a story broader than the corporate boundary, which is the connection between the information society and the knowledge-driven organization, and the ecosystem that it generates around and through the company.
In this story, one plot-line is the following path of assumptions, which amounts to traversing the bottom, middle and top rungs of the ordinary hierarchical corporate model for workers' value:
But while the MCC framework promoted in the book finds an alternative to that pattern for the employee, there's an even bigger message for the company itself to draw from the book. As knowledgeworkers, we like to feel that we're selling our intrinsic value to the company, but companies have their own reasons for buying or not.
The bigger value framework posed by the book Mass Career Customization has terms of measurement different from productivity and from the Deloitte matrix, where the employee must determine how much value the employee can have to the company. Instead, as seen below, the key terms are about how the company can have value in the new ecosystem generated by the Supply of Employees, the Demand for Employees, and how they relate to the Information Society supplying them versus the Knowledge-driven Organization using them.
Posted by Malcolm Ryder at 9:14 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
April 28, 2007
Knowledge as Capital
The McKinsey gang examined corporate performance on two fundamental indicators of sustained competitive advantage—revenue growth and profitability—over an 11-year period from 1994 to 2004. Their finding:
"...we found that ...nine companies had higher market-to-book ratios than their competitors did. (The M/B ratio is a measure of corporate performance that compares a company’s market cap with its book value.)...the top nine performers strongly preferred organic growth: they made few acquisitions and divestitures when compared with other companies in their industries...
In our view, their ability to generate value from knowledge-intensive intangibles (such as copyrights, trade secrets, or strong brands) represents a good starting point for further exploration of their superior performance."
Just connecting the dots.
To connect them yourself, log in at The Elusive Goal of Corporate Outperformance -- McKinsey Quarterly 28 April 2007
Posted by Malcolm Ryder at 6:28 AM | Comments (0) | TrackBack
March 24, 2007
Big Brass versus Crystal
Some balls are easier to juggle than others. But is that stance any way to run a company?
Something we certainly think we'll have to read is Michael Raynor's book The Strategy Paradox. Why? Because, as Deloitte puts it in their website's introduction to the book, "Management orthodoxy demands that strategies be built on commitments, which leaves no alternative to basing today’s decisions on assumptions about an unknowable future." This observation quickly drives down to the more important point they cite from Raynor: "The board should not evaluate the chief executive officer (CEO) based on the company’s performance but instead on the firm’s strategic risk profile..."
Since a review of the book is not where these paragraphs are going (yet), please visit Deloitte or even Raynor himself. What the heck: skip all that and read the book.
Before I read it, I'll turn my cards face up: if Raynor's book winds up telling me something other than that enterprise architecture, theory of constraints, and real options analysis is what's needed (and we assume it should), then I'll probably talk about it again. Maybe here, like, you know, in the next paragraph that could follow this one. Why not. While we're at it, let's go dust off our books about Royal Dutch Shell, do 'em again, and come back in a while.
For those of you with not that much time on your hands, a suitable companion piece is still available from Strategy+Business thanks to our buddies at Booz Allen, whose website offered this bit last year (as announced through emails to the faithful). I'm going to assume that advertising this for them will leave me in friendly territory vis-a-vis their copyright on what they sent, shown here for your convenience:
Sharpening Your Business Acumen
by Ram Charan
Dallas, March 30, 2006 -- The ability to see the big picture, anticipate external trends, and adapt accordingly requires plenty of practice, but can create unique moneymaking opportunities. It requires executives to transcend old rules of thumb and take strategic risks that don't follow precedent; to envision the effects of change before change happens. Here's a six-step thinking process to help anticipate external influences in the marketplace and craft smart strategies accordingly.To read the full article:
http://www.strategy-business.com/enewsarticle/enews033006
Posted by Malcolm Ryder at 4:34 PM | 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
February 1, 2007
I.T. Without ITIL
The most exotic thing about information technology has always been terminology. It is the key to the scientific success of the field. But quite naturally, the complexity of the science also has meant that the terminology works steadily against any increase of ease in the field's practical management. More and more cats pop up that need to be herded. The net result -- a nightmare of semantics -- caused what the Gartner industry analysts noted over five years ago: the overwhelming majority of cost in I.T. comes from not technology complexity, but management complexity.
Perhaps that's why it is that in these last three years or so, the I.T. Infrastructure Library, or ITIL as it is commonly now known, gained traction with the kind of momentum carrying an industry standard. ITIL describes a huge range of management processes using a vocabulary of enormous logical consistency, which can make the semantics of management suddenly unambiguous despite IT's complexity.
At the same time, the sheer scope of ITIL is fear-inducing. Many of those who would use it fall into one of two groups: those who look for evidence that there is actual practical import to sticking the toe in the bathwater; or, those who religiously convert. Analysts like Forrester Research say that the former group is about 60% of the gang, while about 10% are fully pious and immersed, leaving the rest either just thinking it over or dabbling.
On the spectrum between the larger and smaller group, the larger keeps its practitioners cordoned off (but not quarantined) in a swim lane... handling the semantics of ITIL as another special expertise hoped to achieve some natural ascendency, the same way an innovation outstrips or obsoletes legacies. The smaller "immersion" group swims the rough open waters of large-scale revolutionary change in culture. Because ITIL is primarily documentation, there is not a real threat that either approach will alter it's ability to provide consistent guidance. But giving good advice is not the same as causing it to be followed. The top obstacle to following ITIL, ironically, is still confusion. Why is this the case? Simply put, corporate IT groups are forced to move at a pace that is much faster than their ability to absorb ITIL, and they are loathe to risk, much less give up, hard-won benefits from pre-ITIL practices. Yet behind those benefits, they often don't have an effective overview of where they already are. Thus, following along ITIL's paths, they constantly run into forks in the road that don't offer the obvious correct choice. Net: ITIL is a maze.To get over this hump, they still need a way to see, in short order, how they can connect the dots between their current practices and ITIL's.
Following suit, the perspective represented in the picture below simplifies the identification of the pre-ITIL circumstances, locating the starting line for a move to ITIL without the threats of disruption or of time running out.
The key assumptions in this picture are as follows.
First, no one really cares about I.T. except for whether it is perceived and proved to be useful.
Second, there are only two major points of view on that utility: the lifecycle of items composing the IT infrastructure; and, the production that composes IT operations.
Third, all of the IT management, whether in infrastructure or in operations, is essentially about two things: how things are (i.e., states), and how things happen (i.e., transactions).
Those three assumptions, when aligned as shown, organize every critical aspect of driving value from IT utilization. From this point, the rest is a matter of additional levels of detail.
Since management is popularly understood to be impossible without measurement, and since measurement can't happen without semantics, it is hugely important that the perspective drawn so far does not rely on confusing semantics and meanwhile shows analysis as an ordinary, not exotic, activity covering the field.
Within the general framework, four main phenomena surface as the major management subjects. Driving these down into daily practices makes sense under the assumption that the point of the practices is to establish value in the utilization of the info technology involved.
The utilization is established on two fronts. One is to give form to the actual information technology that users can ultimately access and exploit; this is what is called "IT Services". The other is to give form to the mechanism that creates and sustains that access and exploitation; this is what is called "Support Services".
In an unconventional but easily proved distinction, IT Services is about the provision of the IT configurations; whereas, Support Services is about linking the IT to usage requirements, as systems for use. (These systems are essentially and primarily logical, and secondarily take on physical form as the peculiarities of the company hosting them might allow them to at any time.) Usually, in effect, it's the difference between supply and demand, between service level management and service level agreement, and so forth.
As seen in the picture, the two kinds of services cover (i.e., attend to) the four major subjects in a certain way.The types of services relate to each other because they work on the same subjects. But the services differ from each other in what it is about the subjects that are the key points of their respective concern and influence. These key points are added into the framework's quadrants to clarify the high-level of analytic detail that really matters for the services. This level of detail is the one that initially accounts for the co-existence and co-influence of the two generic types of services (IT and Support).
For followers of ITIL: the difference between IT Service and Support Service is not indicated in the normal ITIL vocabulary. Instead, the generic concept of "management processes" proxies Support services that bring IT services to the user or customer. ITIL largely provides a taxonomy of those management processes, and most observers first engage the taxonomy of "delivering" IT Services (defining and developing them) versus "supporting" IT Services (maintaining and optimizing them). But at least half of the trick in adopting ITIL is to orchestrate its management processes into standing "Support Services" as described in this discussion's framework, which is oriented towards managing the value of utilization.
Posted by Malcolm Ryder at 4:50 AM | Comments (0)
January 21, 2007
ROI and The Rush Job
or, The Productivity of Production
Years ago, the only way to get custom-printed photos on a rush basis was either with a LOT of money -- or NOT a lot, through a pretty darn good photographer friend, emphasis on the friend. Smelling an opportunity, and not pld enough to eschew self-abuse, I broke into a really crowded field of commercial photographers by offering the unthinkable: "fast, cheap, or pretty: pick any three." For six months, I didn't charge premium or "rush" prices: I just didn't sleep, and I custom-printed photos for delivery by rush deadlines.
Don't try this trick at home! It jump-started my business, but the six months cost me a couple of years of longevity that Science says I won't get back. A negative ROI. In general, production organizations know this could happen to them, too, and they sanely stick to the rules: "fast, cheap or pretty; pick any TWO."
The problem is that customers sometimes don't care about the rules, especially if the customers hold the production organization captive. A typical example of this is an IT organization in a corporate setting. Although it seems irrational, IT routinely has to solve the dilemma of offering all three outcomes.
Susan Conway, in her article Keeping the Think Factory Humming in Optimize Magazine's January issue, actually offers a fairly straightforward idea -- that getting cheaper (through tools) allows more effort to getting faster (reducing cycle time) and thus becoming prettier (through enabling continuous improvement of quality). Running in that direction, from tools up to quality, there is an increasing "enablement" applied layer after layer to the circumstances that must generate value from production.
Although she calls that value "efficiency", it is both more than and different from that; and the deceptive linearity of her run-up doesn't point at how those layers, or links in the chain, actually get connected: namely, simultaneously, not sequentially. It's not the "links" themselves that make the difference, it's the connections between them that do -- the linkage.
For clarifying why this is true, an important reference to have is Goldratt's Theory of Constraints -- in which the notion of a weak link is explored as an effect, not as a cause. We make the link weak by what we do around it; it is not inherently so. Likewise, we make the link stronger. This prevents us from taking the "linking" effort for granted. More to my point, it calls out the simultaneity that must be addressed: all the links matter at the same time...
Let's take that idea to heart. As a producer, how do you do Fast, Cheap and Pretty all at once?
We might make a new Pontiac Solstice, which shows that it can be done. But the usual situation is that each target characteristic can influence the production differently and even dominantly versus the others; so it matters that we know what their co-existence really demands.
Typically, we feel that we already know what each individual characteristic is about, but how about their combinations?
For example, what's an exemplary instance of Fast plus Pretty? How about Muhammed Ali's left jab. Effectiveness, wrought from precision, which was wrought from discipline, which was wrought from training. It's the precision that is its key distinction -- the organizing principle that creates the linkage, and its value, between Fast and Pretty.
And away we go:
Fast + Pretty? the left jab. Precision is the secret. Relies on discipline (from the training).
Pretty + Cheap? the sari. Elegance is the result. Exploits pattern (from the technique for folding or wrapping).
Cheap + Fast? the omelette. Balanced to the occasion. Leverages the facility (of a standing "factory" -- the hot skillet).
In other words, if we knew we needed both fast and pretty, "precision" is a good aspect to pursue, and to get there, we're going to need the discipline of having been trained into consistency. And whether wrapping a sari, or doing math equations or calligraphy, the elegance of "less is more" relies on drawing the optimal pattern through technique. What about that omelette? Balanced, neither too much nor not enough for the appetite, you grow it quickly from very little, on the already hot pan. While that pan is hot, you just keep crankin' 'em out.
But back to bigger work, what is production up against? The point is to get one deliverable from combining all three characteristics. Like that incredible car from Pontiac. The prerequisite is you'll have to be organized to pull it off.
This illustration calls out the three key constraints in managing the connections of the production -- design, controls, and sources. They are fit and related amongst the initial objectives to be met.
For example, when we talk about "sourcing", we're concerned with the scale of production that we need from the process, and how much that is going to cost. We'll source production from a factory that gives us the desired economy of scale from its process.
The model also looks more directly at what we think each initial characteristic feature is, here more carefully identified. For example, "pretty" typically means that the production output has high compliance to specifications. Or when we say "fast", what we're usually talking about is how quickly the product can be provided every time it is requested.
And earlier, the path to noticing standardization was from training that creates "discipline". But now that we've noticed standardization and its place as a principle, we can recognize and include other key influences that are related to it, such as policies.
Pulling these constraints and principles more to the foreground, the following picture shows how Archestra's ActiveROI model similarly organizes management in IT production organizations to drive productivity for the business it supports. As seen here, ActiveROI describes the systemic relationship of the constraints of design, controls and sources through implementation of architecture (design), portfolios (sources), and policies (controls). Investing in this systemic management practice puts the organization on the footing for not just efficiency (a small piece of the puzzle) but for holistic generation of business value.
[See more on ActiveROI by searching Archestra. ActiveROI, originated by Malcolm Ryder and commercially developed at Renovance LLP, pops up in various disguises in your Google or Yahoo search results, but it should not be confused with marketing companies, other persons, or machine intelligence projects that like the name so much they use it too. For updates to the model, and for a list of its authorized promoters, search the Archestra archives exclusively, and/or contact M. Ryder at Archestra.]
Posted by Malcolm Ryder at 11:56 AM | Comments (0) | TrackBack
October 13, 2006
How to measure IT's contribution
Flashback from CFO: Magazine for Senior Financial Executives, Spring, 2005 by Malcolm Ryder
Regarding the notion of estimating how much revenue to allocate to every kind of corporate resource in proportion to each respective resource's contribution ("Revenue Is What Matters," Letters, Fall 2004), I have to wonder what purpose there is to that.
Not being an economist myself allows, perhaps, my view on this matter to spawn a useful question. Namely, without a definition of "contribution" there is no logic to the presumed "proportion," and don't we already know from real life that contribution means impact and that impact is defined by the system of measurement?
What most of us in IT and everyone in science have learned is that we can't talk about impact without talking about complexity, which means talking about interdependencies and frequently about the obscure order found within apparent chaos. If at Company X a $50 spreadsheet program in the hands of a $100K--per-year employee results in a discovery that generates $10 million in revenue, that's a great trick. And yet even if Company Y copies the same set of "resources," it probably won't get the same results.
The reason why accountants have not set or proved the so-called value of IT is because value is not generated by resources but instead by dynamics, and accountants don't measure dynamics. I agree that what is needed is a look at the answers already found in other disciplines.
For example, meteorologists measure systems and motion, such as high pressure, low pressure, and temperature, and from that they can attribute daily and even hourly impact to real causes instead of merely to gases. Likewise, coaches who actually know how to coach can tell you that the influence of the most talented player on the team can turn the team into a loser, where a much lesser talent can influence the team to win and so gets put on the field.
So the key is to break free of the notion of "resource" that is rooted in a concern for corporate property and learn to see that the elemental dynamics of situations are the real resources.
For most companies, the closest they come to this awareness now is their understanding that some company assets, like people and technology, must service something that they call processes, with processes representing the company's hypotheses of desirable dynamics. Logically, then, the process is the closest they come to defining the resource that should claim some of the credit for the revenue. What does the process cost, and how well is it managed?
Malcolm Ryder/Chief Strategist/Renovance LLP/
COPYRIGHT 2005 CFO Publishing Corp.
COPYRIGHT 2005 Gale Group
Posted by Malcolm Ryder at 9:56 PM | Comments (0) | TrackBack
September 29, 2006
The difference between Value and Valuable
In our management comfort zones, if we're not in the skeptic's cart, we'll usually associate "strategic" with "valuable" in an almost automatic reaction, with the additional thought of "higher" value coming along for the ride. It just feels like the enormous discipline required by strategy makes the higher value of strategy harder to come by than non-strategic value...
But the big news is that value doesn't come from strategy. Instead, value comes from execution. The essence of value is that it is a difference with a significance -- and that difference doesn't just pop up on its own.
Strategy might define what will be considered "significant" about a difference, and of course that's the real job of strategy: to identify and promote pursuit of what is most important. But literally making that difference occur is what execution is all about.
Thus, while the priorities and positions set by strategy are what we'd consider to be "valuable", that simply means that with them we have a reasonable hypothesis of the potential for value to be gained. The value is not actually there, however, until execution draws it out from real circumstances.
So what are we saying that is not already obvious? Strategy is not action. Strategy, as a plan or an idea, is the money hidden under the mattress while the markets swirl around. Everyone can guess at how valuable a strategy might be, but since real value comes from execution, the irony is that the promised value of strategy generally competes with the real value of execution.
Judging from recent popular management literature, it would seem that strategy loses this competition more often than not. But this is because we tend to discredit the importance of a strategy that must keep changing in order to stay competitive with the outcomes of execution. If the strategy "had it figured out" but then had to change, then wasn't the strategy wrong? And won't it be wrong again if it has to change again?
Think through this, however, and what surfaces is that strategy is not a static reference but instead a dynamic mentality. Like a blueprint, it is essentially a set of design principles iterated for a target moment and location of delivery. The moment and location can change, resulting in a new blueprint while the principles remain the same.
We accept that these days we usually must work against moving targets, but that simply means that we have to have means of deciding in advance what our positions and operations should probably be in the foreseable future. Charting these P's and O's, and then navigating according to the chart, covers a lot of the discipline and commitment in strategy, leaving execution with the job of producing the current movement while also protecting the opportunity for the subsequent ones.
So, while we should measure execution according to that "productivity", we should remember to measure strategy by the strength of the logic with which it identifies leverage in pursuit.
Posted by Malcolm Ryder at 7:31 PM | Comments (1) | TrackBack
August 25, 2006
What Matters versus What Counts
How do you decide the "most valuable"... the "best"... the "most significant" ??
Why Andre Agassi is on my list.
http://msn.foxsports.com/tennis/story/5892448?CMP=OTC-K9B140813162&ATT=199
When determining and understanding "value", it's all about what kind of difference the observed difference makes.
Posted by Malcolm Ryder at 1:44 PM | Comments (0) | TrackBack
July 4, 2006
Business Value in IT Strategy
This picture describes the way that IT planning perspectives share the responsibility for discovering, integrating and balancing business priorities stemming from financial, environmental and operational requirements.
Strategists should consider, for example, how to place opportunity versus risks, resources versus capacity, and architectures versus agility.
These placements will then call attention to the nearby surrounding influences of real options, change management and economy of scope -- influences on analysis and design efforts in developing strategy with the apparently available opportunities, resources and architectures.
Those influences set the perspectives from which opportunities, resources and architectures are considered. The picture shows that they are related perspectives. The relationships feature overlapping perspectives, such as "risk mitigation" being handled by both real options and change management.
As a result of organizing within these influential relationships, strategic positions can enjoy inherently systemic support from the interplay of financial, environmental and operational events. This alignment of support makes the positions more sustainable, allowing the business to use them as a reliable foundation for its ongoing execution.
Posted by Malcolm Ryder at 11:02 AM | Comments (0) | TrackBack
June 18, 2006
Operations Value versus Operations Performance
To say the least, operations are a lot of costly effort. Then, because we're concerned about what our expended effort is worth, everyone wants to measure value and measure performance.
But not many bother to distinguish the two well enough.
The point of measuring performance is to determine what one's effort is worth. In fact, we'll often think and say that if performance is good then the effort was "valuable". But it doesn't necessarily follow that the effort wasn't valuable if performance was not good. Why not?
Don't confuse "value" and worth: instead, think of worth as the target impact of the overall effort -- or in other words the goal.
Meanwhile:
- Performance indicates how close to the goal your effort got you;
- Value indicates what was effective about how the effort got you there.
The danger in confusing the two is that steps taken to "correct" or "enhance" previous results can too easily turn into solving the wrong problem. For example, in the name of getting better results, changing value doesn't necessarily change performance -- nor vice-versa.
To choose and make the right kind of change, and to know how it will finally help, each kind of change -- value or performance -- must be accurately conceived, and their relationship to each other must also be defined.
I.
First, consider value. Put simply, value within operations is identified in the production of a significant difference.
Ordinarily, we think that "significant" means that things didn't just get different but that they got closer to what is desired. But more strictly speaking, any difference that alters the dynamics of conditions from what they had previously been must be recognized as "significant". In that case, determining value means understanding the meaning of whatever actual difference has occurred -- whether the meaning is desirable or not.
One of the main reasons to recognize different roles in organizations is to be able to focus on different kinds of value being created. For example:
- Leaders see themselves as creating culture.
- Managers see themselves as creating viability.
- Implementers see themselves as creating capability.
So they each have different ideas about value -- and also possibly about performance. More importantly, these different approaches have to be leveraged in a way that actually does improve overall performance, which means there must be some model or "performance logic" that explains and reconciles how the various approaches get the job done.
Let's take the example of what a business wants from an IT organization. To understand this relationship properly, it must be recognized that a business person who has responsibility for leadership, management or implementation is in the role of a "leader", "manager" or "implementer". Where IT is concerned:
- Leaders want IT to provide advantages through innovation and cost-reduction.
- Managers, serving the leaders, want complexity and risk minimized, and availability maximized.
- Implementers want customizations and configurations to be prefigured and completed, not ad hoc and hurried.
And to fully understand that state of affairs, it must be recognized that ideally an IT person can take on all of these roles as well. What should happen is that in sharing a given role, the business person and the IT person should divide the labor called for within that role, and conduct the labor to make the appropriate kind of difference with that role.
The division of labors starts with clarity on what the issues are to which each role should be primarily attentive.
- Leaders see change in terms of Opportunities and Threats.
- Managers see change in terms of Strengths and Weaknesses.
- Implementers see change in terms of Norms and Exceptions.
With the issues distinguished by role, a given role's two main viewpoints on responding to them are as a Decider and as an Enabler.
II.
In the Business/IT example, it is common that the Business takes the Decider view and IT takes the Enabler view. But -- to cite an instructive case in cooperative role-fulfillment -- these days IT executives are usually strongly urged to acquire the ability to understand things from both points of view, and to exploit that ability within their responsibility and domain expertise for managing IT.
In pursuit of goals (i.e., worth), everyone wants change to be positively valuable instead of indifferent or destructive. In the normal business context, recognized value is associated with the ability to positively influence the customer's acceptance of what you want to offer. For this purpose, the roles align with each other to systemically (not systematically) address each other's requirements and leverage each other's contributions. Leaders look at the market and respond to it; but Managers respond to the leaders, and Implementers respond to the managers. In the flow of requirements from leaders to implementers, this alignment -- or better, coherence -- can draft progress towards the goal. The point is that each role makes a kind of difference that nurtures the effort of the role next in line. In the following illustration, we go further and argue for a fully interconnected set of relationships.
Given this "closed loop" view, the final link of alignment would appear to be that Leaders will also look to Implementers in some way, not just to the market. Superficially, it's hard to argue against that link being "evaluation" or "assessment" -- that is, leaders taking the time to decide whether the implementers (were able to ) have realized what is needed.
But based on long-standing arguments in the field, most organizations need a better understanding of what this last apparent link is really about. The starting point for clarification is simple: Leaders should not tell implementers what to do -- but instead tell implementers what is needed. The better Business gets at defining needs, the more likely it will wind up with something valuable that it wants -- so it falls to Leaders to assure that Business Needs are well defined and communicated. For example, in the classic case of trying to coordinate business and IT interests, leaders need to set the business agenda for IT -- but business should not set the technology agenda.
But how do they forge their cooperation?
III.
In general, agreement, not command, is the "constructive" mode for their coherence or alignment:
- The business agenda for IT is made up of objectives; it should be all about when and why. Leaders and managers should agree on that -- on when some condition should be developed or pursued, and why. This will be reflected in planning.
- The production agenda is made up of requirements; it should be all about which and how. Managers and implementers should agree on which activities should be executed and how. This will naturally be reflected in the choice of producers but will also be reflected even more basically in processes.
- The technology agenda is made up of resources; it should be all about what and who. Implementers and Leaders should agree on what gets used and who gets to use it. But that agreement will be based on business needs. Policies, especially, will hold this connection.
The set of agreements describes how the continuously interacting roles stay contained in the loop.
How does this model the logic of performance instead of just the range of value types?
Going back to the basic definition of "performance", the focus is on how far the effort has taken us towards the goal. The key idea of the performance logic is that certain types of value are created by the effort, and the value-types combine to foster progress towards the goal. The "logic" of the progress is in how the value-combinations create advantages for, or remove barriers to, progress -- and the punchline is that progress itself must be defined before it can be measured. In the model offered by the diagram above, performance is seen in the additional degree to which a goal-oriented change means capability (through implementers), viability (through managers), and acceptability (through leaders). Said differently: what can be done, how well can it be done, and how much will we support doing it? To the extent that those factors account for successes already noted, their combination may be used as a predicter of future success. For the most part, amongst roles that generate these "success factors", the coherence provided by plans, processes and policies mirrors and directs the logic and its re-use.
The table below pulls together the above thoughts in a representation of discovering and cataloging the generation of these success factors. It overlays the distinction of the key roles with the main viewpoints within each role. The table lays out the task of identifying what decisions and enablements can be associated with each role -- and from there, alignment would be tested or attempted in plans, processes and policies.
IV.
Postscript:
Because production flows from implementers to the leaders, Managers bear the responsibility for proving that implementations can be aligned sustainably with the business objectives. In effect, Managers act as the "agents" and "brokers" for Leaders.
Of particular note in the IT example scenario, change is the biggest problem in IT, because it challenges standards, forecasts, and budgets -- all the things that make it possible for managers to minimize complexity and risk. For that reason, Change Management must be something that Leaders are willing to be champions for, otherwise they should not expect managers to do well.
Posted by Malcolm Ryder at 7:25 AM | Comments (0) | TrackBack
May 31, 2006
Debating IT's Value
The April 14 2006 web version of CIO Magazine brings this refreshing editorial "Credit Where Credit Is Due" to the ongoing jousting about how to measure the business impact of IT. In the editorial, MIT's Erik Brynjolfsson advises that, based on recent research conclusions, we need a new approach to talking about IT and business success.
What is "success"? From the perspective of the goals of the measurer, it is performance versus goals. Not coincidentally, when the business and its stakeholders think of "value" they typically think of performance versus goals. It makes perfect sense, then, that each business would want to recognize its particular success factors -- the aspects of its performance that drives it towards its goals. Naturally these goals may or may not coincide with those of other companies at the same time of reckoning. After all, any given time, two companies might not agree on where they need to try to be, but even if that coincides they might not agree on how to get there.
Good debaters know that a lot rides on how a question is phrased, and the right phrasing about IT's value is "what *kind of* value does IT offer to supporting the success factors of business performance?" This makes it more obvious that getting the success factors right is the first step in measuring IT value. In other words, the reason a tool is valuable is because the work that it's doing is valuable work.
This seems blindingly obvious; and more to the point, it is in no sense a new idea. As a concept, it doesn't need to change at all -- rather, when mulling over IT and trying to explain why we ought to have something, we need to abandon the distracting obsession of using asset metrics instead of using performance logic.
Posted by Malcolm Ryder at 6:58 AM | Comments (0) | TrackBack
February 27, 2006
Getting Governed: Handling the Risk of Value
Remember life before governance?
We planned the work, and then we worked the plan.
A lot of the planning was about defining the "we" -- and cascading that definition down from the high (market) level to the low (task) level.
In this cascading, our business starts out as a model for certain kinds of market interactions, and then an organization is created to operate according to the model. We have a strong idea about what kinds of things are required for the interactions to succeed, so what we focus on is making sure that we know someone is responsible for attending to those requirements. We distribute those responsibilities -- expecting the organization's dynamics to more or less derive from that distribution.
So far so good. Then the fun begins: people actually start doing things, and on any given day the cause-effect relationships of what they do to what they accomplish is most of what we ever think about -- except of course for considering the value of what got made.
Between the resulting shortcomings and the advantages, the unnecessary and the useful, we make most of our judgement calls about what should continue "as is" and what should change.
The big hypothesis is that the model we started out with will generate sufficient redeemable value, if only it is executed vigorously enough. We're experienced enough to recognize that there will be obstacles, but to get around them or through them, we're willing to redesign the way we meet the requirements.
How much of that flexibility is a good thing?
I.
Most businesses initially take a pragmatic approach to flexibility that looks at whether results seem to be proving the prevailing method of satisfaction. The habit: do more of what works, less of what doesn't, and look mainly for external indicators that something different should be done.
The "performance" mentality is driven by pragmatism. But what has also developed during the last five to ten years is a perspective that holds the entire enterprise responsible to a community of stakeholders -- which expands the range of external drivers and, correspondingly, requirements.
In some arenas, this new perspective argues that the broadened scope of responsibilities actually increases the likelihood not of episodic performance but of sustained performance. The intuitive logic of this is as follows: as an aspect of competition in a hypercompetitive world, it's too risky to alienate or disrepect any stakeholder of significant influence -- namely, one who has the freedom to take their support to a different business (such as customers), or one who has a critical opportunity to undersupport their host (such as sponsors and employees). Performance is therefore seen as the result of stakeholders being motivated to beneficially cooperate in their provision of a hospitable environment for the business's competitiveness.
Environment? As represented by models such as "balanced scorecard strategy maps", stakeholder cooperation means logically promoting desired outcomes by chemically reacting in more or less the same alignment seen in a value chain. This reaction is casually thought of as a "process" because it represents cooperation as interdependencies -- and then represents interdependencies as a set of serially productive influences. If A then B; if B then C; etc. But a proper understanding of the influences is that the "links in the chain" are actually dimensions, co-existing and intersecting at all times, creating an operating "space" within which the organization tries to find, extend and orientate itself.
In contrast, a "governance" mentality is a more functional outlook than environmental. Closely related to the problem of methodological quality, governance argues that the organization must execute systematically but that its system cannot be managed without enforcing limits on the complexity of its internal interactions. As opposed to the competitiveness that is the ultimate concern of the performance perspective, the governance perspective is ultimately concerned with the effectiveness of the organizational structure in its given configuration.
So what is the argument about effectiveness that governance makes?
II.
Three thoughts lay out the governance view on effectiveness.
(1) Governance and Performance share a strong concern with impacts, but where performance looks at impact from a benefits point of view, governance looks at impact from a risks point of view.
(2) Governance distinguishes effectiveness from impact. "Effective" means that a certain way of doing things is acknowledged and desired for the predictability of its effect. The concept's true significance is in its use for identifying and thus selecting functional options according to a pre-measured balance of value versus risk. (Not all value is beneficial; value is identified as a significant difference, but benefit imposes the requirement that the difference is relevant.)
(3) Governance focuses on the likelihood of the organization's functionality being systematically coherent enough to maximize value while minimizing risk. It's natural elements of disciplinary intelligence are architectures, policies, and approvals -- all of which organize constraints on demand.
Performance, in contrast, concerns itself with "efficiency" -- in terms of how much input is necessary for a given level of output "on-demand". Performance doesn't expect governance to work on efficiency.
But what performance sometimes forgets is that the kind of capacity made available as input (to demand fulfillment) is a product of governance. Poor governance can easily mean poor (or unreliable) input.
In real life, not just in theory, performance's demand on capacity has not been a good thing for businesses lacking governance. The most notable consequences include corrective movements such as Sarbanes-Oxley and the crackdown on software license violations -- as well as gutted share prices and other industry news headliners. Less notable as general news are breakdowns like post-facto productivity failures in mergers, missed time-to-market, or violations of contracted service levels. To an important degree of frequency, these outcomes spring from innovated and improvised execution that has been directed yet disruptive, dedicated but ultimately incoherent.
Governance implements a certain way that real-time functional capacity is produced -- in the same way that fitness and technique combine to power an athlete's responsiveness to opportunities and threats. Ideas, strategies and plans are based on confidence levels in effectiveness.
III.
Governance focuses management on effectiveness by forcefully modeling execution as opposed to just process. Execution is dominated by the decisions that occur before action is taken. Process models assume a certain range of circumstances, but processes must be invoked. Execution is a management function establishing the decision that activates a process. Whether formulaic or improvised, execution precedes process and is primarily attentive to the circumstances that present or argue for the alternatives in hand.
Governance is concerned, therefore, with the quality of the decisions, and with preventing execution from being displaced by process. Here, decision quality refers to the risk/value balances that establish response-capacity on terms predictable by all key stakeholders -- and execution intends to manage impacts and help build benefits accordingly.
The illustration below describes how governance aligns influences on operational behaviors in a way that aligns the generation of impacts with the concerns of stakeholders. As shown here, the key feature of governance is management's attention to control. But the influence of governance pervades several layers of functional predispositions. An important property of the arrangement as illustrated is that it also establishes the semantics for discussing governed response-capacity -- on each layer and in the relationship of the layers to each other.
These semantics do not "cascade" -- not in the sense that the meanings on one layer are derivative of meanings on another layer. Instead, they distinguish what it is about each layer that is most relevant to controlling response-capacity for the best balance of risk and value. As a result, the various layers are logically complementary in their overall influence on the functional coherence of the organization. That is, under governance, the impacts of individual functions do not work at cross-purposes, making response-capacity more reliable under demand.
Posted by Malcolm Ryder at 6:09 PM | Comments (0) | TrackBack
February 21, 2006
Culture as Brand
Here's a thought: large companies have the problem of peering into the crystal ball, while small companies have the problem of functioning in a fishbowl.
What does that mean? Large companies act like they are picking the market; small companies act like the market is picking them. Both cases, tough situations for them to handle.
Ironically, the lip-service in each case is usually reversed. At least when these companies are facing their funders, large companies talk about being picked, and small companies talk about doing the picking. Interesting how things switch when the issue is asking for money instead of taking it.
Thinking of the small start-ups and non-profits that I've worked with (not exclusively!) over the years, I'm reminded that both of them frequently struggle with another interesting choice. They might have multiple value propositions riding on the same competency, or they might have only one value prop that anyone cares about, and must shift amongst multiple competencies in order to continue delivering the goods. My experience with them is that the more the outfit needs money, the more it sends multiple competencies at one value prop -- whilst the more it already has money, the more it imagines that one competency is wonderfully fertile. This is related to the market targeting issue, but it's more directly concerned with competing after the targeting has been done.
Related to that, I notice that we usually try to imagine branding as being a cause versus being an effect. That is, if brand is what we want buyers to think we think we're about, how do we make the many things that we do cause them to see us one way? Or are we simply at the mercy of whatever random things they do to see us?
Mulling over branding a few years back, and thinking about companies that can't see themselves the way customers see them, I hit a point regarding the vast difference between "positioning" and "position" -- hardly a new topic. I suddenly had the thought that to close the gap, the real purpose of a business is to create customers, while the purpose of a customer is to create products.
The realization came from an imaginary dialogue:
Company: "I'm doing this *for You*
Prospect: "Yes, but are you doing it *this way* ?"
Company: "Well, what do I get if I do?"
Prospect: "You get *me*..."
Think about how persuasive it is to be able to tell an audience what kind of customer you make -- which is what we can think of as the "cause" aspect of branding. Prospects would say "I want to be like your other customers" and so the reputation helps you to make more customers. (Good positioning!)
The "effect" aspect is more about the product (or likewise service) that actually gets made. Although the catalyst for the product is the customer, the bottom line is that the company winds up making the product for itself and finding out later if it's good enough to sell. Prospects say "I require something of a certain type" and their scrutiny of your product/service ranks you (leaves you) somewhere in their consciousness. (Position, for better or worse.)
At any rate, those thoughts boil down to the idea that the prospect defines the opportunity by expressing their *preference*, so you market to the preference. Moreso, as savvy salespeople know, the preference reflects an "assumed identity", and the same prospect could turn into several different customers.
Putting it in the context of revenue growth through superior competition, such differences seem to point at segmentation. It's quite interesting to imagine that one given potential buyer might be a customer simultaneously in different segments, but this is something to think about especially in terms of what customer relationship management must address. Frankly, it must address culture -- which is the empirical evidence that the prospect's multiple personalities make sense to them...
Posted by Malcolm Ryder at 1:53 PM | Comments (0) | TrackBack
February 20, 2006
A Comprehensive Governance Framework
Why Governance?
Institutional control is a matter not only of doing things "correctly" but doing the proper things correctly. And, we want to control the institution in a way that is itself institutionalized -- just as a mature person would normally control themselves in accordance with appropriate principles of behavior that should be habits of character.
But what is it about an organization that particularly needs governing?
If the organization is a "business", then the motives of a business will drive organizational activity and the point is to steer those activities in principled ways that actually help the business.
The framework below sets the high-level business motives (across the top) as the outlook on key focal-points of the organization's management.
One set of points -- competency, policy, and strategy -- together describe the organization's makeup stretching from what it knows how to do on over to what it should do and finally what it has decided to do. In effect, this describes the current predisposition that the organization brings to its work every day.
The other set of points -- strategic development, operational availability, and transactional consistency -- summarize the organization's major proactive mechanisms for generating "delivery of value" to stakeholders. This is more like the organization's position (not to be confused with positioning).
The balancing act between the organization's predisposition and its position can be seen as a basic behavioral phenomenon demonstrating what the organization knows about how to translate its potential into reality. (Of course, this should include some consideration of whether the current potential is desirable and/or needs changing.)
Given those two axes, the framework looks at the internal structure of the organization for the key contributors that govern relevant business activities -- that is, what it actually winds up doing.
A key observationof the framework is that the organization's capacity to respond to opportunity and demand is hugely shaped by the coherence of its governance. While a lack of governance does not preclude notable capacity, the exact lesson learned in business between 2001 and 2006 is that risk factors in responsiveness can make existing capacity more of a liability (dot.bombs, Enron, etc.) than a benefit. This makes the influence of governance a major force to be leveraged in value management.
At the high level, this is referenced through the framework by its correspondence of the organization's processes, services and portfolios to the goals for progress, production, and achievement.
Naturally, real organizations are not governed only in terms of the intersecting issues presented here. However, governance must attempt to identify the most critical types of decisions to attend to at the various locations and levels of the organizational structure. A primary objective of the framework is to describe the sources and flow of information that can sufficiently account for the effectiveness of the organizational structure.
In that regard, a management ability (BPM) to associate competency and policy exploits certain types of information that can organize appropriate behavior. In like fashion, an ability (BI) to discover and exploit value-laden opportunities for that type of behavior keeps the governance in service to the goals of the business.
The final note for this introductory discussion is that the framework is intentionally abstract so as to allow it to be applied to organizational units of widely differing scale and flavor. There is no reason why a small business unit would have less of a need for governance, and no logical reason why the essential points of governance would be different. Instead, the most likely difference is in the level of awareness that the business unit has about what kind of opportunity governance would bring to the unit if successfully instituted. This is not intended to make any point about the intricacy of particular best practices in governance applied and distinguished between "corporate" or "IT", "profit" or "non-profit", and so forth. Those practices are rightfully derived from the communications needs held by stakeholders in the responsibilities that distinguish their domains from each other. Yet the framework presented above argues for the similarity of management across those domains, and calls out for a certain breadth of awareness that is about explaining why control becomes valuable.
For a related discussion of IT Governance in particular, see the article Surveying IT Governance by clicking here.
For an in-depth discussion of related value-creation issues, click here to see the article, The Business Creation of IT Value, which looks at how business management takes the organizationof IT and develops it to support the business position. While this is not strictly an example of implementing governance in IT, as a followup to the discussion here it illustrates how the problem of "Business-IT alignment" works out in overlapping areas of governance and resource optimization.
Indeed, if we look at coordinating the issues of managing organizational behaviors and resources, we return to the earlier observation that there is a correspondence of the organization's processes, services and portfolios to the (governed) goals for progress, production, and achievement. Seeing "IT" as a corporate resource, the correspondence might be articulated (see illustration here) as an allocation of IT organization responsibilities to those three aspects of the business position.
The thought it leaves us with is the question of how running IT "for" the Business relates to running IT "as" a business, and how business governance and business strategy connects to IT governance and IT strategy. From the framework introduced in this discussion, the indication is that strategy is an area in which governance has an influence -- and that influence is likely to shape Business objectives in ways that IT's influence will have to respect. Thus, IT's own governance will have to establish IT's business-like predisposition and position for compatibility with the way the Business's objectives are meant to be addressed.
Posted by Malcolm Ryder at 1:27 PM | Comments (0) | TrackBack
February 16, 2006
Does Different Software Make a Difference?
He who forgets the past is doomed to repeat it...
That's not an inviting scenario for companies that decided to get rid of old software in order to improve costs and productivity.
"Goodbye, and Good Riddance!" was the attitude, and why not? Typically, the understanding was that older software was keeping important work from being done because:
- it didn't have the right features, or...
- it had the right features but its method was too involved or complicated, or...
- it worked fine but it no longer was covered by a support agreement whereas newer stuff would be.
Those conditions eventually got discovered if only due to difficult events cropping up with ongoing usage. The decision to intentionally change was well founded by evidence.
But taking the pain first wasn't the only way to handle it. We could also have anticipated each of those three problems -- and actually scheduled them right out of the "future problem" zone.
So it seems, anyway... but there are complications in trying to do that. For example:
- Changes in the users themselves can make features suddenly seem more or less appropriate.
- Training and Standards streamline patterns of usage but are both more difficult to come by after the software is already in company circulation. Demand for the software to spread is typically much higher and faster than the acceptance of training or standards.
- Most software gets under-utilized; but the part of the feature set that gets the most use becomes more than familiar enough to continue on after support agreements have unnoticeably expired.
And the final twist is that the software lives on the hardware -- so hardware decisions very often wind up becoming defacto decisions about the location and type of software. For example, if the hardware walks out the door, so might some software! Or if the hardware gets upgraded, the old software might not be able to keep up. Finally, can the new software be used without having new hardware first?
This means that newer software, bought and implemented, may be trying to add benefits on top of unsolved ills.
If new software and/or upgrades are to be done in a way that can handle our intentions and the complications that get in their way, there must be a breadth of awareness that requires information pooled from a variety of sources.
Let's look at an example of how this awareness, or planning perspective, results from the information pooling. Our perspective will be built with the following:
- Purchase plans
- Vendor records
- Employee records
- Distribution records
- Support records
- Budget and expense records
First, a general overview: the sequence of this group of records allows us to trace the life of the software as it changed from being someone's property other than the company's, into property company owned or contracted. It also traces the availability of the software from a period when that was a supplier problem to when it was a company problem. As we watch the meaning of "owner" and "available" change over time, we can see why the change happens -- but we can also recognize that earlier meanings often get forgotten or demoted as later meanings take over. In other words, things that are still true about the software fall out of sight, out of mind. But if those forgotten conditions can still exert influence, chances are that they will.
Next, some specifics. In each of those different kinds of records, imagine (or confirm) how one particular piece of software is uniquely identified. Identification rules might exist for each different type of record, but do any of those rules intentionally support preserving the identity of the same unique piece of software across different kinds of records? Who within the company creates the rules that do that? What do they expect to get from using those rules?
Now, for the effort to handle our new intent and the complications that underlie them, we need to figure out how the old stuff might compete with the new stuff. We can look at that in three ways:
(1) Fiscal -- what kinds of dollar-related issues are still associated with the software?
(2) Physical -- what options and restrictions exist on where the software is and should be?
(3) Functional -- what certainty do we have about why the software is being used the way it currently is?
And in every case, the challenge is to be able to get reliable answers in a reliable way.
For most of those questions, getting the answers requires identifying certain decision-makers, finding out how they make decisions, and finding out how they prove that their decisions were executed and maintained. That will push us into the records.
This often turns up a lot of inefficiency at best, or chaos and contradiction at worst. Those problems have to be minimized, because they are at the root of why old software can come back to sabotage expectations about new software being helpful. And what everyone needs to remember is that new software becomes old software, too.
If a collection of reliable data from those sources can be consolidated, it can then be analyzed to find patterns that indicate where upgrades or new software can most likely have an impact. The probable degree of impact should also begin to surface as a matter of how hard it is to eliminate barriers represented by old software or, jujitsu-style, to exploit its current attributes (fiscal, physical or functional).
Finally, as the hub (if not the holding tank) of the consolidated information, the software inventory should be available as the primary thinking tool for planning change from the old to the new.
With that emphasis on analyses that improve planning, many organizations might want to revisit the reports that are currently published from the software inventory -- and assess whether those reports are really helping to manage things as opposed to merely tracking them.
Posted by Malcolm Ryder at 7:58 AM | Comments (0) | TrackBack
February 15, 2006
Just the Facts, Ma'am
Ever play "Telephone"? You know, the game where someone whispers a message into another person's ear, and that person has to whisper the message to the next person, and the chain of whispers goes on person after person until the last person is asked, "What's the message?" This is usually where everyone's funnybone gets whacked, when the answer turns out to be entirely goofy as a transmission of the original message.
Looking at the data in your software inventory can have all the same fun and excitement -- of knowing the validity of the info you're getting is... laughable!
All you have to do is (1) keep no track of how many times the information was transferred, and (2) not care where it started out. Easy!
Sure enough, for thousands of organizations, it is really amazing how "entertaining" the inventory is to business users.
But on the other hand, if you are the person who is held responsible for the data, you probably have a lot less interest in this game. It's almost criminal how hard it is to fix the business mistakes and misunderstandings that can grow from the unreliability of the information.
The problem is, as the game demonstrates, that when garbage out goes on to become garbage in somewhere else, the mistakes get magnified.
Where are the likely "garbage in" points in your company?
IT industry research organizations like Forrester, Gartner, and the Standish Group routinely bring up three major points where business leans on IT for information inputs: architecture, projects and support. Not only is each of these subject to being spoiled by bad information, but the relationship of the three to each other can magnify their individual damages.
Why are they so vulnerable? Because each one has a major design component that is what makes it of any further beneficial use – and the design is based on the information inputs. Bad info leads to incorrect design, which leads to incompatibilities with the ultimate business purpose. These incompatibilities include mistakes like:
- making something incorrectly, which because it doesn't work leads to re-work just to get it finished;
- making something with poor quality, which leads to breakdowns; and,
- making the wrong thing, which leads to disposal;
Add the time, money and potential aggravation involved, and it's easy to see where impatience and anger make the difficulties bigger than just the difficulty per se.
Popularly, it is believed to cost 90% less to prevent a problem than it does to fix it. Ben Franklin probably made the idea popular (a stitch in time saves nine) but it keeps getting proved again in things like software programming and medicine.
As it turns out, software inventory information can likely be the key culprit of those major corporate mishaps, but is also a likely candidate to be the prevention hero for such problems.
Three areas where the corporate "entertainment" value of bad inventories becomes criminally difficult to reverse are in penalties -- from failure to meet contracts, failure to meet the law, and failure to maintain security of corporate data. These can be very substantial risks.
(1) Contracts assume certain capabilities to deliver, which depend on processes with high levels of reliability. But that reliability depends on technology configurations that must execute functions properly on demand.
(2) Laws state that companies have only certain rights to use technologies in certain ways, but in the heat of competition, corporate user behaviors may be unconcerned or unaware of the restrictions.
(3) Confidentiality underlies much of what turns a company's knowledge and difference into an advantage. It's just too hard to run the plays when the opponent already knows what you're going to do, and what you're going to do it with. Software is how you get to your information; it's how they get to it, too. Ideally, they don't get their hands on your software...
These are three different issues, having particular software management solutions but solutions that are enabled by inventory information.
- Version control and delivery puts a foundation under contracts.
- Delivery and authorization keeps users within the safety zone of usage rules.
- Authorization and tracking keeps tabs on where those software stepping stones are that lay down paths between information and info users.
The overlap in the solution approaches is not an accident. Furthermore, it doesn't stop there. Tracking confirms what versions are actually under control or not -- immediately implying certain things about the effectiveness of planning, changes and acquisitions as currently practiced.
Overall, the point is to have the right software in the right place at the right time for the right reason.
When those four qualifications are met simultaneously, risk has been minimized. But this is a point that may never be reached or long-lasting for all situations. Since the business is by nature a dynamic affair, requirements and circumstances keep changing and present the need for adjustments in how software is involved. Managing risk has a goal of minimizing it in total, but the process is about being continuously proactive to keep it from growing where it wasn't already and doesn't have to. For that effort to be efficient, the relevant information must be accurate.
The pressure on the IT organization is to ensure that the data in the software inventory is always capable of expressing when certainty about risk has been lost, and expressing with certainty the facts about whatever is wherever it is and how it got there when it did.
Posted by Malcolm Ryder at 3:39 PM | Comments (0) | TrackBack
February 14, 2006
The Sources of Software ROI
Be careful what you ask for: you might get it!
That's what everyone needs to know about ROI.
ROI is a term that everyone intuitively understands but -- as often as not -- can misinterpret. The generic interpretation of ROI is nothing more nor less than a formula that describes how we expect value to come from spending. But that means being careful about what it is that we consider to be "value" as well as "expense".
One interesting task that carefulness suggests is to catalog how different kinds of expense match up to different kinds of value. This will show a set of many-to-many relationships. Consequently, what comes to the surface is that there are lots of different stories to tell about whether people are getting their money's worth or not.
In telling those stories, one factor to discuss up front is the difference between "cost and "expense". Expense is a budget issue that relies on approvals. Cost is a financing issue that relies on strategy. We don't want expenses to undermine the financing strategy, but too often an expense is the beginning of something that winds up costing a lot more than expected.
Meanwhile, what about "value"? We know from experience that what is valuable for one party may not be seen as such by another. This occurs because the nature of value lies in the importance that is attached to some distinction that has been made. Many parties can agree on what distinction was made, or in other words, what change took place; but unless those parties all have the same needs and circumstances, the importance of the change is likely to differ, in level and/or implications, from one party to the next.
So when it comes to ROI, what we really look at is how certain reasons for expenses would be associated with certain kinds of expectations about impacts.
For example, wIth software, the typical association is between the purchase justification of ownership and the predicted risk/benefit of its usage. That's a one-to-one relationship, but different parties experience different benefits. So it's as if the software is associated with any number of expectations, some more clearly or strongly than others. Likewise, an impact may have multiple sources.
In effect, there can be many different combinations of such reasons and expectations -- some apparently more preferable, logical or validated than others. Indeed, those are three attitudes that can help explain differing parties' often different perception of importance and therefore of value.
Normally, no one pursues combinations that don't have some positive attribute.
However, in cataloging already accepted reasons, expectations, and combinations that the organization either proves to have or claims to have:
- Sometimes the matchups are ones that just don't fit the policies of the organization. When it comes to the purchase and subsequent use of software, these stories tend to include issues with missing or disorganized support, and with potential theft.
- Some matchups don't seem likely to occur even if they are desired, due to organizational structure or processes that crowd them out. These stories point at issues like legacy implementations -- and legacy decisions, too -- that compete with change. And on the flip side, issues here include unproven new software, prematurely deployed.
- Some matchups are more under the control of users than providers, or vice versa, and there may be a question as to whose administration is better and/or whether the real control is actually the way it is generally believed to be. Here, key software issues involved include a lack of standards -- or disagreements -- in accountability for the condition or configuration of things.
Companies try to protect ROI with their policies, processes, and administration -- but it is not unusual that pressures from competition (that is, needs) or from business performance evaluations (results) can provoke isolated decisions that create misalignment between them.
So, one problem we find amongst these stories is ROI "erosion". Between the reason for software being bought, the habits for using it, and the ways it actually affects the organization, the value proposition gets worn down.
Software Management has an important objective of protecting the software value proposition against erosion, so that the software's potential ROI can be realized.
To offer this protection, management must be able to confirm that any practiced combinations of purchase reasons and demonstrated impacts are:
- documented, trackable, and reasonable; plus,
- prioritized, supportable, and improvable.
In the first set of confirmations, evidence is king. In the second, agreed requirements are the key.
Often the second set is practically impossible (or pointless) without success in the first set. This puts the emphasis on having, through the first set, a reliable reference record that accurately communicates not just what is available but why it is.
The software inventory is at least a concept that satisfies the role of being the reference record or database.
Many known complications with software inventory are due to the fact that records are created and maintained by many different parties for different reasons, which might later resist being well consolidated. Records maintenance also may vary in its diligence, completeness, or other quality levels -- according to who is doing it and why. Often this is tolerated because the standards for accounting are not demanding anything more. So one of the first things that must happen to drive a change in records maintenance is an explicit company need for standardization.
Standardization really means that everyone understands how their piece of record-keeping fits with pieces that must be maintained by others. Like with a protocol for a network, each part understands what the other part means. As a result, the parts do not all have to be in the same place, but they all have to speak the same language or use the same grammar. With software reference records, the grammar is a data model that all record-keepers share.
Going along with that is a move beyond accounting to analysis. By itself, accounting does not express the importance of the many-to-many relationships between what software is present and what it is actually doing. So, accounting does not talk about ROI. Not understanding ROI means not having one of the most essential ways of evaluating whether current software is helping or hurting -- and whether change should or should not occur. So what we look for is a chance to do analysis by being able to correlate impact data with reliable accounting data. This highlights the significance of getting control over the inventory -- which becomes a driver for a standardized data model.
Posted by Malcolm Ryder at 2:38 PM | Comments (0) | TrackBack
February 13, 2006
Why You Pay Too Much
One of our colleagues likes to say "My favorite kinds of problems are Other People's Problems and Problems That Go Away By Themselves!"
Some people think that software purchases can get put in there. It might be a department or project with its own "big stick" budget, damn the corporate delays. Poof! More stuff. Different stuff. Cool. Or, it might be annoyed users, hands hovering priestly over hard-to-support legacy stuff, softly chanting "upgrade"... Poof!
But back on planet Earth, lawyers, support teams and vendors see unexamined, untracked software purchases as The Problem That Won't Go Away. And when CFO Magazine runs a feature on taming the costs of software, you know the "Business" is not waiting any longer for "IT" to make things better. CFOs all believe a sales genius named PT Barnum, who told them that "a fool and his money are soon parted." Taking a cue from them, let's get a quick rundown on what the top sources of cost problems are and why they persist.
1. Shopping fatigue. After bruising technology selection projects, everyone is determined to have the winner show up. Tolerance replaces discretion. Bruising vendor selections? Please, not now.
2. More shopping fatigue. After spending 20 to 30 years learning algebra, your company's buyers watch software vendor contracts show up requiring expertise in chaos theory. "Doh!"
3. Inexperience. As CFO pointed out, why would an internal procurement person who does a big deal every blue moon be able to stay on the field with a sales guy who does it all day every day? You've gotta ask yourself a question: "Do I feel lucky?" Well, do ya, punk?
4. Terror. If your company already ran the gauntlet with one vendor, it paid the price of admission and has the scars to prove it. Why run it again with a different vendor just to get back into the same room? No thanks, I'll keep the captor I already overpay!
5. Money! If you didn't need money to get software, software wouldn't cost so much! Yeah, that sounds ridiculous, but the way you get money to buy things is by asking for it. Have you reviewed the budgeting process lately? If you think you need $50K but you can only get $30K, and then you spend the $30K to try to do $50K of business impact, you could either wind up being 40% less productive than you promised, or you might stretch that $30K of software to 166% of its legal capacity. What's the chance your company did one of those two things? Back to the CFO article again for this quote from Attorney Robert Scott: "I can tell you that 100% of the Fortune 1000 are at risk for this..." And those are the guys with the BIG bucks.
6. Software! Why does software cost so much? Because it's SOFT. Like ideas, like luck, like... recipes. There's they way it was supposed to be, and then there's the way it turns out to be, often with a lot of mystery in between, according to who touched it. Not knowing who touched it, and why, becomes the main way to lose track of whether it's going to keep doing what it is supposed to do.
7. Efficiency. What?! Well here's how that works. See items 5 and 6 above, and think "Let's roll out a common image across all the desktops." The law of unintended consequences says that if this is done only as a bandaid, it will create two new problems for every one that it solves.
These are all diferent from each other in a recognized way, but they all contribute to the same kind of problems: omissions, defects and errors that keep you from having the most appropriate software in the right place at the best time.
That mismatch creates three specific kinds of money problems:
(1) lost savings,
(2) extra expenses, and
(3) wasted investment.
If you're the IT department, the good news is that you're not the source of most of those problems. The bad news is that IT has to make the problem go away -- partner with the CFO or else just watch it all get worse.
Three things IT can do to help CFOs be happy:
- IT can help lawyers be sure about what the company is really entitled to, and fortify the company's legal rights and protections.
- IT can help Support teams benefit from less mystery and complexity in tracking down software types and matching them to operating requirements and knowledge.
- Largely due to the above, IT can help turn Vendors into co-operators who use the same game plan that the company uses and who get paid to power the plan with only the right stuff at the right times.
How can IT deliver those bonuses to those groups? Take on the three areas that expenses like to grow in.
- things that arrive before they should have;
- things that change when they shouldn't; and,
- things that leave before anyone knows it.
This will turn out to be your business case for real software inventory management.
Posted by Malcolm Ryder at 3:50 PM | Comments (0) | TrackBack
February 11, 2006
Linking Economy to Profitability
After a five-year pendulum swing of spending to cutting to spending, we've managed to stretch across four chapters of the IT-Business relationship: Y2K, dot.bombing, BackToBasics, and now Compliance Versus TheTopLine.
In these chapters, the story of transitions also features patterns overlaying other patterns.
For example, over the phases, we'd see that:
- the role of an IT infrastructure was swinging from being a risk factor to a success factor, back to risk, and back again to success. Meanwhile...
-The business model credibility was swinging from supply-chain angst to demand chain angst, back to supply, and back again to demand.
With patterns like those to find and juxtapose, there is plenty of room for examination of cause-effect relationships in how technology evolution and architecture may have precipitated new phases or ended them.
No question, this examination must necessarily acknowledge both intended and unintended effects. Business reliance on IT is a double-edged sword and, as shown with space exploration, we get to know how to reach a place too soon-- but only later how to stay there, and sometimes almost too late.
Yet, respectful of the need for wariness, we can honestly look at each of the aforementioned phases and, with the clarity of 20/20 hindsight, see for each one the gigantic "DUH!" that shouldn't have had to be. Obsolecence, irrational speculation, anorexia, and opacity if not arrogance... all of them butt-kicking poisons from the business side, not the IT side.
Because of that, where the topic is "intention", there is another big story, too, about the glacial maturation of what must be considered "business intelligence" (BI). Although at the moment mired in the learning curves of collaboration and analytics, BI's ultimate goal of achieving a sufficiently comprehensive perspective is perhaps represented most clearly by models such as Kaplan and Norton's Balanced Scorecard and European systems for systematically including the measurement of intangible assets, such as Karl-Erik Sveiby's Monitor and Juergen Daum's. At any rate, the rush is on for businesses to actually get smarter through intelligence -- with the twist being in the emphasis on having the right kind of smarts.
So, lessons learned: while IT makes action almost too possible and makes info almost too widely available, these are relatively intrinsic qualities of IT -- characteristics that have the great potential to simply erupt without regard to management, and therefore are not reliable barometers of business value in IT. In turn, that means we can't build value management on the basis of those characteristics.
The real issue for management is not to "enable IT" to do those things but instead to harness and leverage IT's innate ability to be an enabler itself. Business management is the source of return on IT investment.
In that light, some interesting points surface:
- The characteristic dimension of the business focus on IT management is, except for professional developers, not technology development!
- Neither, despite all the rage and benefit, is "business-IT alignment" the essence of IT management's focus on the business; that is really a business management issue.
- However, abstracting and separating the business and the information technology, the common challenge of managing IT is that IT's impact on business activity is so intense. In IT's role as a business "enabler", the critical success factor is the degree to which IT impact organizes the business rather than dis-organizing it.
Business management must step through the logic of that success. The logic has at least these three pillars:
(1) From the business perspective, for IT to be nutritious and non-toxic, the basic business need is to deal with what it is about the business that IT aligns and how IT does that.
(2) The responsibility for managing IT's role belongs to the business, not to IT. Responsibility for appropriate production within the role belongs to the IT management organization.
(3) What business needs IT to do in the business, just as business needs other functional elements to do, is to align economy and profitability, so that having one of them doesn't diminish the other. The way IT does that is to optimize capacity.
I.
The way business uses IT for optimizing capacity is by modeling business management of IT's impact through processes and portfolios.
IT inherently offers the kind of speed and scale with which a business must build and sustain capacity in today's marketplace. With capacity as a mandatory "given":
- Processes are responsible for economy versus capacity; and,
- Portfolios are responsible for profitability versus capacity.
Managing the contribution that IT makes through processes and portfolios allows IT to align economy and profitability through the organizing of capacity.
The huge top-level significance of that observation is in its implications for strategy and change management. Strategy presumes to model the competitive advantage that the firm can capture from perceived opportunity, while change management presumes to stabilize organizational resiliency and thereby keep the business positioned for opportunity. But in the effort to balance risk versus value, strategy reflects demand, and change management reflects supply, while neither must actually include financial optimization to be logically valid. The fact is that they both are simply designs that are fully able to get "their" jobs done while being benignly neglectful of financial stress. The organization actually has to figure out whether it can use these designs, but if it can't use them it doesn't mean they are broken; rather, just inappropriate.
Thus, with IT being such a dramatic enabler of both strategy and change, managing IT should in particular target helping to fit the strategy or change to the organization's terms of self-sustainability. In this regard, Process helps ensure that capacity is effectively useful, Portfolios help ensure that capacity is effectively directed, and IT supports both of them to get it all done.
II.
One analogy for this is that capacity is the "stored energy" or "battery" of the business. IT is what charges the battery. Consumption of that power is where processes do their work (economy), but the application of the power is where portfolios do their work (profitability).
By another analogy, processes make capacity into skills, and portfolios make capacity into value commitments. Furthermore, between those two, management creates behaviors, from which actual outcomes derive. Since the behaviors can either propagate or negate the potential of the skills to address the commitments, the benefits of skills (economy) may or may not apply to the opportunity represented by the commitments (profitability). Business management, through generating behaviors, makes the link, using decisions to deliberately leverage the skills for the commitments. IT supports that management, by literally incorporating the decisions -- that is, by making them "actionable" (functional) and thus producing behaviors.
In short, IT must produce resources; managers must deploy them, and the business must commit them. This perspective guides the assessment of IT's relation to both performance and return on investment. IT-generated capacity can give managers of business behaviors more options, but the value of the capacity is not created by IT -- rather, by the business modeling of both the consumption and commitment of the capacity. High performance presumes successful execution of good models, but meantime the models must be relevant to the strategy. Finally, strategy must be sensitive to the possible capacity that IT can generate, without arbitrarily "assigning" value to the possibility.
III.
In what follows over the next several iterations of this document or in other followups, we can illustrate that concept in more ways, as well as more specifically. For example, business process management (BPM), business intelligence systems such as configuration management databases (CMDBs), and performance knowledge systems like operational performance management (OPM) bring implementations of information technologies to more directly bear on the model-oriented management that optimizes capacity.
But the immediate general statement to be made is that the business needs appropriate capacity to address its desired opportunity; and it uses IT to provide itself with not just capacity in general but specifically with appropriate capacity.
Understanding business from an IT perspective is of vital importance to IT providers who must come up with useful resources. In that regard, superior architects power superior IT providers.
But more important is the flip side: understanding IT from the business perspective means understanding what business management decides to do with IT. IT management must take its direction from business management. The directions it takes are mapped out in processes and portfolios.
Posted by Malcolm Ryder at 7:52 AM | Comments (0) | TrackBack
February 10, 2006
What's So Hard About Software?
"I know that half of my marketing budget is a total waste. I just don't know which half!" That little twist on some wisdom attributed to retailer John Wanamaker pretty well sums up what most organizations know about their software assets. They just don't have the kind of information they can rely on to get past that point.
To the very same point, readers of InfoWorld in February got cover-story confirmation of what they probably knew all along -- the madness in their enterprise data is methodical, and it's time to see the shrink.
The key points of the diagnosis are especially familiar to organizations struggling with managing IT assets. Gartner maintains that on the maturity ladder of asset management, level three (of five) is where most organizations need to be, but most organizations get stuck on level two. Now, it's fair to say that most managers, checking themselves out, consider themselves to be effective if the future provoked by their decisions is simply better than the past they decided to change. But what appears to happen too often in asset management is that things get different allright... just not better.
The issue is not the confidence to make decisions; they do get made all the time. But because management is so reliant on measurement, and measurement is reliant on description, the quality of identifying data is where most of the management effectiveness is made or broken. Without decent data, the decisions aren't worth very much.
In capturing data about IT assets, perhaps little else is as difficult as tracking software. Not only is software made, bought, borrowed, stolen, found and inherited, but it hides and changes, too. Even if we include only the occasions where any of that was really intentional, the results offer a dazzling array of subjects to track and difficulties in doing it. The final irony is that as software moves from its origins to its destination, it legitimately gets tracked in different ways for different reasons by different parties. (Who knows the real identity of the man with a thousand faces?)
As we hear pretty regularly now, the definition of "crazy" is doing the same thing over and over and expecting a different result. Since frustration with information about software assets is often really high for everyone in the chain of supply and demand, it's evident that the things we've done about it before, and keep doing, aren't working. So are we crazy, or is it just that we don't have any alternatives?
I.
Descriptions of software assets vary because of the diverse reasons for handling the software. Each party responsible for the handling naturally tries to optimize their description of the software for the particular purpose behind their own responsibility. In essence, the descriptive difference that they cultivate is part of their effort to raise their performance.
The irony is that, in an important way, this "performance" increase turns out not to be effective. Yet the practice of describing an asset in multiple ways does not often change.
To back up that claim, how do we define effectiveness? The two biggest impacts that software has on the company are on expense (operating costs) and productivity. In the organization's locations or processes, there are thousands of points at which expense or productivity can be affected. Factoring in that diversity, software decisions must improve both expenses and productivity to be called effective. But the tendency is to think in terms of each separate decision having a tolerable effect. This often goes mostly into stressing features and lowering the price. But in the mid-to-long term, if production generates excessive risks, then the cost of handling risks negates the savings of lower expense; and if cost-reduction generates excessive restrictions on acquisition, then the inadequacy of the acquired software undermines the potential level of productivity. So instead of a double-win situation we get a double-loss, and a vicious cycle to boot.
This points out that many decisions about software are made with good intentions but simply (and profoundly) are made out of context.
II.
Software management, as opposed to software tracking, tries to determine what patterns of software demand and usage correspond most closely with actual improvement or deterioration of sustainable expense and productivity. To find those patterns, management must do an analysis of what is there. To do the analysis, the identification of what is there must be valid. Unfortunately, the evidence of what is there is often highly unreliable -- unpredictably incomplete, misleading, or competing -- until it has been vetted, cleaned, tested and certified.
If those last few words ring a bell, it's probably because they are so recognizable as the same procedure used to transform most raw material input into a resource. It unglamorously (but crucially!) steps us down from "information management" to "data processing", where we can get enough traction to know that from then on we'll actually go where we steer.
The key barriers to effective processing of asset data stretch across the usual three dimensions of people, process and technology. Luckily, people are becoming less of a problem as the need to put skilled analysts on the problem of integrating disparate data becomes increasingly well understood and supported as a role and as a job. Meanwhile, technology continuously improves in its ability to automatically detect and announce when something has been added, moved, changed or deleted -- and to accept and understand external rules for doing so. That means different systems can better communicate with each other and/or with a neutral third system.
So, people are getting better at revealing the scope and depth of the problem, and tools are getting better at manipulating elements of its solution. But the remaining frontier is process, through which activity becomes achievement.
The key to the successful processing of disparate asset data is to understand how it became disparate in the first place. This understanding is represented by a model of the software asset lifecycle. As software goes through different phases from creation to distribution, use and disposal, each phase cultivates and records certain kinds of descriptions by efforts of parties responsible for the software at that phase. Since a given phase may also feature multiple parties with differing responsibilities and stakes, each party may have its own way of referring to the software at each phase. To process the data adequately enough for delivering a highly confident inventory, the process must know how to hit the various parties at all the various phases.
Aside from the challenge of bringing such comprehensive knowledge to the task, the big barriers to getting the job done are its cost payback and performance urgency. One way for organizations to address these barriers is to consider the task itself as an investment. If the cost of the task can permanently improve the cost of software ownership, and if the increase in information reliability immediately minimizes or eliminates management mistakes across the asset lifecycle, then the return on investing in the task is definitely positive and likely pretty high.
What are the pains from management mistakes that exemplify the urgency?
Try corporate fines for software license violations; failed systems rollouts due to software incompatibilities; and the combined bills for unnecessary redundant purchases and overly complicated technical support.
Then add on top of that the big issues that provoke them -- such as SarbOx compliance, which is mandatory regardless of the underlying expense it will exacerbate in process redevelopment, project management and purchases of "up-to-snuff" functionality. If it's not SarbOx then maybe it's a departmental consolidation, a new market-segment launch, or retirement of legacy systems.
Whatever: urgency is probably not missing. But practical opportunity to respond is the point of contention.
To define the opportunity, it helps to pick a target and a scope of impact, and then plan an attack.
One somewhat obvious approach is to begin sorting out the purchasing data (where acquisition cost practices can definitely be analyzed) and the inventory data (where distribution practices can be analyzed) -- and reconciling them with each other. The question of whether you actually have what you're supposed to have is the signature focus of this approach. But the answer first obtainable may or may not be reliable. The real point is to discover whether there is any control of the asset's lifecycle, and to begin instituting enough control so that the company henceforth can determine whether its production will predictably leverage the purchase value of the software. This discovery will indicate points of operation that are potential points of failure underlying the demand from business units, regulations, and funding caps. Eliminating these points of failure lays the groundwork for true and positive ROI from the software.
Posted by Malcolm Ryder at 11:07 AM | Comments (0)
February 8, 2006
The Business Creation of IT's Value
Converting IT assets into Business Infrastructure
In determining the business value of IT, the challenge is usually stated as identifying how business results are attributable to employing IT assets. As Gartner analysts refer to it, the topic is "the value created by IT within a company."
How IT creates business value. That sounds like a well-defined problem. But when doing the actual calculating, it quickly emerges that such phrasing must be expanded and clarified.
For example, it can mean "value caused by technological means." That sends us immediately to investigating the idea of "causes". But meanwhile, saying "value" might mean only some results (targeted) among many; or it might mean the net impact after subtracting undesirable results from desirable ones. Furthermore, value need not always refer to business "results" because business opportunity is as crucial to the overall scheme of things as are results. Finally, business value need not be only one of these varieties to the exclusion of the others -- and it is certainly interesting to notice the relationships that exist amongst the different types.
I.
One type, though, does seem to have a lead. Given the permanently accelerated pace of change, preserving opportunity sounds like an indisputable top priority. Strategic studies will quickly point at the fact that IT is now critically important to even an acceptable baseline visibility of what is currently happening, while also being similarly critical to the making of what comes next. That one-two punch establishes IT as profoundly important even if measured only through imagining trying to "see" or "do" without IT.
With that consideration, we have a view on at least two value scenarios that are beyond debate.
One is that IT allows work to be organized into standing processes where otherwise the complexity of the environment and the organization would probably not allow. Clearly, the benefits of having a process versus not having one pertain to both the health and the growth of the business -- by providing for both scale and scope as well as both resilience and consistency.
Another scenario is related to the first but not in the most obvious way. IT assets are asked to pay for themselves, and yes, the basic way for them to do that is to enable business activities that generate income or reduce costs. But the reason why they can do that is not so much a matter of the automation they intrinsically bring -- rather, it is about "organization" that occurs due to management. This time it is not the work that is being organized but instead the work's sustaining environment. Not process; rather, infrastructure.
II.
The environmental impact of IT is driven by the business management's transformation (whether poorly or well) of IT assets into business infrastructure.
In this transformation, resources are central. A resource is an asset that has a job. The essential transformative event is when the asset gets an assignment. Value generation is engendered in the assignment. Thereafter, the actual "production" of value is a problem of capturing it from the assignment.
But the idea of "value" still refuses to settle into a single simplicity. On the one hand there is financial value, and on the other there is functional value. The two types are in the same class when we see them both (i.e., financials and functions) as economic impacts -- but they do not necessarily coincide. For example, selling something, making something, and consuming something are quite different paths to benefits, and the timing and level of their respective benefits are not necessarily going to resemble each other at all.
In accordance with that, the business always has at least two ways to identify a given resource. As a financial item, it is registered in asset management data (where it is simply called an asset). But as a functional item, it is registered in configuration management data (where it is called a configuration item). To be clear, it is customary to ensure that the item is registered both ways, but as we just recognized above, the one way's reasons are different from the other's.
Still, thanks to widespread but casual notions of return on investment (ROI), configuration items might confusingly be typecast as "property", and subjected as such to direct financial impact assessments. This risks ignoring the effects of the item's current functional influences, but most organizations have already made adjustments to this by classifying and comparing costs and benefits associated with the "use" of the item. Usually, that move is calculated to reveal how expensive is the financial commitment to the item. In the typical classifications, assumptions about the item usage are set out as benchmarked experiences, generally classified as expectations regarding "acquisition" and "maintenance" (including storage), and "performance" and "support". The fiction built into this is the idea that there are many different ways to hit the same given benchmark, making it only necessary to pick which way has the best price. But the reality is that each available way changes the likelihood of hitting the benchmark, not just the price.
Still, the story of the "expensive experience" explains the habit of thinking about resources as "financial assets" ...The problem with that habit emerges when managing assets to those benchmarks is found to be not the same as enabling the business for its needs.
The more important perspective -- which avoids that problem -- is one that looks at the continuous organizing of items into a system of business support. Because business capabilities are increasingly predicated on the functional impacts of IT utilization, the business potential in that system is the "core" value of IT. By analogy, the U.S. superhighway network was hideously expensive to produce, but the economy (economic productivity) that it enabled is almost incalculably more powerful than the best that could be achieved before the system was delivered.
III.
Despite that idea, the notion of "IT Value" is often still confused by a failure to identify the point of view from which "value" is being defined. But if the reason for the discussion of value is to express how IT leads to important results from business functions, then the key issue is how effectively the business exploits IT as a resource.
To further clarify this subject, we would first distinguish the IT "department" from the information technology itself, and investigate how the business manages to leverage the information technology not just through deparmental overview but as an overall enterprise-wide discipline.
This discipline inherently crosses a variety of contributing business functions, a fact that is sometimes dealt with through process or lifecycle models that track the organization's attention to IT-related business goals.
But the primary virtue of those approaches is their description of how the business affects and rates the conformity of the IT resource to target specifications -- where specifications represent the business's theory (proven or not) of what functionally causes affordability and/or success. Said differently, they both provide a sophisticated technical explanation of resource links to business requirements.
The development, continuity and availability of IT resources for business enablement should also have visibility separately from those models -- as a system , the point of which is to continuously generate and regenerate an infrastructure for business.
In attending to the resources, this view is complementary to those other models but not redundant, because:
- infrastructure may be specified, but the practice of realizing the actual infrastructure is always executing (and virtually competing) against complexity, uncertainty and change.
- Then, the business reacts primarily to the reality of that execution's impacts, not to the implications of its measured level of compliance to specs.
Managers have the responsibility of helping the business get necessary business performance from the realities, regardless of the quality of the infrastructure. The infrastructure may have a certain distinctiveness (as measured by its current compliance to specs), but "value" is by definition a distinction with a difference. If the distinctive infrastructure is not making a difference to the business, then it is not generating business value.
IV.
As a result, the value of managing the IT -- that is, of managing the IT realization of a business infrastructure -- cannot be understood only in terms of the scores for reaching various intended states of quality. Just as in a car, instrument dashboards are necessary, but even though they may be highly accurate, they don't tell you whether you are winning the race.
Instead, the value of the management (i.e., delivering a business infrastructure from IT) must be detected in terms of its being a competency that has a certain impact while seeking maturity.
That said, the relationship between impact and maturity should not be taken for granted. For example, immature innovations can have gigantic impact, while very mature abilities may provide no significantly greater impact when just replacing other mature abilities. Impact correlates with the circumstances in which the maturity of the ability is applied. Where our concern is with "business value", the circumstances in question are the business needs.
V.
In its economic and competitive environment, the business's ability to respond as needed is always its top concern. So, the fundamental question that must be asked is always the same: what difference does the business want the infrastructure to make?
In making the answer come true, management's responsibility is to organize IT in a way that promotes the currently requested difference.
Competency in producing an appropriate infrastructure for business needs is the real target of the infrastructure management effort. Programs, services and operations must assure resource alignment with business needs. Architects, suppliers and business unit execs must coordinate the alignment opportunities. The following picture maps the coordination:
This goal emphasizes a type of focus on resources that must strategically assure their development, continuity and availability -- three dimensions of capacity, affected by many quarters of the organization..
The basis of that strategic perspective on resources is an understanding of how assets and configuration items -- two views on the same environment -- together describe capacity for business responsiveness.
The basics of the concept are as follows:
- the working environment is populated by items
- the items group costs into investments
- the investments support production
- the production converts demand into valid opportunity for reward.
However, none of those points occurs as described, except by willful action of the organization. Each point involves a commitment to handling the items involved at that point. Each commitment is based on a financial aspect and a functional aspect of the items. The chain of commitments creates capacity from the items.
Protection against the risk of diminished or insufficient capacity versus demand is one of the dominant points of view that the business brings to identifying return on investment. This means that to understand where value in IT comes from, it is mandatory to understand where demand is coming from.
Demand, by definition, arises when needs are prioritized into requests for action. But need itself comes not only from business ambitions; external forces on the business challenge the ambition that the business has of itself and its future. To accomodate and solve those challenges, the business response must apply diverse but coordinated management perspectives to the way that its capacity can be translated into appropriate action.
Said differently, the business does not spend time questioning whether it should use IT. But it spends time questioning how to use IT well. In seeing IT as a business resource, solving the problem of responsiveness means addressing :
- where the resource comes from,
- how employing it is supported, and
- what mechanisms can ensure that it is in the right place and hands at the right times.
This is where the business view of IT resource must be translated from a user-orientation into a provider orientation. The user-experience of the resource, as provided through the processes, systems and portfolio of holdings, is interpreted into management action items that generate or regenerate the infrastructure. A representative general illustration of that translation (click here and maximize) shows the highly familiar components of IT management, oriented to the way business recognizes its opportunity to leverage IT capacity.
This translation is one major facet of IT alignment to the business, underpinning the business value of the IT. More consideration of that alignment, as seen also in the first diagram above (or click here), helps to appreciate how the overall adoption and effectiveness of IT as a business resource is comprised of:
- strategic resource development: managing sources through IT programs;
- transactional resource continuity: managing events through IT services; and,
- operational resource availability: managing states through IT operations.
VI.
But what makes this all "systemic" ?
The general principle is that if you remove one part of the complex, the rest will "fail". Experience tells us that the segmentation of responsibilities and authorities can create sub-organizations or functions that are protected against the disappearance or failure of other parts. However, we now recognize that same insulation as the origin of "silos" that prevent the difference necessary for the business from being drawn from the distinction that the silo maintains.
Regarding infrastructure, what forces this issue of interdependencies into prominence is the degree of change that characterizes day-to-day business. Change means that there is no perfect static infrastructure, rather only one that is "good enough" to succeed on demand before it must be modified into an equally successful new one for subsequent demand. Constant reformulation of the infrastructure introduces tremendous pressure on its real-time reliability for business.
Because of the range of demand that the business wants to accommodate, the options and opportunity costs associated with composing support for business responsiveness are in much greater volume and variability. This increases the likelihood that modifying one aspect of the resource management will have a significant affect (even if latent) on whether other aspects will be effective for meeting other demands. By analogy, that wrong-sized spare tire up front that gets the car back on the road also takes away the ability of the braking and steering to automatically synchronize; the turbocharger of the engine takes away the chance to use a regular grade fuel; and so forth.
Consequently, as demand management and change management become more and more critical to the ordinary reliability of the infrastructure, the notion of successful infrastructure must refer to something increasingly more dynamic, and the concept of IT's business value must embrace the opportunity created and preserved by agility as the first key value measure.
Posted by Malcolm Ryder at 9:05 AM | Comments (0) | TrackBack
February 6, 2006
Surveying IT Governance
The concept of governance in business is not an overly complex concept, but its implementation can be dizzyingly elaborate. Surveying it very broadly, we find that it variously and passionately refers to accountability, alignment or control. However, these references are not competing with each other but instead reflect the richness of the problem that we can summarize at an even higher level: "management".
I.
Ever since Frederick Taylor, the science of good management has been characterised by a small number of factors all related to the same idea -- demonstrable effectiveness of resource, or what sometimes is just as well called resource optimization.
In order to optimally utilize resources, a few critical success factors of their management always pertain:
- definition of their conditions (clarity)
- measurability of their application (certainty)
- direction of their effort (relevance)
Over the years, there have been many ways to interpret and discuss each of these essential scientific qualities of the management effort -- arguably none more persistently than accountability, alignment and control. Typically, different particular roles in the organization's community -- such as sponsors, executives, operators or clients -- host and promote different interpretations, according to the responsibility within their respective roles. But this does not mean that they are separated or indifferent to each other. All interpretations can be inspired by some of the same key business issues -- such as whether resources are economical and why; whether outcomes are improvable and how; or whether advantage is sustainable and where.
Nonetheless, particular blends of roles and issues bring distinct sensitivities, or perspectives, to the observation of the resource impact on business performance. When it comes to handling IT as a business resource, the perspectives interpret topics like economy, improvement and advantage by assessing things to be managed -- for example, characteristics of the IT resource inventory like supply, configurations, and distribution; or characteristics of the IT resource deployments like capacity, processes, or access.
Having multiple perspectives is a good thing. Any one of them will usually catch something of importance that the others missed. For the sake of planning, these "catches" bring up interdependencies -- for example between supply and capacity -- that affect or exemplify the logic of expected benefits versus risks.
Revealing such logic is a breakthrough. The collective effect of these perspectives is that through their sustained diligence, they bring a regular visibility to the dynamics behind whether the resource impact is:
- good or bad (preferred),
- intentional or unintentional (prescribed), and
- correct or incorrect (allowed).
Formally interrelating their sustained diligence, Governance brings those three "dimensions" of impact to evaluate and coordinate the state of the business operation. The effectiveness of that is largely in revealing and reminding that each dimension can develop ad hoc and/or independently of the others, but that they need to be blended into a compatible set of conditions for supporting business goals. Decision-makers and designers of all kinds throughout the enterprise quickly engage the views, because in particular those two roles must assure that the business value of the resources emerges systematically in operations.
In other words, the effect of IT Governance is to institutionalize the business management of IT.
II.
Emphasizing a proactive stance, it is easy to appreciate that this effort at "managed assurance" is most often projected as "control". Maturing the assurance effort into repeatable and reliable success strategies, practitioners have collaborated for years on organizing and sharing their learnings by creating frameworks that:
- memorialize and increase awareness of significant assurance opportunities,
- guide selection and decision of priorities and methods, and
- establish terms and conventions for monitoring and analysis.
However, behind these frameworks for success, there are varying nuances to the idea of "control", ranging from influence to facilitation to command. Meanwhile, particular roles and circumstances generate a variety of individual business needs. Together, as opportunities and catalysts, these nuances and needs have combined in different ways to spawn different frameworks that all continue to be cultivated.
Over time, different frameworks can each grow out to a point where they overlap others; but if these frameworks are to provide reliable guidance, their overlaps need to be reconciled to ensure that the various frameworks do not work at cross-purposes, despite the intensity and complexity of how elaborate they may become.
Before worrying about that, perhaps there is an even more pressing problem in the organization: a seriously imbalanced mix of individual control efforts already actually implemented for the many aspects of IT activity that ought to be governed. Today, that imbalance may feature incompatible, inconsistent and/or variously unsustainable approaches - in which much of the organization is already invested financially, mechanically or politically. Aside from choosing and trusting a framework to make sense of that variety and envision "leveling it out", there is the substantial pragmatic challenge of herding the cats.
The current wisdom on attacking this problem is that governance should be instituted "top-down" in the organization. A key virtue of that approach is that it minimizes the chance that adopting governance will suffer a "two steps forward one step back" syndrome, because authority and accountability are more rigorously enforced.
But a key challenge in it is that governance itself must be done in the service of the type of progress that the overall business needs. DIfferent parts of the organization contribute to progress in different ways. And different organizations often need to make different kinds of progress.
This throws attention towards the idea that IT governance should not be one-size-fits-all. Put differently, IT governance should not be just a set of "controls that makes alignment for business accountable" -- rather, IT governance must be a competency that demonstrably solves the right business problems.
III.
One key to demystifying adoption of practical IT governance is to first see, in more generic terms, what it is that is being addressed.
We have the range of carefully labelled starting points including "control by" certain parties; "accountability to" certain parties; and, "alignment for" certain parties. But while these may indeed indicate the particular involvement of different roles, the first thing to consider is the commonality of their interests.
Much of the commonality can be expressed and contained through explicit policies and rules. These share the ability to consistently regulate decisions about real-time events -- and it is vitally important for multiple co-operating stakeholders to draw confidence from that. For most organizations, this issue of aligning all decision-making and production design to some standards is the major driver of adopting IT governance. It is a direct response to the need for reducing the "collateral damages" of the organization's complexity -- such as operational costs, errors and liabilities. In effect, standards or regulations represent the party for which the resource utilization is aligned. In the abstract, this party might just be be the "desired future version" of the current organization. In the concrete, it might be a customer, sponsor or other (like the government) stakeholder who has enough immediate influence on opportunities or constraints to be able to dicate the terms of operation. Here, for example, we see Sarbanes Oxley, ISO9000, CoBIT and other directives in force.
Likewise, consistency results from adopting widely-proved guidelines for essential management practices. While "best practices" are propagated because they correlate with successful outcomes, the true value of adopting them is that they include the highest degree of validated measurability -- which translates into predictable improvements in manageability. As such, they need not replace already-successful measurement-based management -- but for managers under excessive pressure from complexity, they accelerate the implementation of low-risk comprehensive measurement. Here, for example, we see ITIL, CMMI, and other instruments featured prominently.
But despite the meaningful differences between those distinct example directives above, they all have the same practical goal: managing the business's preferences, intentions and allowances regarding resource selection and deployment against demand.
This practical commonality doesn't make the challenges easier, but it reminds us that an organization's existing abilities and initiatives for those same management tasks should be pointed at the impending or mandated policies, standards or guidelines. Why? Not just as enterprise housekeeping but, recalling the primary management theme of effectiveness, so that business progress is more strongly enabled. Before that re-orientation is done, we don't know what else new is necessary.
IV.
With the more generic overview in place, it is easy to appreciate the scope of reasons and benefits usually described within the initiative for IT governance.
"IT governance is an integral part of enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization's IT sustains and extends the organization's strategies and objectives." As seen on its website, the IT Governance Institute (ITGI, at www.itgi.org) continues that introduction to IT governance with a short checklist of things that governance must cover:
- ensure that "IT is strategically aligned with the business and delivers value, its performance is measured, its resources properly allocated and its risks mitigated."
The scope of coverage indicates that the business reliance on IT requires broad organizational accountability. This makes sense particularly in the sense that the business is a customer of IT. But the nature of the actual governance problem is better suggested by the idea that IT utilization is aligned for business. In this latter sense, business is a function, and as the format and value of the function changes over time, governance must deftly support realignment of IT utilization for enabling and supporting the function.
In other words, without diving down into the weeds, this functional outlook gets more directly to the matter of how governance accomplishes what it should accomplish.
As a high-level frame of reference for thinking about governance, the following idea makes a basic assumption about the business's "return on management" -- namely, that managment is given the day-to-day responsibility to take the organization from the current state to the "planned to be" state.
In order to do that, management must generally focus on achieving clarity, certainty and relevance of the resources it handles. But it must specifically focus on influencing resource impacts by wedding the clarity (definition) to the utilization. We tend to think of governance as being about "how things are done," but the closest examination of what we mean by that shows we are more considering "what things are done". The decisions about those things tend to focus on whether they are appropriate, and on what they require.
Consequently, the crucial work of coordination that governance can execute revolves around managing in terms of the "As Intended" Definitions of resource utilization. These are covered in three broad areas that hierarchically comprise the value chain for resource utilization.
Top-down, the business value hierarchy is:
Value: Objectives and Portfolios that align resources to needs
Fit: Architecture and Standards that align resources to requirements
Quality: Assets and Projects that align resources to purpose
As a result, we can see the parallel impacts cascaded (top-down) as well:
- Performance;
- Risk; and,
- Capacity.
Understanding governance from this high-level functional perspective has three major advantages.
1. It is less confusing as to where and why issues such as costs (financial controls), mechanics (processes and support), and politics (decision rights and organization structure) fit into the scheme of things.
2. It also becomes more obvious that the uniqueness of any organization -- which is readily detectable at the level of costs, mechanics and politics -- in no way divorces it from the general opportunity to govern IT effectively in accordance with general principles.
3. Finally, it is more apparent that the multiple roles in an organization can identify goals and opportunities to collaborate on improving existing governance capabilities incrementally, while not violating the interest of a top-down view of enterprise-wide consistency.
IV.
Governance practitioners and supporters take advantage of the last point above. Their challenge is to figure out where to plug into governance, and why. This shows up on both the "supply" side of the it industry and on the "demand" side.
For example, Microsoft focuses on operational excellence, yet to establish a business case for its solutions it talks about three things to consider: save more money (deployment), make more money (productivity) and keep more money (efficient support). These benefits, to be produced with Microsoft functionality, come with legal and financial restrictions on the availability of Microsoft technology, and corporate stakeholders (both internal and external) place further boundaries around how production is allowed to generate the benefits. Governance, through its frameworks and models, is instrumental to connecting the allowances for supply and capacity to the allowances for production and impact. Decision-makers and production designers must actualize the recommended connections.
On the demand side, distinguished practitioners such as CIO Emeritus Len Tenner of Hewitt Associates caught what might be the single most important observation about IT governance, as introduced by authors Peter Weill and Jeanne Ross in their book "IT Governance". Said Tenner in his recap: "effective firms must customize IT Governance to match their organizational approach and business goals."
But this just reminds us that the hands-on challenge of doing IT Governance is for the organization's leaders to define, produce, deliver and support governance itself -- an ongoing, multidisciplinary, cross-functional effort at developing and maturing a competency.
Certainly not the last definition of that competency, but a pretty exemplary one, is from deep inside an office in a department of a non-profit organization whose success is also increasingly reliant on effective IT:
"IT Governance - A structure of relationships and processes to direct and control the enterprise in order to achieve the enterprise’s goals by adding value while balancing risk versus return over IT and its processes." (Austin Community College Internal Audit Office)
The message in offering that citation is that the phenomenon of IT Governance is not about an industry, a business model, a market segment or a product, and not even primarily about technology. Instead, it is primarily about a management discipline focused on a business resource.
The involvement in IT Governance must be championed not by "business people versus IT people", nor by "executives versus producers", nor "auditors versus employees". Instead, it must be championed by managers at all levels of the organization.
Posted by Malcolm Ryder at 3:06 PM | Comments (0) | TrackBack
January 13, 2006
A Brief Survey of Gain
Why is it so often the case that when you get what you asked for it isn't what you wanted?
The easy answer is probably the correct one: you didn't ask for the right thing. Setting aside all matters of blame, the more important two points to consider are:
(1.) Why did you ask the way that you did? and...
(2.) What other way might you have asked?
An especially strong focus on this situation comes through using a portfolio manager. The amazing advantage of a managed portfolio is that it (normally) contains within it the logic that explains two things:
- how it is that what you ask for turns out to be what you want, as well as...
- why it makes sense to want what you need.
I.
Anyone raising children should be able to immediately appreciate the profound difference in the house that would occur if their kids had those two habits! And joking aside, this is really to the very point of portfolios: they implement maturity in the perspective on investment and gain.
A major ingredient of this maturity is the ability to distinguish different levels of commitment and expectations, and to logically match up commitments and expectations, consistently.
We can readily see this in the language that is typically used to describe events and conditions related to expectations and commitments -- but the irony is that in the heat of action we often lose our bearings and mismatch them:
One immediate "finding" from looking at the vocabulary is that it's a good idea to not confuse expense and cost -- and likewise to not confuse value and worth. By looking at what each of those items "will give" (third column) we can see that there's a difference and that one must ask for the right thing.
Our vocabulary chart seems to have a lot of redundancy in it, but one of its main points is to show that in a given situation we might easily think about gain in one way yet do something about it in a different way. What's the difference between why (before the fact) we pursue something and how (after the fact) we evaluate it?
II.
Another problem lies in potential confusion of what kind of commitment is being leveraged to serve the current purpose. Let's look at expense versus cost. What if, under the purpose of offering products or services, we're asked to "hold down cost"? That's not the same thing as being asked to "hold down expense".... Is something that is expensive necessarily costly? We can start to see in the vocabulary that the answer is "No" -- because the acquisition allowed by an expense might be something that greatly increases benefits, through ownership, and the benefits may be redeemable to lower overall cost.
Example: a person finds that a better car that is more expensive has reliability that, by allowing safe and flexible commuting over longer distances, increases opportunities to work for more money, which in turn can be used to lower outstanding debt or otherwise come to a better net balance. The reverse: a very inexpensive car has bad reliability, spends too much time not working well, and poses frequent risk and other limitations to reaching and keeping better work. Worst case, losing the job might also mean losing the car. In this latter scenario, "inexpensive" turns out to be pretty costly.
Such relationships start us thinking up the chain from expense to worth. How do we drive "good" value with cost? How do we drive "good" worth with value?
III.
On that point, what is the difference between worth and value? Simply defined, value is "a significant difference". But what is significant to one party or situation may not be to another. Worth puts the value in a context. Something may increase in value, but is the additional value producing high-priority benefits?
Example: a product or process might improve, but if it is not being used any more frequently by any more people then its additional value is not worth much. Different example: a party is trying to prove that a new approach is viable in a task; here, if the task outcomes show the slightest bit of improvement over the usual, that validates the approach, so that tiny increase in value has tremendous worth.
These are ideas that are not so much unusual or even news to us. Instead, the problem is that we often allow our familiarity with them to be sidestepped by decisions and actions that for some reason prescribe to notions and expectations that are not nearly as logical.
IV.
Observing a more rigorous vocabulary helps to clarify thinking. For example: if we think we need something to be valuable, we should know that what we are after is some kind of impact. This impact may or may not have anything to do with expense. But the point is that pursuing greater value does not automatically necessitate lowering (or raising) expense -- so we shouldn't expect expense to adequately talk about value. In some instances it might work out logically that expense will be a key factor of the opportunity to increase value, but that would be determined as a characteristic of the particular occasion for value-pursuit, not taken as a default principle of generating value. (Question: what does budget-compliance tell us about whether operations were effective? Answer: if anything, not much.)
Other scenarios as well should be more carefully understood. For example, can something that is very costly also be very worthy? Sure -- this is characteristic of the response to many emergencies, and in those cases it probably is true because whatever is very costly is also sufficiently valuable. On the other hand, we don't want everything to be an emergency, and it makes no sense to impose an evaluation system for emergencies onto non-emergency situations. Yet meanwhile, one situation that is not an emergency but is simply relatively "extreme" is common in the marketplace: it involves super-costly products (like the highest-end street-legal cars or virtuoso solo pianists), which virtually create business that otherwise would not exist.
Naturally, this thinking must also address ROI (return on investment).
Looking at the vocabulary chart, we see the left-most column naming commitments that "pay back" in accordance with objectives listed two columns to the right. When commitments are made , "returns" should be represented by the benefit provided towards the objective.
There is no special reason why the objective should ever be displaced as the reference for assessing the effects of making the commitment. However, this involves more than the benefits.
Following through with a commitment introduces other issues that, if tracked and weighed, might have characteristics that discourage or encourage a decision to make that same commitment again in the future. Knowledge of similar previous experience -- even that of other parties -- could have the same influence. It might therefore be that the "burden" experienced in certain commitments would compete with the basic objective in the process of justifying a decision to commit. The burden might set tolerances or precedents that must be forecasted and addressed "satisfactorily" before the follow-through is allowed to commence. Over time, attention to these "qualifiers" can dominate the perception of certain types of commitments -- especially for those that are recurring ones. A symptom of this is when the attention to the commitment is more about whether, compared to "the last time" or "usually", it is expected to be less problematic or moreso.
The execution of the follow-through to the commitment is a serious subject, but it still should not substitute its performance issues for the real objective of the commitment. If it does, it distorts the calculation of ROI.
V.
Instead, the objective is supposed to represent that a certain need has a sufficient priority to mandate supporting execution. The delivery of benefits to the objective should be assessed in terms of how much it helps the objective.
There may be competing objectives, however, and a limit to the overall capacity to address them all. So the correct way to approach things is to first decide whether the particular need is, at this time, really one that should be addressed -- and secondly, how aggressively it should be addresed.
In a portfolio, the corresponding move is to include or exclude investment categories in the portfolio. A category (which represents a need) has an objective, and investments are made within the category to help achieve the objective. Within the category, some investments made are better than others, from one time to another -- having to do with how effectively the selected sources of contributions to the category are executing as contributors.
By careful selection of contributors to carefully selected categories, we set up production of benefits that achieve objectives. But as cautioned in the vocabulary above, we need to be clear about what it is that we are really after, in order to ask for the right thing to make it happen.
Posted by Malcolm Ryder at 9:47 AM | Comments (0)
January 7, 2006
Execution as "Progress": The Four Types of Value in Performance
Here's an odd thought: if "execution" didn't change anything, then we wouldn't have to do anything to get where we want to be.
We just might not have any idea of when we'd get there.
But to know whether execution matters, it's mandatory to accurately determine whether progress is being made towards targets.
Experience has shown there's more to the problem, though: the target might be reached, and reached in the prescribed way, but the impact of that achievement might still not make the difference that was actually needed from the execution.
For getting the big picture of what matters, the most important issue is to know whether the right targets are in place. Having the big picture means knowing that the efforts thought to be "progressive" are solving the right problem.
I.
"Progress", a measurement of performance, is the concept that drives most management decisions about whether execution is "effective".
In practice, a target level of achievement is set, and "performance" pertains to the actual level obtained as measured against the target. Management continually adjusts execution to approach the target.
What a target really represents is a threshhold of change at which some necessary value is expected to be obtainable or obtained.
In other words, the target points to a working hypothesis of what kind of conditions need to be altered in order for the performer to intentionally arrive at a desired future state.
Granted, when things are going well and execution is usually reaching the target, the mentality about conditions is not so much that they are being "changed" as simply driven... Nonetheless the true importance of the target is that it originated in an awareness of some unwanted (if not harmful) condition that would likely prevail unless an effort was being made to change it for the "better"... That awareness is, after all, the motive.
But targets have a funny way of suppressing (or replacing) our memory of that baseline.
And from that point, the means go on to grab attention. Both the specific form of effort and the mode of the effort are variable factors in bringing about the change.
- By form, we mean the manner in which the effort practically incorporates the capability of resources and actors. For example, automation and manual labor are different forms of effort.
- But by mode, we mean the general but characteristic strategy of alteration being pursued by the execution. For example, persuasion is a different mode than force; gambling is a different mode than saving.
A forgotten motive and variable means can make the message in measured achievement deceptive. How does the performer know that the results this time are, through the same means, repeatable and relevant in the future?
II.
While measured against targets, execution is typically monitored in terms of actions versus requirements. Usually the actions are accompanied by attention to their associated risks and rewards. Management makes discretionary, circumstantial decisions based on tolerable balances of risk and reward.
But when we understand that the essential problem for execution is to change conditions, we can understand execution decisions more strategically -- as a matter of connecting choices (e.g., of resources, operations or relationships) to needs (which are what sets the context for strategic value).
From a strategic value perspective, we describe "progress" as being the satisfaction of need.
Thus, in considering the value of performance, one of the first key questions to address is, "what type of need is the desired future state presenting?" Getting the need properly defined must precede decisions about how to execute.
Then, needs are met through changes wrought by execution.
III.
Here we must look at the business as a performer, and at a way to generalize the concept of "needs" into practice.
The performer has four basic ways that it can address the environment in which it operates. These ways -- or modes of progress -- are used as working categories of opportunities that the performer thinks it must have in order to arrive at the desired future state:
- transform itself (e.g., transcend the environment)
- comply itself (e.g., match the environment)
- exploit circumstances (e.g., master the rules), or...
- adapt circumstances (e.g., change the rules).
Put simply, execution has no value per se, but instead is responsible for making those four things occur, whichever of them is selected as offering the best apparent likelihood of reaching the main goal.
IV.
In making that selection of what to execute for, we factor in necessary capabilities, thinking about the two basic ways that anything influences an intended change -- as either an inhibitor or a benefit.
What we want to be able to see is how different circumstances would inhibit or benefit the change needed for gaining the desired future state.
On the one hand, the means of execution are circumstances that will directly impact the intended change, so visibility of means is important to describing how the execution effort gets to create value.
But due to management, the most immediately significant circumstances around the execution effort are dictated by an objective that is attached to (and justifies) the effort. For example, supervision, resourcing, support and approvals are all aligned around the effort in order to make it bear directly on the objective successfully.
Speaking at the highest level of generality: when the purpose is to "improve" on a current state, the business as a "performer" has at least four objectives to work with.
For pro-actively generating value from the change-effort, the performer might...
enforce these:
- regulations (esp. involuntary); and/or...
- standards (esp. voluntary);
and/or develop these:
- modifications (incl. discretionary), and/or...
- new options (incl. contingent).
Generally, these four approaches tackle what are initially constraints on the current state. But they may be pursued with a special understanding -- namely, through execution the constraints can be exercised as opportunities.
That allows us to see the constraints as success factors for progress, but we have to answer the question, "for what kind of progress?"
V.
Answering that question, the framework below first assumes a "worst case scenario" about change, which is that change is usually going to be ad hoc, arbitrary or chaotic, unless explicit management is applied to it.
Considered against that assumption, management can generically distinguish each of the four approaches to execution. Each approach has a characteristic "default balance" not of risk versus reward but instead of inhibition versus benefit that it is expected to contribute to the performer's intended change-effort.
Through their typically lower or higher contribution of inhibition or benefit, the four approaches are positioned relative to each other in the framework. With that done, the illustration also maps them to the four basic modes of progress (i.e., types of value) available to the performer. In doing that, it suggests that each different approach "naturally" makes a contribution to certain types of value.
Likewise, certain approaches appear to be more appropriate to or successful for certain kinds of problems, while less so for others.
For example: If the performer can decide that the desired future state requires transformation, then "regulations" are less likely to be the place to look for key solution elements. However, transformation requires low levels of inhibition. And "modifications" are significant to transformation, while "options" are more aggressive.
The main purpose of this framework is to illustrate a mentality that allows logical analysis of how execution and value are linked. For certain managers or organizations, the details such as the four proposed modes of progress or execution approaches might be debated or even replaced with other items more closely matching their experience. But the most important management consideration with an overall view like this is that execution is in fact establishing a type of value that is truly relevant to the desired future state.
VI.
Supporting the desired type of value with execution comes with one other wrinkle. Each quadrant of the above framework offers a constraint to convert into an opportunity, but the conversion itself has a "default" or generic quality, which characterizes the quadrant's different approaches as follows:
- upper left: "conservative"
- upper right:"ambitious"
- lower left: "statutory"
- lower right: "radical"
This observation would be just a footnote, except that often the approval of execution plans is dependent on the political climate, habit or other tolerance that decision-makers have for certain styles of pursuit. Those issues could improperly insert themselves into the situation as the main reasons for "why" something should be done -- displacing the value proposition that identifies the performer's real goal or what outside observers would call "real progress"...
As a result, properly managing performance must include an aspect of assessment that first objectively describes the logic of the selected approach in terms of the value-goal, and only afterwards describes the feasibility of sustaining the approach. In that way, the most opportunistic or emotionally desirable approach might even get ruled out, but it is always more likely that the correct approach will be identified regardless of how difficult it is to execute. At minimum, this will prevent costly commitments to solving the wrong problem.
Posted by Malcolm Ryder at 6:49 AM | Comments (0) | TrackBack
December 13, 2005
The Value of Being In the Know
Imagine trying to create value without being knowledgeable. Not good. But how do we know what value the knowledge creates?
I.
FIrst let's go to a working definition of "value", to tell us how to consistently recognize when value, instead of something else, has been created.
- value: the significant difference that is made by a distinction.
This generic definition is important because it is portable and unchanging across different kinds of situations. However...
In any particular situation, value might be created in a variety of ways. Its two key parts -- significance, and distinction -- can exist independently of, and prior to, each other. This allows some complexity:
- a single distinction can be significant in multiple ways, but not all of those ways are necessarily relevant to a given stakeholder. And...
- there can be more than one way to get to the given significant difference; not all ways are necessarily tolerable or practical at a given time and place.
Thus, the two parts can have a many-to-many relationship with each other, which means their combinations can vary and thus generate value in many diferent ways.
We'll have to sort through that variety when assessments roll around. We should objectively identify different kinds of values. Then, based on relevance and practicality, we can determine what kind of value might be most within our grasp, but finally we also have to decide how much that kind of value means to us and why. This separation of "value" from "worth" is the precision awareness provided by an assessment. The assessment helps us think through potential values in terms of worth, and ultimately we'll commit to the most worthy values.
As an example of concern about "what value is meaningful", companies considering taking on knowledge management (KM) are commonly concerned about the economic impact of KM's value. If KM is valuable, they want to know how and why, with regard to that specific impact.
In figuring it out, we have to start with "how" the value of knowledge can be recognized.
II.
One approach to identifying what value knowledge creates is to first state the desired type of value and then apply knowledge in situations that logically should drive that type of value creation. If applying knowledge produces a measurable change towards the desired value then we attribute that value to that knowledge. An example situation would be "problem-solving". Here, we know that we want a solution and that getting to a solution is a multi-faceted issue. Measuring the effects of applying knowledge might yield findings such as:
- solution obtained much sooner than otherwise has been the case
- solution obtained with greater efficiency of required resource consumption
- solution obtained where previously there hadn't been one obtainable
In fact, "faster, cheaper, and prettier" are very reasonable terms by which to measure the effects of applying knowledge. They typify agreed notions of value (i.e., significant difference) that people already know what to do with.
This is an approach that is compatible with "accounting" -- at least in the sense that it describes tangible results correlated with the level of effort invested and consumed in the situation.
An approach wholly different from that, however, is from the other direction -- where applying knowledge appears to predictably, and even reliably, cause changes, but the significance of the changes is undetermined. Here, the problem lies in not understanding what to (literally) "make of the change"...
When applying knowledge has effects of indeterminate usefulness, the accounting perspective does not help to identify and manage a recognizable value. Accordingly, we need another view -- one that perhaps introduces previously unseen useful effects to accounting, but at minimum discovers the usefulness of previously unobserved effects.
III.
In the latter case above of knowledge-driven changes, management has a special problem: we need to determine whether applied knowledge has re-organized conditions in a way that provides a different set of opportunities and risks than what had previously been established -- not just a different level of preconceived value. The more important the new opportunities and risks are, the more valuable we can say was the knowledge involved. But as with any change management, we need to determine whether the knowledge-driven changes are the "right" ones -- and whether the value is a kind that we really want.
One practical way to recognize this issue of reorganization is through the idea of "technique". Technique organizes the way things are used in action. In practice, acquiring good technique is the same issue as being "trained" (reorganized) to a point of better functional capability. The two most important aspects of technique, making it a target for adoption and improvement, are that (1) it provides an operational advantage against stress, and (2) the means of that provision are sustainable. These are compelling differences to attribute as value.
Technique organizes the way things are used in action -- but so does a "process". So what's the distinction there?
Technique is to "process" as Policy is to "approvals". Approvals define the selection of permissions, but policy defines the logic of permissions according to prevailing conditions. Likewise, where process defines the selection of connecting actions, technique defines the logic of actions according to prevailing conditions. A process that amounts to bad technique is no more tolerable than approvals that amount to bad policy.
Most oganizations today can think about technique by thinking about "best practices", contrasting that against what might be considered the "best procedures" world of processes and rules.
But if we take the example of best practices and investigate it for its contribution to value, much of what immediately comes to mind is the view from the opposite direction -- that is, practices which are not "best" are inhibitors or liabilities that we want to remove. This helps to focus our attention more on the aspect of protecting "opportunity" and on how opportunity is maximized or minimized under the pressure of demand.
Now, we see that Opportunity can be set alongside Operation as a second critical perspective in assessment. Where assessment of operations deals with progress, assessment of opportunity deals with potential.
- Potential represents the degree of protection provided for an opportunity to obtain the desired impact.
- Progress represents the degree of achievement in realizing the potential.
Accounting typically examines Operations for progress; but value assessment also needs a mechanism that examines Opportunity for potential.
IV.
Before beginning that opportunity examination, we must be careful to furthermore separate "opportunity" from "objective"...
In practice, objectives are usually identified and promoted specifically to represent the perceived or desired endpoints of paths -- paths seen as "opportunities" that describe the potential for reaching a goal. The paths have been conceived for the purpose of meeting the objectives.
Managing operations focuses on moving things along those paths; but covering the known paths is more about performance than it is about value. Meanwhile, accounting is heavily performance-oriented. It wants to discover and explain "progress." It expects knowledge to stage and promote progress by changing operations to realize the potential.
In contrast, managing opportunity means path-finding and path-determination, which comes from strategy. Strategy is heavily value-oriented. It is mainly about finding and validating the paths where potential is first created. It expects knowledge to stage and promote potential by changing opportunities to realize the desired impacts.
Thus, in the defined opportunity produced by the strategy, we see the definition itself as the "significant difference" and therefore attach value to it (separately from any pursuit). Then, we have to weigh the opportunity's significance to the objective, independently of weighing the importance of the objective itself.
For example, we may see the strategy as the map to success. Following the map will still be a critical constraint on achieving the goal, but the requirements for following it (i.e., progress) should not be mistaken as the criteria for weighing the importance of the strategy's value (i.e., potential).
- Instead, the strategic opportunity must be relevant and viable, and considered against alternatives.
- Meanwhile, regardless of the importance of the objective itself, if the opportunity is critical to the objective then by definition the opportunity has great weight.
V.
The map that strategy creates is a highly valuable asset even before we start to actually follow it. We want knowledge to do two things: to make us better map-makers; and, to help us make better maps.
Those differences indicate yet another key to assessing the value of knowledge -- namely, to distinguish "intellectual assets" from intellectual behavior. Knowledge changes both things, so they each are dimensions of knowledge influence, affecting both operaions and opportunity. Additionally, they affect each other.
Managing assets and managing behavior are not the same activity, but with valuable assets such as distinctive ideas (like strategy or procedure), we naturally also want behavior that improves and leverages their value.
For example, we want high performance in compliance to a valuable procedure -- which makes that behavior itself valuable. But that sense of behavior should be understood as "skill".
Intellectual behaviors such as analysis, decision-making, and invention are also coveted skills -- but they make their distinction, and ultimately their value, in their ability to create and modify important circumstances and intellectual assets.
If we say that we can apply intellectual behaviors and intellectual assets to a situation, have we covered the bases for saying that we have applied "knowledge"? Not quite.
Under the pressures of demand, an organization's assets primarily represent its capacity while its behaviors represent its competency. But in our overview of knowledge, a third and final dimension, joining intellectual assets and intellectual behaviors, is what we might call "intellectual predispositions" -- which brings preferences to join capacity and competency.
Now, with those three dimensions of knowledge influence, we can begin to catalog the types of differences that we want assets, behaviors and predispositions to make, and in that way list key terms of assessment. We can cover opportunity comprehensively, and we can also "backfill" issues frequently ignored about operations.
Amongst our catalog of differences, we must also have clarity and confidence about what final impacts we really need, and then about whether the contributions of the assets and behaviors (capacity and competency) are actually supporting both the progress and potential towards the target impact.
If our key objective is maximum positive economic impact, the challenge will be to distinguish how knowledge drives economically significant progress, and how it drives economically significant potentials, related to the desired ultimate impact.
We'll especially want to understand how knowledge helps our progress, potential and desired impact to align with each other. Or else!
The fact is, we could do a bang-up job of executing on differences that don't really matter amongst our goals and priorities, yet still affects our economies -- for example, perfecting compliance to standards that don't solve our problems.
And highly potent value can be created that doesn't have much economic impact -- for example, a well-executed product perfect for only a very tiny market.
What will emerge, though, is that the interrelationship of these issues is not strictly linear but instead is interwoven -- more of a network of influences than of a chain. Managing assets, managing behaviors and managing predispositions each have their own way of affecting progress, potential and desired impacts. But the way that knowledge affects one dimension also affects the others, which changes their alignment. In that way, managing knowledge value is a lot like managing a network.
VI.
To envision the scope of interrelationships in the alignment, consider the following.
This matrix is one way to describe how knowledge influences alignment. Here we see the representations of numerous familiar business instruments that are directly related to knowledge and that in turn are distributed to shape operations, opportunity and objectives. Our familiarity with the items in this view also lets us see more readily that changes in one place can alter the support, status or direction of another place in the picture.
Managing knowledge will include managing the making, certification and purposeful utilization of it at each point in the matrix. But through our familiarity with these instruments, we already recognize that the point-to-point connections are vital to the health of the business effort. Given that, managing knowledge value comes in when we know what difference we want the knowledge to make at each point, and how those differences relate to each other.
With things put that way, it's easy to say that at all points we just want knowledge to make things "better".
But better should mean that they become more reflective of the target impact while improving the way they interrelate. For example, a faster, cheaper or prettier way to do something is better if it keeps or increases the level of support it offers to other factors that depend on it. Otherwise, diminished support can easily make the other factors riskier and likely more costly. The sensitivity to this is typical of taking a portfolio management approach rather than an accounting approach. What we're working with is the "knowledge portfolio"...
VII.
From here we can begin to sum up how knowledge is valuable.
Our matrix has a left-to-right connection of three perspectives: operations, opportunity and objectives. As management modes, what forwards knowledge influences from operations through to objectives and beyond is technique, strategy and purpose. We readily recognize this in certain management artifacts:
- Earlier, Best Practices (through technique) was an example in which the influence of knowledge on operations was directed in support of opportunity.
- In like manner, Planning represents strategy's bringing knowledge influence on opportunity, with which we would likely support objectives.
- To that, we can add that an organization's Positioning represents the knowledge influence that purpose has on objectives, which we use for supporting stakeholders.
Together, the three things illustrate the organization's competency, capacity and preferences systemically establishing themselves -- three characteristics that we already know are criteria in economic justifications. These characteristics are also recognizable thematically as in the examples within the picture below:
Meanwhile, vertical linkage in the matrix connects the three knowledge dimensions. Looking back at the cycle of leveraging knowledge value under demand, we saw a picture that corresponds to these dimensional links: predispositions should direct appropriate behaviors; and in turn, behaviors should produce relevant assets that communicate and transport capacity from one time and place to another in the organization's experience.
In that picture:
- intent is a source of conditions;
- form is a source of content; and
- function is a source of capability.
Knowledge affects the measurable conditions, content and capability of the organization -- characteristics that we already know are monitored for the economic impact of their use. Overall, the cycle addresses the question, "of the things that we want to do, how do we get them done?" This explains why improvement initiatives focus on investment, refinement, and redeployment in those three areas. While those initiatives typically look to business "intelligence" as a primary means of gauging the importance and progress of the efforts, we saw that "knowledge" is more instrumental to shaping the actual changes that the efforts make. In other words, that is why knowledge is valuable.
VIII.
One of the key challenges to working on improving the value of knowledge is to assure visibility of why certain kinds of knowledge is appropriate in given situations. In general this is thought about as "expertise", but in an important way that misses the point. Along with information overload, an organization also has a degree of complexity that often obscures the reasons why knowledge is available or not in given circumstances. Automation certainly tries to address this problem by minimizing it risks. But behind that automation should be a visible logic of knowledge management that corresponds with the assessment matrix and alignment cycle we have now seen.
As a closing explanation, but one that is a work in progress, the following picture identifies that knowledge is more likely manageable when its form and function aspects are more visible. This visibility helps to begin the process of optimizing the current knowledge deployments into a configuration that, as outlined by the discussion above, will more systematically support programs for increasing their value.
Posted by Malcolm Ryder at 12:18 PM | Comments (0) | TrackBack
December 6, 2005
The Value of Performance Pt. 2
One of the general ideas that help to focus management properly on the business effectiveness of operations is the principle that the overall "throughput" of operations goes through different planes of impact, and that "performance" on one plane generates "value" on the next level up.
In that case, optimizing operational throughput calls for visibility based on an architecture that consistently represents the most significant planes.
I.
Here, "significant" refers to having a structural role in organizing the business's capability, regardless of the current frequency of events and interactions in that role. For proper managerial visibility on throughput, we need to know that any plane on which a critical impact is measurable is "in the picture" whether it happens to be eventful at the moment or not.
Making a key structural difference means that the plane is literally "critical". In creating the big picture of all planes, the challenge is always to take the overall construction of the organization that is hosting the activity, and to identify where within it the meaningful logical separations exist.
To do that, we must see that each separation is really a "boundary" -- on either side of which events may occur independently of those on the other side, yet also influence the conditions and/or events on the other.
Those facts, and how they mix, are what makes it so difficult to determinea proper segmentation of planes. Add to the challenge that the strength of influence across segments may be variable, and the influence may be direct or indirect.
However, against those complexities, a hypothesis can be tested through monitoring for correlations of events and conditions. These correlations will represent performance and value.
- In general, performance is a measure of how closely execution met a target achievement level under demand. So for each plane in the hypothetical architecture a signature achievement must be defined.
- Meanwhile, received value generally refers to the significance of the difference made by the impact of a supporting event. Thus, for each plane, a characteristic significant impact must be named.
Here is one top-down hypothesis of the main planes of throughput (and hereafter let's call the planes "layers"), :
Linking the target achievement of one layer to a "significant difference" on the next higher layer will decribe how performance on one layer generates value on the next higher. To do this linking, the first layer's achievement level must be associated with an impact registered on the higher layer.
Typically, the association is defined as follows: achievement on one level must be an important event on another level.
II.
Interdependencies define the prospective relationship of performance and value across the layers. The question is, how important is the achievement on one layer to the impact needed on another?
That analysis of throughput must address that question, thus leading to design of throughput that proposes and timely implementations and their adjustments. Measurement systems should focus on monitoring and validating the specific conditions, changes and consequences related to the throughput design.
In general, however:
- managing the stack of layers bottom-up is about " access" -- such as the availability of an asset as a resource, the availability of a resource for a function, etc.
- moving top-down the stack is generally an issue of "quality" -- such as the suitability of the business process to the business function, or of the business service to the business process.
This suitability is not the same as "compatibility". Instead, suitability refers to whether a given layer generates the type of impact needed by the higher layer's characteristic distinction.
III.
But again, influences across layers may be direct or indirect.
For example, M. V. Sarma of the consulting firm CSC gave the following definition:
Business Service Management - – Defines the performance of IT services in terms of business value, such as revenue, cost, risk management, market share.
If we parse this a bit, we can restate it in saying that the "values" for the business (i.e., the needed distinctions) are
- increased or sustained revenue
- lowered or controlled costs
- minimized or contained risk
- increased or protected market share
The related "performance" of IT services is not equal to the business value. Rather, we remember that value is always "a distinction with a significant difference". IT service performance contributes to a business value by supporting the significance, and the exact nature of how it is supportive is not a unique "given" but most often a result of management. For example, high-speed IT data processing can deliver timely information; this is a good achievement but that achievement does not itself lower cost. Instead, a manager's interpretation of the data leads to decisions and actions that lower cost. But the manager does rely on the visibility offered (i.e., the performance) by the data processing.
Another key note is that, to drive the desired business value, the amount of impact required may itself be achievable at various different amounts of underlying IT service achievement. This is analogous to being able to find the same given product ("impact") at different prices or financing ("achievement levels") depending on the time and place of purchase. In an IT example, an increased degree of website responsiveness is a contribution that is associated with triggering an increase in revenue, because more site visitors complete discretionary transactions. But this contribution may change from time to time or place to place, according to the business focus and location. For generating business value, it needs to be constantly visible against a target impact or threshhold set for the time and location of interest. The contribution needed for triggering inreased revenue is not always the same at every time and place.
Thus, accounting for the linkage of IT performance and business value takes several steps of drilling-down, and includes intermediary phenomena such as threshholds and interpretation. Meanwhile, describing the performance-value connection highlights impacts that are attributable to the IT-based activities and that are supporting the desired difference representing the business value. .
IV.
The important relationship to track between performance and value is how consistently the business demand for the service impact is satisfied at a given amount of service output. This principle is the same regardless of whether the service is an IT service, a Financial service, or some other kind of service.
The main issue is that if the layers are properly identified, then they are independent, although interactive. But this is exactly what we want. As illustrated in this discussion, this independence logically corresponds with two key known facts:
- changes can occur in any given layer without changing the overall business needs, and
- different implementations of the overall architecture will occur from one time to another and/or from one company to another; but the management practice itself can be consistent across these changes.
For any given organization, optimizing the overall operational throughput means focusing on the relationships between the layers, with investment and improvement directed mainly at those relationships.
But any given layer must also be managed. Once we separate a layer's output achievement from its upstream impact significance, it is possible for subsequent analysis to more precisely identify what is really necessary and sufficient performance to drive value all the way through to the business function's arena.
Posted by Malcolm Ryder at 10:07 AM | Comments (0) | TrackBack
November 26, 2005
The Value of Performance
A key threat to an organization's effective capability stems from missing the distinction between managing performance and managing value.
Naturally managers are expected to manage both, and the methods used are expected to generate information on which decisions are made about how to structure and drive the organization. If the wrong information is used, the organization may needlessly change or may change unsuccessfully. Becoming misaligned with the business, or becoming disfunctional through structural flaws, will reduce the effective capability of the organization.
To avoid the misalignment or dysfunction, decisions that provoke change must cause change for the right reasons.
The significance of information taken as an indicator of a need for change derives from a model of progress or a model of success. The model is both a theory and a plan that logically accounts for how progress or success is generated.
In practice, Progress and Success are defined in certain terms for the record, and operational achievement towards meeting those definitions is considered valuable. To be relevant to the model, information must help to account for the generation of valuable achievements.
This viewpoint allows us to understand why value and performance seem synonymous, but the distinction that needs to be made and preserved is a critical one for the relationship of the organization to its clients and hosts.
The target beneficiary of an operation has a need, and the need generates demand. But needs get prioritized without necessarily going away, and demand is generated from the priority. This illustrates that demand is actually not the same thing as need.
Meanwhile, organizational operation is meaningful because it addresses demand, and the way it addresses demand is to satisfy requirements. But different demands can "call for" the same requirement, which illustrates that requirements are not the same thing as demand.
Seeing those facts, we can understand the essential difference that management decisions and their suporting information must recognize and relate:
- Value pertains to the generation of a difference versus needs.
- Performance pertains to the generation of value versus demand.
This establishes the basis for management decisioning: managers are charged with driving and protecting progress and success, and now we know the essential terms by which they recognize and communicate the effectiveness of the management effort.
This view on the general relationship of value to performance clarifies the proper meaning and charter of "performance management". This view emphasizes that the concept of "performance" doesn't really materialize meaningfully until reference points (a model) are provided that both precede any actual execution and that afterwards evaluate the execution. The main goal of performance management must be to synchronize the actual outputs of operations with demand.
In contrast, the concept of "value" doesn't really materialize meaningfully until need is defined and confirmed. This puts planning into proper perspective: since plans by definition commit the organization to one scenario by excluding others, the importance of the commitment must be in its relevance to needs. The main goal of value management must therefore be to synchronize the actual outcomes of operations with needs.
Overall, the challenge presented to management is clearly visible. Since the "operations" effort is built around requirements, it can faithfully address them while actually becoming largely irrelevant to emergent needs. The translations of need into demand and then into requirements must be continuous and as real-time and seamless as possible if the organization is to maximize the effectiveness of its capability.
Information management techniques are developed to provide the visibility necessary for doing, tracking and using the translations. But technical support is not effective if the information is used to solve the wrong problem. For example, confusing value and performance leads management to attempt to address needs with outputs, or to address demand with outcomes -- mismatches that (worst case) leave organizations and stakeholders with false impressions of control and ROI, and with unproductive management agendas that are dedicated to changing things for the wrong reasons.
Such errors might be attributed in a general way to failures in knowing how things actually work. To avoid this very problem, management is saturated with initiatives in "intelligence" and "analysis" but there is then the complication of figuring out whether the intelligence and analysis are of the right type and the right amount.
Management typically puts a lot of attention on monitoring the "components" of a plan. But there are two ways to conceive of components.
In one approach, the plan's assumption is that there are mechanical "parts" -- such as the steps in a procedure or the quality of a particular resource being used -- and that their use is specially necessary to the intended progress and success. It's safe to say that this level of thinking is mainly operational.
But a more critical aspect for management attention concerns the actual reasons why the usage of those components is necessary, and concerns the requirements for their usage in the planned way. These are the success "factors", as opposed to parts, and the attention primarily takes the perspective of demand, not of supply.
Together, the reasons and requirements would determine that the mechanical components are "appropriate" for the organization's attempts to execute its strategy. But the components still do not drive the intended progress or success.
As seen below, the reasons and requirements cross-reference to form a framework for understanding how the organization can operate for performance. In this example application of the framework, a new product is to be reliably supplied to a target customer group. Basic assumptions emerge in the framework, representing a set of defined operational parameters or conditions that are to be managed. These are the success factors.
Now, information management steps in for decision support.
Where intelligence is concerned, if current findings indicate that the framework's success factors are not being met or validated, then adjustments would be justified -- to protect the execution of the plan from any significant divergence from the operational goal of providing relevant outputs towards demand. This would mean that the right changes are being made for the right reasons.
As for determining the right success factors in the first place, analysis is usally the weapon of choice. The framework's dimensions direct analysis at conditions that have categorical relevance to implementing for demand and thus will be about performance.
Posted by Malcolm Ryder at 7:32 AM | Comments (0) | TrackBack
November 24, 2005
Getting the Net Value of the 'Net
The internet is a complex organization of systems and content that is already fully deployed in live productions. So what's new? It is also a laboratory for testing and studying how we balance open sources, standards and objectives -- converting innovation into a "common good" when material scarcity is not a dominant factor. Meanwhile, business organizations in general are being encouraged more and more to pursue their structure organically and systemically through web interactions. Thus, the issue of governing cyberspace versus development, as discussed below, is actually not just about the internet but as well about the nature of the modern self-organizing enterprise...
How much "internet" is there?
For many of us, the internet is already practically ubiquitous. But despite its existing pervasiveness and our familiarity with it, the internet is neither virtually nor otherwise a "natural" environment. It's an artificial environment -- one in which a diverse population is steadily learning how to create, find and deliver many kinds of value. Given that, although the environment is artificial and is still being deliberately invented, it would seem to be in the public's best interest if it was a "protected" environment.
But because this "public" has many different constitutencies with different interests, not everyone agrees on what exactly it is about the internet that should be protected -- just as is the case with markets and national parks.
Different parties in the environment implement "controls" there to protect their own interests, but when the type and impact of these controls follows an independent agenda of the implementer, and when many such parties are motivated mainly to protect their own, then most parties have uncertain futures regarding success with their own agendas in that same landscape.
So, enlightened regulation is the thought that comes to mind -- but on what basis is agreement to the rules established? This is definitely not self-evident.
For example, an approach bred from defending the "rights" of each party to maintain its interests can't be a surprising choice, but it relies on a flawed assumption -- namely, that the active parties are actually creating the internet's expanse and that there is no significant limitation on the future expanse, therefore making it unnecessary to negotiate cohabitation in it, but rather merely to stake claims in the frontier land rush. But what's the problem? Too many tortoises in a population that includes hares. How do the tortoises get a claim?
Or another approach assumes that in much of the extant internet, "there's no 'there' there..." In this view, the only part of the internet that is worth controlling is the part that is already valuable. This cultivates a confrontation of squatters' rights and developers' rights, while leaving open the question of when the remaining wilderness has stopped being just wild. Problem: imperialism (and larceny) is a major threat.
The examples merely illustrate that stakeholders vary by the location, type and level of their interest. However, this is the whole point. Through metaphor and empiricism, the definition of the internet morphs from one thing to another amongst different users' perspectives. None of the users wants their interests to be regulated; instead they want them to be protected. Their interests define the internet for them, and in that sense they all want "the environment" they call "the internet" to be protected.
Thus, universal protection has the built in challenge of finding a greatest common denominator. Case in point: because the internet is so easily seen as an extension of some other communications infrastructure (environment) such as for marketing, academia or news, those infrastructures present norms or expectations of practice that mean differing and possibly competing sets of requirements within the internet . But you can't protect something that is all things to all people. Before the internet can be universally protected as an environment, it first needs defining in terms of the basic characteristics that can distinguish it from other environments; and then an effort should aim to ensure that the interests of one user/party there do not arbitrarily eliminate realization of the interests of others there. The key part of that thought is the "not arbitrary" clause; this effort must happen according to a policy that already prioritizes the different types of interest before they get to exert themselves.
Naturally, we debate how to set those priorities... but we should not be looking for the perfect answer; instead, we need a consistently appropriate way of arriving at an answer.
Protection versus Regulation: Policy versus Rules
We start here with presenting the internet environment by a signature common denominator. The elementary presumption is that everyone should have the right to access and exploit this environment's inherent support for distributing and otherwise managing digital hyperlinked media. Yet our experience of this exploitation and this "everyone" is incredibly complex. The US vs. foreign countries, the government vs. large corporations, and the whole scene regarding industry vs. hackers/cybercriminals -- all of these confluences drive intense debate about how to govern the internet, and complicate our concerns with ensuring a universal right.
We know from such problems that you cannot actually regulate the environment any more than you can herd cats. Instead, you can do two things: you can "constrain" the environment by limiting how it affects you, and you can regulate the approach to interacting with the environment.
So for example, you can regulate services, a key instrument through which you approach the interactions. Regulated services gradually build up the environment into an infrastructure. We can presuppose that this infrastructure should be "open" or freely shared, but experience shows that this idea won't be accepted at face value, because infrastructures require investments and investments are, frankly, competitive choices made by parties who already have disposable assets.
The question is, what are the principles behind the investment in and regulation of the services, for the public interest? Principles representing the "public interest" in reality presuppose that the public itself can be distinguished as a special interest group. It follows that, practically, the public should have a pertinent governance policy about services. But what, then, is the public's investment that creates an entitlement to bring policy?
Whose internet is it?
Where rules are essentially about requirements, policies are essentially about priorities. This points at the difference between constraining (via policy) versus regulating (via rules), and again we note that the environment itself is not regulated -- rather, it is constrained, while the approach to interacting with it (e.g., services) is regulated. In short, services should support policy. But whose policy, and why?
The key feature of a typical public policy is "fairness". Regarding the internet through the logic above, the public viewpoint is that Fairness itself should be "protected" (not regulated), and in particular "rights to access". However, to do that, the means of protection should be regulated, so that they are consistent with public priorities.
But equal "rights to access" is not the same thing as having actual equal access. Case in point: currently, the lack of a standard public requirement to have a "personal use license" to the internet means that anyone merely capable of getting themselves on the "info superhighway" can drive there, at whatever risk this poses to everyone else and to the environment. This is not equality, it is indifference. Meanwhile, some people, even benignly, pose much greater risks to others, and some people get much more out of their activity than do others. Obviously, this is not necessarily "fair or unfair", but it is rather a difference that might be qualified in many ways.
Against those conditions, environmental protection addresses the issue of "fairness" by balancing the risks that the environment's inhabitants pose to each other by their pursuits. The intention of the balance is that for any inhabitant, the environment effectively offers what the inhabitant distinctively needs from this environment, which clearly must also include preserving the user's opportunity and thus means preserving the environment.
Yet, fairness in no way dictates that the inhabitant must use this particular environment to satisfy need. Merely showing up does not bestow any special rights. Meanwhile, an environment without barriers to entry can easily collect a population, but a population is not automatically a "public". In sum, the default situation is that there are no public rights. To get them and assert them means we have to argue for them successfully.
Development
For the idea of the "public" to be effective, it must intentionally qualify members of a population, with a notion of membership that assumes a desirable commonality of interest. "All Comers" and "Public" are not synonymous. Members of the public have obligations to each other. All comers don't.
But both groups show up in the internet of their own accord; and when they do, both groups encounter the same three general circumstances describing the environment. These three conditions simultaneously exist, and come to the foreground of the user's consciousness mainly according to what it is that the user is trying to do.
- In the first, voluntary use of the environment comes with an "as is, at your own risk" norm of support.
- In the second, operation within the environment is facilitated by agreements and development.
- In the third, synthetic engineering of the environment optimizes the facilities.
In fact, different users provide, enjoy or cultivate these conditions according to their own various agendas. Thus, in determining a universal policy for global usage, support, facilitation and engineering become the primary subjects of policy assessment -- as a user's activity in each subject area is examined for its impact on other users and assess those impacts in terms of fairness.
Defining the stakeholder
In this impact assessment, the normal presumption is that any given user's requirements can be adequately identified so that it can be determined how critical the environment is to the satisfaction of the user's needs. That criticality is one standard dimension by which a user population can be anticipated, segmented, triaged and prioritized. Users discovered having less critical dependency (current or future) on the environment might be assumed to have "lesser say" about how the environment is to be managed.
But there is a pre-qualifying issue, which is the question "Why are the user's requirements considered to be 'requirements'? Can we be sure that they are not simply options?" In short, how easily could the user get what they need from someplace else?
In that light, we logically look for the motivation behind the user's need, understanding that the motivation generates objectives that the user decides to meet -- objectives which in turn spawn the user's view of certain options being "requirements" instead of just alternatives.
The thing is, as a community of potential users or as a population in the environment, we are not obligated to agree with the particular other user's objective. Thus we are not necessarily in agreement with the related means, conditions and consequences of pursuing it. Nonetheless, at the ground level, the internet is actually developed, and still developing, mainly through the decisions made about executing these pursuits.
Assessing the stakes
Policy makes a difference by explicitly implementing key aspects of governance of the relationship with the environment. In the effort to establish policy, we cross-reference support, facilitation and engineering against means, conditions and consequences -- creating the basic framework for comparative assessment across different user objectives.
When we thus look within this framework at how means of support, conditions of facilitation, consequences of engineering, or other factors might develop or manifest themselves, we determine alternatives, risks, services, and other concepts that represent the interests of different stakeholders in the environment.
The translation of interests into rights is the logical imperative of the policy. The presumption of the public policy is that individual parties do not encounter or enter the environment with "inherent" rights -- but instead that the policy allows the public to grant rights according to "public interest". Without a policy, there is no common "granting" mechanism other than culture and power -- and those two mechanisms may be randomly at odds with each other even as they bilaterally shape and reshape each other. But characteristic of our times, we really can already take the use of the internet for granted. Thus, as a global device for real-time interaction, the internet begs for a cross-cultural "public" to arise -- making reconciliation not just important but urgent.
We have seen the Internet, and it is Us
In a given environment, potential users of the environment will gravitate towards less randomness as a matter of common sense. Their general modes for acquiring increased certainty span R&D (build), subscription (buy), and sheer hustle (borrow). All of these modes do present practical challenges to users, who consequently find themselves separating out according to their differing ability to effectively take advantage of each mode.
But while such segmentation naturally occurs, this observation in no way specifies the party's particular "use" in question. The attempted uses range freely across the segmentation -- and as uses are discovered and cataloged they represent objectives that must be assessed by policy. These objectives are the first order of policy business, with the opportunities for their satisfaction being a key topic of protections.
Meanwhile, the internet is -- almost by definition -- a network of networks. Standardization of the protocols for internetworking does not per se dictate that access to all networks should be a universal right. Any given network is greatly understood as an ecosystem, and not all ecosystems are compatible with each other. Extending the comparison, an ecosystem is like a subculture. Policies should constructively serve subcultures, but this raises the issue of when and how much the policy for one subculture should be required to support another subculture, so an assessment should tackle this too.
Commercial marketing, news journalism, and academic research are examples of distinct subcultures. Operating within the internet, under different dynamics and having different agendas, they co-exist without necessarily co-operating or collaborating. In exploiting the basic internet technical architecture to create operational infrastructures for themselves, they each present respectively different requirements, which are variously satisfied through built, bought or borrowed means.
As cohabitants of the internet environment, the different subcultures may actually share operational means, but the terms of the sharing are neither mandatory nor guaranteed. Rather, these interactions of different communities come with the same set (scope) of issues already identified in the above framework of policy assessment.
Our framework is portable; each different subculture may use it to assess and tailor its own policy. But the framework also searches for the same issues regardless of whether the scale of user comparison is personal (person-to-person), organizational (group-to-group), or greater. Policy can be assessed and set for the different scales.
Each subculture may have its optimal policy. This makes us wonder about the need for compromise, or in general the way to achieve reconciliations. But although multiple subcultures or ecosystems are present, and while many different levels of interaction are simultaneously active in an subculture, the framework's similarity of scope across the different groups and scales logically suggests that there is not a need for some superpolicy (or "policy of policies") to govern any given ecosystem -- nor the network of ecosystems.
Instead, it is more appropriate to move to strategy as the enabling and unifying discipline for public governance.
The internet calls for a strategy of environmental management, that states what kind of value is the goal of the public policy and thus directs all supporting logics used to reconcile the complexity of its population's diversity.
Growing and Harvesting the Net
In the political realm, global does not mean universal, and rules do not mean rights. Consequently, the ethics of environmental protection cannot be articulated as absolutes but only as motivated responsibilities towards goals.
What emerges from this perspective is that governance is likely to be ineffective without strategy, and that the translation of policy into rules is likely to be ineffective without strategic agreements amongst stakeholders.
Because our highest-level community perception of the internet is that it is a "resource", we attack the "environmental protection" issues from the viewpoint of "resource management and optimization."
But at the ground level, what complicates the issues in practice is that operations to often reduce the discipline of managing the resource into the management of artificially produced assets. In effect, asset management competes with strategy as the value system for governance.
Internet policy for the public interest cannot be rationally successful when dominated by asset management, because assets are essentially private and, aside from notions of quality, require no ethical influence at all to be successfully developed.
Whereas, (in the common parlance of Archestra research) a resource is "an asset with an assignment." iven that assignments would be to serve the public interest, managing the evolution of the internet on the basis of "resource" is a profoundly different objective than managing on the basis of assets.
Without at all confusing "global vs. universal" nor "rules vs. rights", the conversion of assets into resources can point at the key concepts of public interest and commonwealth. Management of the internet should be based on growing resources, not growing assets. In parallel, the translation of interests into rights, through the influence of policy, must be based on strategic management of resources -- judiciously cultivating a shield of protection for the environment and its inhabitants.
As we assume a nearly relentless further growth of the internet's pervasiveness, putting rules before strategy can stick a finger in the dike but it won't relieve the development pressure of asset management that breaks the dam. So our mandate is to create and adopt for the internet a resource-oriented universal strategy that can be globally executed.
Posted by Malcolm Ryder at 10:18 AM | Comments (0) | TrackBack
November 23, 2005
The Value Management of Change
Planned change most often performs the task of recovering, reallocating or reconfiguring assets such that they become currently viable resources.
Benefits from changes come in many flavors, as few as there are different stakeholders and as many as there are occasions of use.
A single change might affect different parties in different ways because those parties have different dependencies, maturities and positions from which they operate. Consequently, the change affects them differently.
Thus, the potential "scope" of a change reflects multiple points of view that can variously describe the same change. Successful changes are often described through a set of "cascading" points of view that show how different levels of execution (managerial, operational, technical, etc.) coordinate.
IMeanwhile, innovations, renovations, reengineerings, repairs... all are possible perceptions of both the intended and the actual objectives of a change.
What's interesting is that not only can a single change be characterized by these different perceptions, but also that the lifecycle of a change includes several phases that may each be characterized, by those same perceptual terms, differently from the others .
In the change lifecycle, a modification to an existing structure or state of affairs can be seen to have these general phases:
- conception
- selection
- development
- implementation
- utilization
Each phase creates conditions that stage the next, but there also may be significant conditional requirements and constraints that are different for one phase than for another. These can include things like information tools, methodology maturity, funding sources, standards, and approval process.
The various factors appear differently, blend differently and influence differently -- by timing, place and stakeholder -- and by phase.
This indicates that any given phase may be driven by certain preconceptions regarding what kind of difference that it achieves will be significant -- or in other words, what value is delivered. The value of one phase can be very different from the value of another.
For example, management can take into consideration the need or opportunity to renovate (upgrade) methodology used in the selection phase. The reason for renovation is ostensibly to realign the procedure to the current requirements of the organization when the requirements have evolved beyond the incumbent (legacy) procedure. While the legacy procedure might deliver an acceptable decision towards the next phase, it might fail to support learning, partnerships, or economies of practice that better promote the organization's overall productivity and agility. Exaggerating to dramatize the point, the old way might be built for a perfect choice in one thing, while a renovation might be calibrated to produce a good enough choice in ten things.
But along these lines, we can see potential unpredictability or lack of coordination that makes each phase a constraint on the overall target value "delivered" from the "chain" of the modification's lifecycle -- but we also see that the value from each phase can influence the environment of overall operations.
This means that the ultimate change-deliverable may or may not be adopted and assessed as a high-value output. The impact of the deliverable includes an outcome that should be measurable, but the impact of the production of the deliverable is more fundamental to the economics of the organization's performance.
We have an intuitive recognition of this fact. We all know what the phrase "at any cost" really means, and it is about sacrificing our enabling infrastructure designated for sustained production, in order to drive an urgent singular outcome. We know what an "environmental impact statement" means when large-scale projects must alter the environment in order to arrive at their destination state. And "economic impact statements" typically identify projected alterations of cost/benefit relationships in many ways other than by the terms of the target change state.
The issue that is raised is the relationship of the change process to the value management practices in the organization. This relationship stands in comparison to the cost-efficiency practices associated with execution.
- Cost management addresses the consumption of allocated assets in meeting requirements...
- but value management addresses the opportunity cost of pursuing advantage by exploiting resources.
Posted by Malcolm Ryder at 8:02 PM | Comments (0) | TrackBack
November 11, 2005
Needs Are Not Requirements - A Failed Romance
This week, as in many others, our customary readings intersected in a question of whether business is the best way for customers to get what they need. Answer: maybe not!
In a handy coincidence, Joshua Greenbaum wrote that customers hate their software vendors, while Richard Snow wrote that vendors don't understand their customers.
It might be said that customers pay for a satisfying relationship without having the wherewithal to manage the relationship successfully. Here we have to separate the idea that the customer gets what they demand from that of their getting what they want. A lack of customer satisfaction is about needs, while getting what they are entitled to is about requirements. Unfortunately, needs and requirements are two different things.
Posted by Malcolm Ryder at 8:15 AM | Comments (0)
September 19, 2005
Productizing IT Resources for Business
Directly or indirectly, a "business-view" of IT always asks the basic question, "what do we have and how can I use it?" This perspective connects IT capacity with business capacity, implicitly relying on provision being managed to the requirements of the business.
Given the dazzling diversity of options and sources in all things IT, a framework of "business requirements" will put pressure on the provider to work not just as a supplier but as an agent. In that case, the availability of "appropriate" and "manageable" IT is assumed by the business but realized by the provider. The business attributes value firstly to the provider's process for satisfying business requirements -- and relies on that process.
Successful realization of the right IT for business is essentially the same problem of "bringing the right product to market"... Timing, cost, quality and availability are all success factors in the value of production and provision. Among the worst case scenarios are to bring the right thing at the wrong time or the wrong thing to the target location -- emphasizing why the definition of demand is a dominant issue.
The basic challenge for the provider is to manage value end-to-end from production through provision. Using a simple working definition, practical "value" is the effective difference made towards intentions. In that light, we can easily see that "value" is generated in different ways under different circumstances while across all of that variety it also maintains a common focus on the intention of meeting the demand.
Functioning like a business, the provider has four key stress-points along the course to fulfilling demand. At each stress-point, the balance amongst the success factors cited above can be manipulated to some degree. As seen in the illustration below, each point (bottom left to top right) can significantly support an adjacent point in the chain, so improvements at each point can optimize the overall throughput of value to the final provision. The process alignment cultivates value.
This example highlights the management related to minimizing the risks to the stability (reliability) of the IT environment, as seen from a business point of view. This view features the concern for the value of "what we have" and "how we can use it" -- each as supported through managing capacity and controls.
Posted by Malcolm Ryder at 7:47 AM | Comments (0) | TrackBack
September 14, 2005
The Business Value of IT Operations
It's safe to assume that every IT organization leader in every mid-to-large sized company is being pointed by the company executives at the need to demonstrate IT's "business value". To ultimately survive this challenge, we have to avoid proving the wrong thing for the right reason, and avoid proving the right thing for the wrong reason...
I.
Debates seem basically unavoidable when it comes to deciding what "business value" means. But until the meaning is defined, it's difficult to decide on what should really be included for demonstration. Not surprisingly, the things that distinguish "business" audiences -- their respective roles, objectives and priorities -- virtually guarantee that there will be multiple perspectives on the idea of "value" -- reflecting role-sensitivity. Meeting the demonstration requirements for all of these different perspectives is a gigantic burden on IT managers.
Even when all the bases get covered, too often the results seem to not correlate meaningfully with the business outcomes that the executives themselves are measured by. From 50,000 feet high, Business changes while IT doesn't, or IT changes but Business doesn't... and it seems that the two things are independent -- so a lack of confidence in "demonstrated value" persists.
II.
At the core of that problem is the possibility that the wrong kind of relationship is being hunted down, for no good reason other than that it would be exciting if it proved to be true. Namely, we want IT to "cause" better business performance, because IT is tangible so we hope thereby to mechanize our success.
At some point, though, and let's take now as a good one, it becomes smarter to look for a kind of relationship that shows more consistency.
This can start with leaving behind the idea of "causal" (or systematic) and replacing it with the idea of "systemic".
An important way to address the issue of business value is to ask what business does that is done "better" due to I.T. utilization. This question, which is a particular point of view, looks at I.T. as an enabling resource for business capability. The systemic perspective looks at the influence of the resource on the whole "ability" -- which is represented by the business task.
III.
Capability enablement is achieved through operations that allow the business to leverage the resource, and that leverage practically represents the resource's influence.
To institute this, business coordinates management of those operations as a logical organizational unit within the overall management of business operations.
At that point, a big part of the complication in value assessments is that the "logic" of the organizational unit is not linear. Instead it is multidimensional due to the variety of ways that the unit should establish the leverage business seeks. This is about the variety of responsibilities invested in the role of the operations.
In the case of IT operations, we derive the dimensions from basic expectations, in this way:
- First, business enablement is not the same thing as business execution. Knowing a language is not the same as public speaking. Being trained is not the same as performing.
- Second, managing enablement is a scope of responsibility requiring attention to the form, function, purpose and acceptance of the means of enablement offered to the business by operations.
- Finally, IT operations are the provider, not the client, wherein the operations value to the business is established.
What are the key dimensions of the provider role, as seen from the business point of view?
The model below shows the systemic relationship of the four business perspectives -- supply, production, delivery, provision -- that IT operations is accountable for in its provider role of manager of IT enablement of the business.
As for the value of the provided enablement itself, effectiveness is the essential concept behind assessments.
IV.
Business's ability to use IT effectively is one of the major strategic objectives of IT operations; but effective utilization must have an objectively sensible meaning. If there is real meaning to the idea of "business value", there is no point in holding IT accountable for value outside of the context of the business's management of its tasks. The cost, speed, efficiency, control and impact of the task are representative aspects of the "whole" ability supported by the resource of IT.
The business must find that its dependency on the provided enabler was sufficient for the necessary performance level of the business task. But there is a logical limit to how much the enabler's contribution can be held responsible for the target outcome of the business task. The success factors of the business task include more than the IT component, and the idea of the task's "success" includes more than just the completion or output of the task.
Considering those issues together gives the business fair warning on how to envision IT's involvement in the answer to the question "how predictably and frequently can we do really well what we need to do?" IT does not decide what the business needs to do. But the more IT utilization can be attributed to a positive answer, the more valuable IT is to the business.
Posted by Malcolm Ryder at 9:36 AM | Comments (0) | TrackBack