" />

« February 2006 | Main | April 2006 »

March 31, 2006

CA, Inc. -- a.k.a. Computer Associates

Please see the entry "Articles about IT on Archestra", posted March 31, 2006.

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

Articles about IT on Archestra

The collection of items on this website, www.archestra.com, often implicate or involve issues that are vitally important to the way management and strategy relate information technology to other enterprise concerns for creating value and performance, and for controlling risk and maximizing opportunity.

As a host for ideas from colleagues and collaborators, Archestra will have additional new items related to IT on a continuing but unscheduled basis.

Original personal items of mine are typically signed and copyrighted under M. Ryder, Malcolm Ryder, and/or Archestra. However, to whom it may concern, this entry that you are now reading is to note that my personal new items about IT will be produced (until further notice) mainly under copyright of CA, Inc. (formerly known as "Computer Associates"), a major enterprise applications provider at this time specializing in Enterprise IT Management.

As a formality on this website:
- References to CA, Inc. materials will not be handled any differently from references to other non-Archestra copyrighted materials.
- Meanwhile, there will be no special Archestra attempt to present IT-related content that is copyrighted by CA.
- Also, contributors to Archestra who in their contributions critique non-Archestra copyrighted materials are welcome to continue doing so without treating their contributions regarding CA, Inc. any differently in manner than might be other organizations by that contributor.
- Finally, CA properties will not be exposed on the Archestra website except by ordinary and sufficient permission of CA primarily through its copyrights or conceivably its own voluntary contributions to the Archestra website.

Elsewhere on the Archestra site, my original personal IT-related content not yet posted but already copyrighted prior to April 3, 2006 will continue to appear at my discretion, on an unscheduled basis -- whereupon it may be further elaborated and re-presented by collaborators and commentators just as all postings on Archestra are currently intended to allow.

March 31, 2006
Malcolm E. Ryder

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

March 30, 2006

IT Investment versus Business Returns

Christopher Koch's blog for CIO.com featured the post Why Defend This Metric? (Thursday, January 05, 2006). The ongoing debate about how to quantify the business value of IT stays open, and at this point it seems the difficulty in answering the question is mainly because of the way the question is asked. Consequently, the debate deserves a turn in which the analysis might force a rephrasing of the question.

If a single metric could justify an investment, it would nonetheless actually have to account for several things, but the logic of how it does that is the most important aspect. Let's drill down.

First, the goal is to arrive at a fact that allows acceptance or rejection. This is about tolerance. The fact being sought is a piece of evidence that a significant difference has been demonstrated that is rationally attributable to a particular contributor -- in this case, "a business difference due to IT". The evidence may range from non-existent to very strong. But until there is agreement on the recognition of both the type of difference and its significance, there is no actual "executive" attention to what is acceptable.

Assuming that a type of difference and its significance have been defined and agreed upon as the axes of reference, a range of tolerance can be declared. But there is no point in attempting the declaration unless criteria have been explicitly established for identifying the boundaries of the tolerance.

Assuming that the range of tolerance is properly established, events that can represent the difference in question would have to be defined, and each type of event would have to be describable in terms of dynamics that normally correlate with the event. Those dynamics might be ones that "cause" an event or ones that "allow other causes to generate" the event. Since the difference between being a cause versus a prerequisite can be quite vast, the association proposed between a given event and a given dynamic must be rigorously distinguished -- in terms of the role of the actors (means) involved in the dynamic.

The reasons that explain why the actors have the roles that they exhibit must be exposed -- to allow recognition of where any behavioral or influential regularities originate, as well as irregularities.

Finally, opportunities for directing those actors -- which is the same as to say "for employing those means" -- must be identified and catalogued so that the exploitation of those opportunities can be examined both historically and in terms of operational policy and methods.

The ability to consistently coordinate these levels of description with each other, and to monitor their coordination, is clearly more a matter to be discussed as "competency" -- and the importance of that competency is in how decisions about what to do with information technology finally translate into significant business differences.

The proof of competency is measured in terms of real-time responses to business challenges. If those responses can be expressed as "scores" (just like a double-play in baseball can be scored in "outs" or hits can be scored in "bases"), then there can be a situational perspective brought to the utilization of the means, and the way that the scores are appreciated can be associated with the money spent on the involved means. When a win seems to require lots of base hits, and investment has been made in assuring hitting competency, the correspondence of the investment to the situation is easy to accept. But failure to hit well in those situations means little return on the investment. Likewise, failure to even be in those situations means little return on the investment.

In this sense, measuring performance against situations is obviously the correct way to measure IT investment. By comparison, measuring IT costs against total business income is apparently an arbitrary thing to do.

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

March 22, 2006

A New Way To Think About Requirements

All progress does not result from meeting requirements. Sometimes, luck prevails, and the conditions in which we were laboring simply change to our advantage without being influenced by us. But all requirements are considered meaningful because they indicate a path to progress. Although competing definitions of progress may exist, no one debates the purpose and virtue of setting requirements.

Defining requirements is difficult. The empirical contrast of results from carefully defined requirements versus ill-defined ones has demonstrated that, and also shown that the cost of failing existing expectations easily wipes out the apparent value of isolated progress. This setback happens when it is unclear where expectations are coming from, and/or when the activity develops new circumstances without certainty of being aligned with the expectations of record.

The frustration of unstated expectations or of ones that have changed or appeared without warning may be a legitimate feeling -- but that in no way exempts the failure from the oversight or purpose of management.

Although change management is successful as a remedy and is ready for use from the start, it comes late in the proceedings.

At the start, the more important and urgent instrument is a model that allows comprehensive discovery of expectations, in a way that allows them to be processed into requirements. Shown below are the four main categories of expectations, ordered to help reveal the multiple perspectives that result in requirements being adequately defined. The categories of expectations -- responsibility, organization, resources, and objectives -- are obviously reflected in most systems of accountability.

Yet it is typical that even knowing the accounting systems, confusion or obscurity develops between what gets done and what is expected.

This problem is most often referred to as a "gap" of some kind -- for example a gap between strategy and execution. But that reference is probably erroneous in two ways.

First, it is production, not execution, that normally gets measured against strategy and coughs up a "gap" between the intended and the actual. (Execution is not about the results. Execution is predominantly about the decisions that generate actions.)

Second, as represented in the model here, the key problem of developing progress is worked out through systematically and iteratively deciding potential values, not compliance, to be leveraged from execution's direction. Implementation proceeds moment by moment through reality, constantly asking the question "what difference will this next item make?" and adjusting its navigation accordingly. In answering, the point of view on that progression sequentially escalates from strategy to achievement, to performance and then to outcomes. The expectations at any one of those steps can trigger a reworking of the previous step. And the implementation does not "finish" but rather continues cycling through the four steps, until the risks outweigh the benefits.

That suggests the importance associated with translating facts about events into facts about states -- which not surprisingly is a huge business, built on faith in causality and an appetite for analysis.

On the other hand, translating expectations into progress is what is really mandated and is always being attempted. This translation demands concurrently managing construction, integration and target deltas (change) -- the main elements of production activity.

The model of progress shown in this discussion assumes a sensibility most like "implementation" (i.e., synthesis rather than analysis). The model's synopsis of "implementation" is that expectations become intentions, which become behaviors, which become events:
- execution formalizes expectations as "intentions"; namely, missions, plans, functions, and operations
- those intentions are used as instruments of execution, to determine the institutional "behaviors and effects" recognized as strategy, achievement, performance and outcomes.
- those behaviors cooperatively drive events, and are interrelated and assessed by general perspectives representing factors of change, such as What, Why , How and Which. These factors may be expressed both as preferences (future) and as facts (current or past).

As a result, "gaps" may appear between the "intended" and the "actual" for any of the effects -- but the progression of management attention from strategy to achievement, to performance and outcomes does not change in order, and outcomes regenerate strategy, closing the loop of influence.

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

March 14, 2006

Finding the "Enterprise" in IT

In running the business with a strategy, strategy must increasingly factor IT into its equations, because of IT's power to affect most of the conditions to which strategies design a response.

Going along with that, the working assumption is that a business organization must have IT-based capabilities that allow it to beneficially maintain and change itself in its target environments. A standard caution is that IT can always make things different, but that "different" is not necessarily "better" -- and the definition of "better" must come from the business.

Given those points, there is a logical hierarchy of values in IT-based business solutions. To reveal it, however, requires clarity about the difference made by automation and the difference made by information.

Superficially, we always recognize that information directs decisions and automation directs labor. But decisions also commit that labor, while taking into consideration that automation can change the feasibility of the commitment for better or worse.

As a result, we see that decisions drive automation -- meaning that information drives automation, not vice-versa.

Arguably, then, the top business issue to address with IT is to govern information access.

This makes the overall affair of IT management primarily sensitive to the successful provision of information driving the decisions. But what is meant by "overall"?

I. Solving the right problem

Keeping in mind that decision-makers are placed at all levels and locations of business production, adequate visibility and control of provision is a gigantic and daunting task. Processes that govern information access are the ones that most need to be automated.

But the point of governing that access is to ensure that decision-makers are supported securely, appropriately and efficiently, so that they can pursue business objectives.

This point provokes a general model for the relative business values of IT-based solutions. The importance of having this model is to set expectations consistently and to provide the most basic logic behind changing existing investments in, and implementations of, IT.

The solutions should contribute to one or more of the following very broad objectives, which flow top-down from the main desired business capability to the supporting functions, architectures and assets:

Taken together, the four concerns add up to maximizing the quality of the IT infrastructure as a business resource.

Specifically, solving the combined concerns -- governance, rationalization and optimization -- results in a positive ratio of resource capacity to business demand, which then allows strategies to "close the loop" by exploiting #4's ability to enhance #1.

II. Optimization

In optimizing resources, businesses rightfully ask, "how capable can we afford to be?" Regarding IT, this is a general way of pointing at the problem of return on investment. It might casually be seen as a cost/benefit ratio. But the flaw in seeing things that way is that, with adequate production supervision, benefits are simply desired outputs that are more or less predictable according to their price; to generate real business value, those outputs must still be used in certain ways.

For example, buying a computer and using a computer are quite different. In the first case, an asset becomes owned; but in the second case a resource is deployed (committed). Ownership and deployment have different kinds of value. By linking assets to live functions, deployment makes IT serve the business.

With this commitment, the natural inclination is to pursue as much functional potency from the asset as possible, and discard the asset when it can no longer measure up. That potency may even result in enterprise-wide impact.

Yet more importantly, the method and opportunity for achieving that potency may not be scalable cross-functionally or enterprise-wide. So this is not the gist of the notion of optimization nor of "enterprise" IT. The enterprise-scale value proposition is not to optimize the commitment of "all X number of components" but instead the commitment of the overall IT infrastructure as a resource. By analogy, it is managing an entire portfolio instead of a collection of budget line items. It is seeing the forest first, not the trees.

At the enterprise scale, the deployed infrastructure essentially becomes an environment for business operations, and IT management accordingly must step up to an environmental perspective. From that position, optimizing the environment basically means programming its dynamics.

For example: business typically organizes its information demands with desired flows of business processes -- and business processes are highly sensitive to changes forced by competition, regulation and economies. Because of that, the related IT processes that help govern and enable information access need to be not just reliable but also adaptable (i.e., versatile and/or flexible). This involves a critical dependency on the underlying infrastructure. Thus, due to ongoing change, deployment of infrastructure is also a continuous "environmental" process, not just an event.

But the programming is not just about addressing deployment for demand. It is also about support for utilization and allocation for supply.

In coordinating all three dynamics, the key characteristics of environmental-scale management feature an extent of visibility and control that intends to establish productivity and conservation in balance with each other.

As part of the environmental programming, management establishes the generally required conditions for this balance through several means:
- policy (which protects priorities versus requests)
- standards (which protects regularity versus options)
- security (which protects integrity versus exposure)
- economy (which protects assets versus consumption

While those protections are a major deliverable of management for achieving balance, the value of that balance at any time is determined by its relevance to business goals. That is, management's other key objective is to have the balance actually promote business development.

The problem is that business development so frequently pressures management with local demands that challenge the global balance. This threatens the environment's equilibrium, which increases the uncertainty about its overall quality versus additional and future demands. Because of that, what management wants is the visibility and control to maintain the environment's equilibrium while knowingly raising its overall quality as a resource.

III. Rationalization

The strategy for having that visibility and control requires a focus on services and architecture. Services predefine the relationship of deliverables to demand; and architecture predefines the relationship of capacity to services. The predefinitions allow the organization's managers (or providers) to offer things already known to fit into economies and scales, and locations and permissions, that they can handle -- and to more readily recognize and decide about things that don't yet fit. Among those things that don't fit are not only newly-emerged requirements awaiting organized support, but also potential threats to the integrity of the established services and architecture.

Unfortunately, the growth rate of a large IT environment may often have outrun prescriptive efforts to define it -- raising the number of exceptions, silos and risks. This simply means that it now has to be retrofit within the terms and principles of architecture and services -- that is, those become the elements of rationalizing the environment. The descriptive language of services and architecture will supply a different perspective from which to identify and assess the environment. Subsequently, discoveries will be made that indicate a need to make changes that will conform the environment to business requirements.

IV. Governing with IT processes

What this really means is that the environment at minimum has to be "trained", not necessarily rebuilt, and programming the environmental dynamics begins to accomplish this. But eventually the programming might require reorganizing things in ways that reveal omissions, defects or obsolescence in the resources, whereupon rebuilding is appropriate.

The challenge is to have adequate visibility and control of any reorganizing. Critical information gains or loses availability and credibility according to how its channels are gated, groomed and connected. Knowing that infrastructure modifications will range in types -- from innovations to deployments to shoring-up defenses, and from strategic to hostile -- policy and change management take on an enormous significance. Meanwhile, the implementation of business policy and business change increasingly must be supported through IT, and this means that business policy and business change must also be translated into IT policy and IT change. That translation must not be speculative, and the outcomes must be explicit.

V. Business management

From the business point of view, the purpose of relying on IT is to bring significant assurance to the safety, competency and advantage of whatever the business tries to do. For IT to offer this kind of value, it must be manageable, and the complexity of its manageability is the main barrier to the business being successful in the driver's seat.

To the extent that complex technologies can make technology management simpler, complexity breeds value by giving the business more practical influence on IT, of the kind that it intends. (Today's automobiles are the most complex ever, yet they are easier than ever to drive.) But the success of the business is predicated on its ability to tailor responses in real-time to the particulars of each opportunity event. Any given response -- a blend of characteristics including safety, competency and advantage -- may need to be significantly different from others, yet crafted from a known available capacity.

Thus, from the business standpoint, the enterprise IT management goal is to achieve the lowest cost of predictably sustaining the necessary degree of enterprise-wide adaptability of the infrastructure. With that established, business processes and business performance can in turn be more readily managed to business targets.

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

March 13, 2006

Aligning Strategy and Production

In management conversations, the vocabulary uses ideas like value, performance, and success in urgent and motivational ways. But their usage is too often so flexible that it is nearly impossible to be sure whether the means of achieving them are being sorted out for better manipulation, or instead just all lumped together (where measurements start to lose their meaning as well). In general, less definition brings less likelihood of predictably gaining necessary effects.

To begin the more detailed look into definitions, the following line of thought offers a point of view about how -- in a context of marketed deliverables -- execution turns intentions into realities that matter.

The home base of this point of view is a significant simplification in identifying the key objectives associated with execution. That is, what does "execution" mean in the value systems of its stakeholders? It's not just about going through the motions. What is needed from execution?

As shown in the first picture below, there is a demand perspective and a supply perspective -- which are important to compare because they are basically independent of each other and yet, in order to create the value sought by stakeholders, must come to correspond and agree with each other.

- Demand asks for something, and the provider gives it through two main features: implementation that creates the factual difference between "requested" and "realized"; and, specification that ensures the right thing was realized.
- Supply offers something. Correspondingly, it promotes availability as the difference between requested and realized; and it offers quality as the assurance of the rightness of the realization.

By describing supply and demand in terms of effects, this viewpoint also allows us to include an initial mapping of the execution-related ideas called "support" and "delivery" as values. With this mapping's cross-reference, it is more evident what it is about demand and supply that stakeholders feel execution needs to accomplish. In this view, Support represents the activity in demand and supply, while Delivery represents the item in demand and supply. We understand that the intended support or delivery has measurable practical significance that from one instance to the next may differ in level while not in type.

The next key idea is that all stakeholders, despite their different roles or positions, actually have the same goal -- which is that the execution linking supply and demand will be successful in negotiating a viable relationship of offers to requests. At any given time, a particular stakeholder may have more or less interest in detailed visibility on the mechanism; but everyone wants the same overall success and can appreciate that overall execution may be a highly collaborative multi-party effort.

All the more reason to stress that everyone should be able to see themselves from a common point of view. That, in turn, is what allows a shared appreciation of the three basic elements defining the execution's success: the design, the plan, and the ultimate output or product.

Each of those elements represents a set of definitions and decisions that are made within the execution, promoting the realization of the request. Each represents an area that contains many options, making the particular decisions as important for what was not chosen as for what was. The decisions represent the actual propagation of potential value throughout the effort to realize the request.

Typically, we expect the translation of intent to reality to be captured in a plan. The following picture generically identifies and arranges the major points of reference within the plan definition that characterizes the before-to-after execution.

From the bottom up through "Workflow", we see the buildup of activity that will ultimately transform the current conditions or state (need) into the targeted later state (satisfaction). What happens above Workflow establishes the mechanism by which we can assume the right thing is actually achieved from that base of activity.

But in actual practice, the definitions of design and product, not just plan, must all be attended to in detail. Like the plan, the design and product aspects each have a hierarchy of key decision-levels that are execution components. The following picture identifies the components of the design and product definitions, along with how the key details of the plan components pertain to them.

This full articulation of the execution effort shows a series of decision interdependencies that, followed from the bottom up, chart the generation of an eventual "Production" as an accurate, reliable and safe instrument for fulfillment. The point of having and using this big picture is to create, before execution, the logical alignment of an end-to-end system for fulfillment.

Going from the bottom up, what we see about the "Plan" group of execution components (middle column) is that each of them allows a "Design" execution component to generate a "Product" execution component, or vice-versa. For example, Strategy uses Modeling to generate an appropriate Architecture; and through Resourcing, a related Organization (i.e., functional unit) is generated from Architecture; and so forth. Furthermore, the details of those Plan components reveal issues in which decisions drive the design component towards the product component. For example, the Organization will use Development to generate an Infrastructure; and in that Development there are issues about standards, methods and schedules that get decided and shape the actual path to Infrastructure. Higher up, decisions about Change issues including authority, scope and risk likewise channel requirements into Production.

In that sense, the zig-zagging between design definition and product definition is controlled by Plan items. Control is, of course, a basic management concern. Everyone wants to get all the way to the finish line. But as the saying goes, if it doesn't matter where you're going, then it doesn't much matter how you get there. Tthe most important aspect of this control is the value problem -- that is, how the control links the values in Supply and Demand.

Looking at the big picture, the intuitive expectation is usually that, Supply is "pushing" from the bottom of the arrangement, tempered by management controls -- while Demand is "pulling" from the top. But in terms of validating stakeholder value, the dynamic is different than that. We spot it in terms of support and delivery.

Given the big picture, the expectation should be that Design will build up the offer of availability that is eventually substantiated in the facilities underlying (i.e., supporting) the Product. Meanwhile, those Product facilities, through prioritization, will promote the request for implementation that is represented by the intentions defined throughout the Design.

In other words, it is not Supply that pushes upward, but instead Support.

Meanwhile, "Delivery" -- featuring an assured ability to provide the correct thing -- should be able to "poll" an auditable trail, down through all levels of decision-making. Because recipients hunt for a provider of what they specifically want and will consider more than one provider, real-time polling would be the ideal, verifying the character of current options. In other words, Design will drill-down into how the provision of the Product specification will be logically assured, and the Product must be able to track down its characteristic quality to Design origins.

That is, Delivery, not demand, is pulling from the top.

The summary of all the above is that in execution there are generally three different arenas -- the sets of definitions driving decisions in Design, Plans and Products -- within which one might track critical success factors and/or points of critical failure. By parsing those numerous issues according to a value orientation on achievement, opportunities that are relevant to stakeholders for linking supply and demand can be anticipated or detected more consistently and thus better managed. This aids fulfillment by way of enhancing problem resolution, optimization and agility -- respectively reducing risk, securing effectiveness, and cultivating advantage.

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

March 10, 2006

How Not To K.O. KM

Knowledge Management (KM) initiatives need not buckle under the weight of uncertain value. The key is to use it to solve the right problem, and to handle it as a characteristic to acquire, instead of as a system to install.

I.

The transportation of knowledge from personal to public, human to machine, and domain to event already occurs continuously throughout the organization. But to optimize how it composes the operational environment, the appropriate aspect of concern to investigate is capacity development, not process development. That is, the availability of the right knowledge in the right circumstance is a different problem from the delivery of at-large knowledge supplies.

Determining the "rightness" of the knowledge and of the circumstance is not about inherently "correct" content. Instead, it involves the use of models that connect expertise to outcomes, not just requestors to information.

That effort needs to be systematic, but in the main conceptually so, not technologically. The biggest practical challenge is to shape a worker's analysis and judgement during a task, by exposing enough of a relevant model to present, guide and validate choices -- while also capturing feedback on the effectiveness of the model's influence on the worker and on the outcome. The problem causing the challenge is that two unlike workers may be different primarily due to their respective individual mental models -- which for starters may also differ from the common model being presented. The payoff comes when dissimilar workers use the same model to derive equally effective individual execution.

A key related factor is that knowledge is carried into production by workers. Knowledge is quite variably embedded into production through a range of techniques utilized by the workers. Managing their techniques becomes a fundamental task of production management. But likewise, the right knowledge must be put into those workers, and the variety of techniques for doing that must also be managed.

Interestingly, there is a very well-known general precedent for just this kind of effective knowledge application: consulting. This shows KM to be generally in pursuit of embedding a consultative capability within the workflow of operations. In that way the capacity for effective knowledge usage is enhanced for all other aspects.

KM's most significant difference is that it establishes an environment in which individual workers can more readily achieve their personal performance objectives. From the perspective of environmental engineering, it is more clear that KM's "customer" is the inhabitant worker, and that the key thing KM must give that customer is an improved experience of managing their resources under pressure of corporate priorities.

Personal management of resources is not exactly obscured by job descriptions, roles, or performance evaluation criteria -- but the fact is that all of those representations derive from a deeper set of assumptions about individual execution.

Here, it is important to distinguish the idea of execution from that of conduct and of behavior. Put simply:
- Behavior generally describes activity and especially activity patterns, in a way that is unconcerned with any imposed or external requirements.
- Conduct describes behavior in the context of situational propriety.
- Execution, finally, describes either behavior or conduct, but only from the concern of whether their impacts have motivated progress towards a certain goal.

How should KM be related to those distinctions?

II.

One of the most important background principles is that the individual should be self-directed yet in alignment with the direction of the business circumstance. Here, the "business direction" means both trajectory and guidance. For this alignment to happen, the individual needs high awareness of the particular important goal, the business significance of the goal, and the implications of various means for meeting it.

A second major principle is that leveraging knowledge requires structured interactions between knowledge providers and users. This is at minimum analogous to the existence of markets instead of merely supplies. For the "leverage" to occur, the user must be in a position to change something with the obtained knowledge. The value of the knowledge is logically associated with the value of the change, so the promotion of the knowledge is organized around that value of change.

Those principles make it apparent that KM, as a business practice, should focus on two high-level outcomes: worker position and worker leverage. That is, if KM does not beneficially contribute to those two things, it is not really adding critical value to the environment or to the business.

Most organizations regard position through worker participation in processes, with participation evaluated by the business at the conduct level. In the case of the leverage, most organizations feature prescribed business functions, such as R&D or production or scorekeeping, that are applied in operations areas like sales, services or manufacturing.

As a result of the operational mindset, "methods" and "assignments" are thought to be the initial targets of KM's top-down influence on individual execution. That is, KM is first sought to make people "do better at what they are supposed to do." That execution is an important business goal, but this goal is "point C" and you can't reach it directly from "point A" where KM needs to start.

Here, we're aimed at improving personal management of resources under corporate priorities-- for which the critical operational success factors are not methods and assignments but instead awareness and alignment -- the drivers of voluntary interaction . These are the direct touchpoints that the worker has, anchoring behavior which we can then project across their conduct and execution.

III.

KM makes the assumption that talent in the organization can generate greater productivity through synergies and/or optimizations offered by dynamic collaboration on key objectives. It therefore intends to practically influence the real-time organization of the community of talent.

But we must remember that a "community" is actually the result of individuals electing themselves to the membership. Let's look at the real structure of the knowledgeworker community targeted by KM. Finding the structure means identifying the major dynamics, "benefit vs. risk" style, that surround and involve the individual member of the community at each opportunity for awareness and interaction. KM's affects on these dynamics stage its ability to shape the individual's execution.

Talent versus Internal Competition: the person's predisposition must be compatible with the organization's need for their skills. In effect, "hold-outs" dramatically increase the opportunity costs of operations by forcing a shift of other resources away from more optimal pursuits of advantage and towards what are essentially operational defenses like contingency coverage or repairs. Here, "talent" is a practical idea representing "appropriate skills". Since talent is valued in association with the efficiency of its use, any challenges to that efficiency will virtually devalue the talent; therefore, managers should target removing those challenges -- but meanwhile the talented individual will naturally seek low-resistance opportunities to being prominently employed.
For that, the individual's own tactics to preempt, avoid or reduce challenge need to be simultaneously channeled away from unproductive self-protection and towards opportunity.

Collaboration versus Co-Opting: the person's presence must be highly valued specifically for the purpose of the collaboration. This means that the person's identity needs to be noted much more for their role as a giver or enabler than as a taker.
- Being explicitly associated with successful collaborations must be equally important as, if not more important than, individual credit.

Opportunity versus Confusion: the person's preference must focus on the objectives for which their support is well rewarded. Otherwise, their personal priorities can too easily challenge the priorities behind the deployment of the KM channels. Behaviors themselves must be an objective, not just certain projects or subject matters.
- The individual needs to be able to see, continuously, which personal behaviors are currently being perceived as business benefits.

Those points advocate systematic coordination of:
- the security of the individual's ongoing opportunity
- the public visibility of the individual's expertise
- the pre-approved recruitment of the individual into high-priority areas of business need

But where coordination is concerned, companies typically look at processes and functions to generate the value they ultimately seek from their resources. Less well understood, and less accounted-for, is the ecological effect that the quality of resources has on the environment hosting the processing.

Usually, the connection of resource-quality to operational progress gets most of its attention during a phase of resource-selection and process design. But except when problems break out, the attention to the subsequent execution-quality often overlooks many of the ways that resources constrain, improve, or modify production in tasks and processes. In correcting this visibility, the essential issue to grasp is how (and why) workers apply knowledge in real time to production.

In the table below, examples are shown for how the dynamics in the community can be influenced through cultivating individual persons' adoption of more knowledge-based objectives. Such examples stage opportunities to track influences in terms of an ecology. In short, this suggests how to execute KM, and shows it as being more of a practice than a process.

IV.

In a very important sense, the difference between KM and process management parallels the difference between coaching and supervising.
- Supervision focuses on reliable compliance of activity to requirements.
- In comparison, coaching increases resource readiness and confidence by concentrating on the alignment of capabilities and opportunities.

Looked at that way, it makes sense to ask how an individual's "profile" of predisposition, presence and preference makes them more or less "coachable" through a consultative facility. The more coachable they are, the more chance exists that their personal performance objectives can be coordinated with business priorities.

A view of this might be developed by auditing the profile in terms of awareness and alignment. In turn we can anticipate how KM mechanisms can support improvement in the profile, and thereby set better expectations about how KM will enable the individual.

Along with coaching, support completes the enablement scenario. In particular, various tools can provide KM-support for each row in the main chart above. For example:
- In the Expectations row, tools that generate topologies and ontologies for aggregated information stores are applicable, helping to coordinate vocabularies and ideas around shared standards.
- In the Experience row, Wikis, blogs and knowledgebases effectively promote the link between specified authors and content.
- And in the Expertise row, search engines and dashboards help expose and promote the relative importance of behaviors and ideas to each other and to production.

V.

Finally, a practical expectation of synergies and optimization needs to be established, and supported in an uncomplicated way:
- For synergies, the point is to show that new or unexpected collaborations yield important results on demand.
- For optimizations, the point is to show that knowledge re-use increases the number of instances of benefit obtained from one developed item or source of knowledge.

Having those working definitions, rewarding initiatives related to them, and tracking their example success stories, is the most straightforward way to focus attention on when and how value comes from them -- making them practical instead of just theoretical.

Furthermore, the extent of opportunities to pursue them should be taught. When a collaboration yields an unconventional or unexpected benefit from a given source, that source is contributing to optimization by announcing that its potential as a resource is greater than previously acknowledged -- offering agility and the possibility of eliminating some redundancy. Thus, synergy and optimization can be flip sides of the same coin, and an increase in one might also spur some degree of increase in the other. This should be looked for both in the design of operations and in the evaluation of outcomes.

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

March 9, 2006

Rules that Prove the Exception

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

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

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

Writes Parkinson:

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

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

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

March 3, 2006

Driving IT Bang for the Buck: Evolution, Improvement, or Innovation?

When we think of effective IT spending, we're focused on making the best current use of the money, given competing alternatives or emerging options. But increasingly, the basis of effectiveness in business spending on IT proves to be in how the business manages its reliance on IT.

Sometimes we don't have enough visibility of legitimate alternatives and options. The urgency of our attention to the purpose that justifies the spend means that this lack of perspective could be left unsolved. But for that reason, a diligent evaluation practice looks for opportunity costs that should be factored in. As part of this diligence, what remains to be emphasized even more is not how the IT will make the organization work, but rather how the organization is going to make the IT work.

I.

In the full cycle of management, the business first conceives and identifies why IT is needed before it makes any other decisions. To avoid taking the need for granted, this first decision means describing the business model in terms of what potentials are granted it by available IT. That is immediately followed with a forecast of how sustainable those potentials are -- which necessarily means identifying and selecting how to make them sustainable.

When that architectural aspect is clarified, the next part of the decision cycle must create a "delivery" organization that can constructively practice the architecture. This means two things:
- establishing the sources and resources that will produce the infrastructure from the architecture, and
- establishing the processes that will link IT production cycles to business operating cycles.

At that decision stage, reliable design and reliable production easily wind up being qualifying criteria used to distinguish the various opportunities, organizations and risks that the business will incorporate as the elements of realizing of its model.

Thus, investments in their incorporation aim to relate reliability to the goals of business. That aim immediately offers a perspective from which a high-level assessment of the current business investments might be done. Normally this makes us think of metrics; but as pictured below, the main point is to allow the perspective to stage comparisons and guide questioning. Here we might just catalog known commitments by critical business goals.

II.

Those commitments might then involve or indicate spending on IT. But, as described there and below, the associated "IT investments" are not about IT per se but rather about the application of IT. We can understand the idea of "application" by considering the purpose of the IT utilization.

- At the highest level of distinction, the business goals of incorporating the opportunities, organizations and risks are recovery, health or growth.
- Within each of those goals, sub-goals are development, maintenance, and change.
- And within each of the subgoals, another sub-level features assessment, design, and control.

Consequently, it is possible to ask questions at the management level such as, "Can we control the maintenance of our health?" or "Can we assess the development of our recovery?"

These are not IT questions -- but they are questions that present opportunities for IT to enable successful management outcomes. In turn, management is focused on enabling successful business outcomes.

Taking that framework of IT incorporation as the main perspective, it is easy to appreciate that business utilization of IT is nearly always altering something -- either a behavior or a current state.

The importance of how IT is managed, though, is in how well IT supports management's ability to intentionally change how the business can behave. (From here on we'll consider "change" in this larger context.)

III.

The observation just made emphasizes that we can and should compare the kinds of value offered by different classes of change, and then associate IT's effects to those values -- as contributions.

To demonstrate that, compare evolution, improvement and innovation.

Relative to each other, these kinds of change differently affect the state of the business:
- evolution permanently modifies the fitness of the business's model to the dynamics of the environment in which demand develops;
- improvement modifies the fitness of its conduct to the current and targeted demand;
- innovation modifies the fitness of its output to the needs of the environment's population.

According to perceived conditions regarding recovery, health or growth, business executives must determine when any of these three modes of change requires higher-priority attention. A timely reaction is mandatory, but proactive change is potentially strategic to optimizing the benefit versus risk of those conditions. That may result in new or extended initiatives to create the necessary related sponsorship and opportunity, including competencies and technical support that might drive spending.

To support a proactive stance, a good device to have would be a framework for envisioning, monitoring and ultimately predicting circumstances that we can agree will signify a need for change. Not coincidentally, those circumstances have the look and feel of key ideas offered within the business justifications for IT spending. That device might look like the following:

IV.

But given those considerations, executives and managers together should ask the "big picture" questions -- for example, whether an improvement initiative is the most likely candidate to produce better recovery, as opposed to an innovation initiative. At the same time, it is important to recognize that one kind of change may be an element of another kind and acquire priority that way. After all, form allows conduct, and conduct (i.e., production) allows product. As another more specific example, innovation may accelerate evolution, and improvement may create more opportunity (security, income, knowledge, etc.) for innovation. Thus, an improvement initative can strategically foster the goal of accelerated evolution. But likewise, the requirements for supporting an adopted innovation may obsolete improvement efforts dedicated to earlier production, eliminating that legacy cost while potentially releasing resources for new purposes.

These interrelationships are characteristic observations in portfolio management.

IT management must be focused on applying IT to business operations present and future. On the one hand, it is typical that an IT budget might be evaluated in terms of how much spending goes to "maintenance" versus "R&D" and so forth. Those generic classes correspond to how IT responds to the business requests for support.

But the rollup of dollars into those classes can easily obscure the more important and time-sensitive issue of whether the right things have been selected for maintenance, or the right things are being pursued through R&D. By calling for a distinction between wise spending and merely approved spending, we get to a conversation about how management leverages IT for the business -- as opposed to mere responses. In that conversation business and IT organizations together find the logical path to measuring the effectiveness of the decisions, and to measuring how much that effectiveness was worth.

The view that unifies their concerns is not one about how "IT investments create business value", but rather one that business value subscribes IT.

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

March 2, 2006

Optimizing IT for Business

Business always enjoys the ability to directly engage IT resources as a response to business needs and robust technology markets. The business can directly drive the sourcing and provision of IT into its operations.

But the consequences of that engagement extend far beyond functionality and expense, into the broader ecologies and economics of the organization's health and growth, affecting business value and business risk.

Designing the business reliance on IT as a strategic outcome of resource management requires logically managing the investment of IT assets into models of service governed by accountability standards for business relationships and business performance.

Inserting management into the Business-IT engagement, IT operations create effectiveness on the basis of service capabilities that balance for the business demand and supply (of IT) over designated periods of time within the boundaries of funding levels.
- Catalogs and Contracts prescribe demand.
- Portfolio and Lifecycle management prescribes supply.

Between the value propositions associated with demand (justifications) and with supply (options), standards for practices in sourcing (buy/build) and provision (deploy/support) create more predictable and secured scenarios for balancing costs, risks and quality -- in both the availability of IT enablement for business functions, and likewise in the capacity.

The logical linkage of Services, as established by architecture and agreements, provides a basis for continuous measurement and improvement of the alignment mechanism established between IT impacts and business operations. This rationalizes resource allocations and optimizes the IT enablements of the business.

As a critical mediating influence on the business leveraging of IT, management brought by the IT organization (gray boxes above) sees to it that the business builds it expectations with proven alternatives.

Supporting the business visibility of the alternatives, and controlling the development and delivery of the alternatives, become logically collaborative strategic efforts between the IT and Business organizations.

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

March 1, 2006

BI versus Parkinson's Law

Technologies that can effectively extract management-grade data from the flow of changing operations states have now surfaced in all three main layers of the business structure: resources, functions and transactions.

All parts of the business can now be smarter about the business.

But the danger in focusing on that as an expansion of "the "BI category" is that such a viewpoint does not add quality or maturity to the management disciplines. Instead, it will just increase the complexity and difficulty that a business has in dealing with so-called "BI" solution providers in the marketplace, because their overlapping and competing notions of "intelligence" as a practice will be even more unbounded. Without practice-level discipline, the more BI is said to encompass the less it will mean.

In contrast, consider this: the idea that we can "drive the business" has gone from being just "instrumental" to actually *instrumented*. We can now have real-time mapping of the resources to the functions to the transactions and their impact.

Now that we've crossed that bridge, "navigation" becomes a most powerful model for understanding the probable requirements of an information infrastructure in the business, giving BI a context.

Before thinking about BI, for example, a business needs to understand the difference between its engineering, its navigation, and its governance -- and how to mature its planning and execution capability in each practice.

- Business engineering, for example, would attend to the performance management, business model, and production architecture issues.
- Business navigation would attend to the mission, strategy, and continuity issues.
- Business governance would attend to the alignment of policy, opportunity and change management within execution.

Each of the three major groups has its own needs for management information. Since all of them are likely already pursued by most mid-to-large sized organizations, the question is one of what key information has usually been unavailable to those management efforts on time, making it harder for them to predictably do business well.

Except in some vestigial marketing sense, the solutions to those deficits are not better understood by calling them "BI" solutions.

Rather, we might evangelize the idea that "management" should not be an elite responsibility in the business but instead a competency that is increasingly and pervasively enabled by information processing focused on the business issues. Taking the business management instrumentation everywhere -- such as through BSM and enterprise architecture in IT, or through transparency in Finance and in Process Management -- will make sense to organizations for reasons that they already understand.

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