« May 2005 | Main | July 2005 »
June 28, 2005
Productivity versus Competency
Which comes first, productivity or competency?
If the question is hard to answer, it's because the two things are easy to confuse when we're under the gun. That's a problem because when we don't know the difference between them, our activity can amount to less than the needed achievement, and missed objectives can trigger remedial efforts that actually "solve" the wrong problem.
Productivity, as our pals at McKinsey state it, is a ratio of inputs to outputs. Without having to say more, that points us directly at whatever the process is between the inputs and outputs. Naturally, improving processes would be the right step towards improving productivity. And for most organizations, getting process religion is virtually indistinguishable from their promises to become more "competent". By equating process and competency, this view proposes that competency underlies productivity. Its point of view is about "competently conducting high-quality processes."
But meanwhile, is that all there is to the role and measure of competency? Not really; the scope of its significance is far greater.
The simple, generic difference between process and competency is that a process is a prescribed pattern of activity, whereas a competency is a confirmed ability to act appropriately to the circumstances. This is a case of lurking synecdoche, where it's important to note that a square is a rectangle but a rectangle is not necessarily a square. A process is a way to demonstrate a competency, but competency is not always necessarily demonstrated in the form of a process. In fact, competency can be demonstrated simply by "judgement" -- that is, by decisions that put (and maintain) you in the right place at the right time.
Granted, the intuitive (or at least conventional) ideas of competency are usually about demonstrating that one is "up to the task". But the idea of "effective" is a better way to go to that point. Effectiveness is a determination that must be able to express the value of the result regardless of the mechanism that produced it; thus effectiveness allows a wide range of sources not restricted to competency. "Winning ugly" (a fact of life) tells us that we only assume effectiveness requires competency...
When you get down to it, competency is something that should be understood on its own terms, and only thereafter related to other circumstances such as a particular task or the pursuit of a given objective.
So, let's remove productivity, process and effectiveness from the foreground, and get a good direct look at competency.
One of the most persistent aspects of the meaning of "competency" is "fitness to the occasion", or alignment. This still makes us think about the ability to appropriately execute in the occasion.
But it turns out that the fitness in competency is much more about the kind of solution that fits the problem solver, rather than the kind of problem that is challenging the solver. It's the difference between "being great at using hammers to solve problems" versus "being great at solving problem type X"... There's more than one way to skin a cat, but not all solutions to a problem are equal, and not all solvers are capable of the same kinds of solutions. The key issue is whether the organization is capable of bringing the solution that we believe is most appropriate to the problem.
Considering "capability" as opposed to "task", fitness is a great word because it involves addressing the variables that together describe the nature of a circumstance. Below, the diagram shows the variables that need to be addressed by business competency. The actual competency of a given organization will be the blended capabilities it can bring via innovation, productivity, standards and expertise. The particular blend it brings will be more suited to certain situations than to others, and the challenge is to identify which situations actually "net out" in alignment with the organization given its actual competency. The situations that do align might be visible and interesting to the organization, but they might not -- and organizations can also mis-direct their competency.
The level of abstraction of this framework allows it to be ported across disciplines and to be very scalable to circumstances. The abstraction emphasizes that competency is inherently (internally) established on unchanging fundamentals, while ideally applied (externally) as a matter of reasoned choice.
In the picture, the sides of the square are the characteristics against which the organization positions itself in its target circumstance (e.g., in a market or relationship), while the corners are where (and how) requirements are met. In effect, the corners link the sides together in issues that the organization should address to assure relevance or fit, and thus set up to drive value.
Failure at the corners is risky -- it leaves the relationships of the sides arbitrary or irrational, and it makes the organization's offerings to the sides unpredictable and/or unproductive. Accordingly, in the organization's current circumstances, such difficulties should be examined as if they are symptoms of failure at the corners.
The sides must be developed as well: poor determination of the sides will result in a mis-fit or disoriented organization.
Techniques for improvement at the corners and sides are varied, including learning, collaborating, partnering, and others... Those capability-enhancement techniques may themselves be executed through processes that are developed, measured and matured through improvement initiatives.
Consequently, for most organizations, a combination of a capability maturity model and a scorecard is great instrumentation (yet not exhaustive) for managing competency. Typically these are employed in "performance management" efforts. But in light of the above, it is clear that the overall goal is to be able to pre-emptively gauge risks to effectiveness.
Thus we understand that the competency issue is not fundamentally about productivity, but instead is about risk management. And in turn, the riddle is solved: productivity and competency are complementary but they are not causally related; instead, they are correlated.
Posted by Malcolm Ryder at 8:08 PM | Comments (0) | TrackBack
June 27, 2005
More on "Great Management versus Great Strategy"
Recently, in so many words, I posed the question, "what good is strategy without great management?" However, my not-at-all ulterior motive was also to question whether management knows what it is doing if it is operating without a strategy.
Results rule, we can usually assume -- and they come with or without strategy. But whose results count? Certainly, there are stakeholders and shareholders whose view of things is all about their own respective benefits; their stubbornly dominant perspective on management is quite tolerant of "collateral damage" (namely, to other stakeholders) in pursuit of what is called "performance". The question of delivering gains gets strategic for these stakeholders mainly when they wonder if they should stick around for a while, exposing themselves to the same risk they ask of others. "Can management deliver gains twice in a row? Will management sacrifice me twice in a row? Somebody show me the plan!"
That triggers scrutiny of management. Plan the Work and Work the Plan has been a "performance" mantra for decades, and managers are hired to make sure that it is followed. Inside the company, their efforts are rolled up into an idea of "performance", but often not until after their impacts have been rolled up in a different way outside of the company.
The external focus on impacts is unavoidable, but ironically it can readily make internal performance an avoidable topic or make its evaluation arbitrary. To counter this, we keep internal management in the foreground by asking:
- what is the importance of managing internal performance?
- what are the critical factors of the manageability of internal performance?
These are not new questions, but now there is "buzz" around the idea that "execution is more important than strategy", and performance management is exploding into view as the biggest new "must-have" since CRM. This makes it feel like the labels management, performance, and execution are all the same thing.
Well, look at life from the manager's point of view: with a modern business's relentless pursuit of cross-functional operations, too many managers can't really say that they had enough control of either execution or strategy to be held accountable for it. Sitting in the hot seat of being evaluated, managers want to know how to protect themselves, and now they have the solution for that -- performance management.
Arguing and establishing the A-to-B connection, between (a.)internal compliance to plan and (b.) external compliance to impact targets, is certainly not a new activity. A quick run through Google Scholar picked up "performance management" references from 1988 and real enthusiasm by 1999. But perhaps what really is new is the idea that the effort-to-impacts connection would be continuously attended and continuously evaluated, rather than just occasionally or incidentally. In effect, the change of attention is from being reactive to being proactive -- even moreso as a mentality than as an activity.
So what does this have to do with strategy? The main point worth making is that the suspicion or proof of a performance connection is not the same thing as the preference for or value of that connection. For example, what does it mean to be really good at doing the wrong thing, or doing the right thing badly? Comprehensive management makes for doing the right things right. A judgement call backed by action.
Strategy is a management discipline that attends to the responsibility for formulating a logical vision of deriving benefit from conditions carrying risks. Managing strategy is about ensuring that this vision is logically strong instead of weak, and highly usable instead of irrelevant. A strategy is an input to operations. It might even be enforced in a way that makes it a cause.
Then comes management's responsibility for effects. The "opposition" to clarify is therefore not about strategy versus execution, but instead between two aspects of results: performance and value.
This is not a complicated distinction. In a situation of multiple stakeholders, where benefits are not equal for all, a given performance has a different value for one stakeholder versus another. Even when there is only one stakeholder, a given performance at one time may have a different value than the same performance has at another time.
Strategy helps set terms in value management. By making the relationship of multiple values explicit in a variety of ways (priority, timing, context, etc.) strategy helps to establish the criteria and points of view that will be used to manage values with and against each other for designated stakeholders. (For example, an obvious manifestation of this is a portfolio derived from a strategy, with the portfolio being the main instrument for ongoing value management.) As a result, typical signs of strategy's influence are policies and initiatives. Imagine trying to manage without those!
As opposed to value management, performance management focusses on the means and modes of progress. The accountability for progress is defined in a model of progress -- different from a model of value. Because a model is made available, it can be used both prescriptively and descriptively. The progress model -- usually a scorecard -- presupposes that values have been determined, and it does not attempt to change them. However, it provides the opportunity to examine how the means and modes in use are most associated with the paths towards the value. The stepping stones of the path are usually "key" conditions expected to be necessary for the value to be obtained. The typical manifestations of managing the means and modes are operational processes and practices, but what is the primary influencer from which the scorecard is derived and which processes and practices manifest?
Probably half of the time or more, real-world testimonials answer that strategy, again, is the influence. Count on two-thirds or more cases citing either "strategy" or "mission". But understanding the difference between value and performance gives a strong clue that such cases, examined carefully, would actually show evidence of a difference influence found common to all scorecarding instances: a competency framework.
The company's idea of its competency is equally important as strategy because it brings the notion of what the company should be able to do, while strategy brings the notion of what the company needs to get done. Understanding that strategy is about management engaging values, while performance is about management engaging competency, the semantic confusions of management-vs.-strategy or execution-vs.-strategy dissolve.
For many companies, perhaps the excitement of the "execution" problem is that the business environment has brought the challenge of constant change deep into the organization, changing competency from something like trained muscle memory into something a lot more like the nervous system. Learning to do the right things, on time, renews competency as the frontier of performance.
Posted by Malcolm Ryder at 9:33 AM | Comments (0) | TrackBack
June 26, 2005
Can Collaboration Improve Processes?
Processes live on the communication of critical information about events. Can collaboration do for processes what infrastructure does for systems?
We normally rely on "process" to maximize our chance to leverage a perceived opportunity. Yet sometimes the process doesn't get the job done for us. A mismatch of some kind occurs between what the process can deliver and what satisfies the requirement of the situation.
Knowing that can happen, we've all had moments when we could use some extra help, but the help that was available wasn't the help that we wanted, and we faced a trade-off. At times like that, our instinctive aversion to risk often overrides the willingness to change for gain -- and either we fall back on an existing substitute approach or we let the opportunity go by.
In the parlance of value and performance, that's a comparison of opportunity cost versus effectiveness. At the trade-off moment in the scenario, we're "forecasting", not experiencing, both sides of the trade-off -- pain versus gain -- and this means that the expectations we form become the virtual reality to which we respond. We pin our sense of "effectiveness" on the expectation, and the risk is that we'll therefore underachieve.
Effectiveness is really a measure of how well opportunity has been exploited. But because our ability to assess opportunity cost shapes our perception of opportunity itself, it changes what we think we can do. Consequently, that assessment ability is actually one of the decisive terms of our probable ultimate effectiveness.
What does this mean about process? When we feel that we need help beyond the current process, we are usually thinking either that:
- the process requirements are beyond our own range of ability, and/or...
- the opportunity requirements are beyond the range of the process.
It follows that when our operation is hampered by either of those problems, the two main types of help are:
- bringing added execution capabilities to the process; and
- supplementing the process with "more processes".
What we have to realize is that in either of those two cases, something other than "process" might be the missing piece of our effort. How does the missing piece change things?
The essential purpose of a process is to make causality manageable and practical. But in order to get effectiveness from this, the results of the management must be relevant to the occasion at hand. The occasion asks the process to make certain things happen, and the process must leverage available resources to generate appropriate results. The available resources are, in effect, the environment of the process.
This is similar to the relationship between a system and its infrastructure. A system manages the interoperability of components, but this succeeds only because the system can draw on an underlying infrastructure that supports the system's functions. The infrastructure is the "environment" of the system.
Improving the supporting environment can add more execution capabilities. This can be approached in two ways:
- enrich the environment so that it offers more choices that are useful to the process or system; or
- optimize the environment for a particular process or system.
In the case of processes, how is that done? Looking under a process, the main visible infrastructure elements are knowledge, instruments, agents and rules.
Knowledge: brings the ability to proactively determine the likely impact of choices and conditions
Instruments: bring the tools appropriate for making decisions and for manipulating conditions based on decisions
Agents: bring the positioning and skills necessary to leverage conditions towards targeted states, primarily through use of the instruments
Rules: bring the terms of acceptability for types of actions per condition.
Systemically blended, the four elements create a process component that can convert a defined type of input in a predictable way. Correspondingly, because the conversion is predictable, the output may also be predictable.
But the essential responsibility of a process is to do the input conversion in a certain way, not to generate a uniquely specified output.
That sounds wrong, but we know it is actually true -- because experience has already shown that for us to obtain a specified result our own current processes are not the only way:
- there is "luck";
- there are alternative processes; and...
- beyond luck and process there is "service", where someone else handles the issue altogether in a way we are not responsible for...
The main reasons we use processes ourselves, with the responsibility for their output, are:
- to minimize uncertainty, and...
- to maximize autonomy.
Thus, if we run into a process deficiency, and we need to improve effectiveness in the face of the pain-vs.-gain trade-off, then certainty and autonomy are at stake.
In general, infrastructure supports the process vis-a-vis uncertainty and autonomy.
- For minimizing uncertainty, infrastructure features "configuration" that assures conditions critical to relating targeted events internal to a process.
- For maximizing autonomy, infrastructure features management control of the resources needed to maintain the components of the process.
With those effects, the process assurance fortifies its permission to execute -- a privilege often dependent on whether the infrastructure is tolerated by the customers and sponsors of the process. (For example: some consumers won't authorize delivery through ground transportation; some programmer/analysts won't authorize processing through a certain database management system; some messengers won't authorize transmission through a certain channel; etc.)
This is the context in which we should consider the prospect of collaboration as an "improvement"...In terms of processes, will collaboration have to help minimize uncertainty, maximize autonomy, and leverage permission?
The key thing to keep in mind is that the goal is to improve the effectiveness of the process, not necessarily to change the process itself.
By improving the environment of the process, its effectiveness can be improved. Collaboration can improve the process environment by making the management of resources better for the process.
By definition, collaboration means that two parties are working together (co-labor). In using collaboration for process effectiveness improvement, the point of the collaboration is to have the different parties each become part of the same process by their literally "co-operating" the process towards the given goal.
Defining responsibilities is a critical part of designing systemic co-operation. This design directs how the underlying elements are blended to generate the process components. In this co-operation, collaboration specifically begins when the roles of individual parties are accountable for the elements that make up process components: knowledge, instruments, agents and rules. Responsibilities then relate the roles to each other as a "process infrastructure".
To increase effectiveness, collaboration can attend to supporting multiple processes, and/or it can support optimizing any given process to certain requirements.
In particular, process optimization refers to the process being able to dynamically select and orchestrate the best resources for operating against real-time requirements. As a managed activity, collaboration is part of that orchestration.
By leveraging the availability and scale of a larger community of resources, collaboration produces an infrastructure (i.e. functional environment) in a way that allows the process valuable freedom from customary constraints of resource availability and scale that otherwise might leave the process short of capability to fulfill real-time requirements.
Posted by Malcolm Ryder at 6:41 AM | Comments (0) | TrackBack
June 25, 2005
Architecture and Strategy
Architecture designs spaces for functions.
Strategy designs functions for spaces.
OK, on with the show.
Posted by Malcolm Ryder at 11:33 PM | Comments (0) | TrackBack
The Net of the 'Net
Guilty of hunting most of my news-before-lunch online, I pushed through and out of a thicket of links into a cool breeze of clarity in IT consultant George Spafford's article on the net present value of a network (available through the JupiterWeb / Earthweb.com syndicate).
Spafford puts a stake in the ground: "we can safely assume that for any network, only 20% of the nodes will create 80% of the value." But on his way there, he points out (even more importantly in my view) that any node on a network can be counterproductive as well as productive, and if productive it can be in many ways.
That means the value produced through the network has to be developed, through decisions that determine when, where and why nodes behave the way they do. The variability of these decisions is the network's potential range of productivity.
Fully appreciating what this means, it's important to not think of the network in terms of something bounded by its physical components. Instead, the network is an environment to be managed, and the value drawn from the network is the "return on management".
That said, what is the virtue of a network, as opposed to other forms of environmental organization? For example, if a network is not the same as a "system", what is the particular distinction behind its design?
The important difference is what essential types of functionality the design pursues.
Systems are designed to be self-contained, drawing effectiveness from the fact that they are securely bounded, which allows for predictability of functional efficiency based on controlled processing of fixed resources.
Networks are designed to find resources, drawing effectiveness from the fact that they are not physically bounded yet provide control of how resources are found.
Seing systems as being resources allows us to envision making a network that finds and connects systems, and naturally explains a division of labor between network management and systems management.
As we continue to explore different types of networks including technology, society and processes, it remains always basic that the productivity and value we imagine is invariably due to the integration achieved within the network, through management.
Different environments have differing ecologies, from which productivity and value are derived. For example, we know that a tropical island environment offers different opportunities and methods to generate value than does an inland desert.
These ecologies are not just circumstantial constraints but instead are the cultural level on which management must also be conducted if any pretense of sustainable value-generation is to make sense.
And so it is that in any network, a culture becomes the "boundary" or domain of the value that may be obtained. Meanwhile, a network can host multiple cultures. Any determination of the network's value must acknowledge that the evaluation presumes certain preferences about which cultures should be hosted and how they should co-exist...
Posted by Malcolm Ryder at 9:55 AM | Comments (0) | TrackBack
June 24, 2005
A Purpose Driving a Performance
The triple-take I did today when reading through InformationWeek might have come from not paying enough attention to the headline of Stephanie Stahl's Editor's Note on CIO priorities, Customer Focus Promotes Growth; but on fourth thought, I think not!
A lot of us are accustomed to hearing that customer focus is a strategy. And although the idea that strategy promotes growth has lost some cache in the age of Execution, there are those who still believe it. Certainly there's momentum still behind thinking of growth as "good performance". Thus, the argument that strategy stokes good performance.
But according to the article, Michael Treacy of Gen3 Partners had recently warned the audience at the Optimize CIO Summit that "The best management team beats the best strategy every single time." And the followup advice: commit everything you do to customer value.
Take One: okay. When is a "strategy" not a strategy? What Treacy seems to be doing is drawing a competition between commitment (organization? action?) and planning (ideas?)... By saying the Best this or that, he hasn't given any company a leg up on any other, since every company must be managed. So instead, how about great management beats not-so-great management -- and the real question is, what makes management great? Is it the guidance received from a strategy, or is it the guidance from something else?
Take Two: What if the purpose of strategy is actually NOT to drive "performance" ?? One thing we know about strategy is that when you do have one, you have a consistent, goal-oriented perspective from which the running states and events of the business are evaluated. But the perspective is a hypothesis, essentially, about how things work to your benefit, and the point of the strategy is to encourage a pervasively consistent logic in decision-making. Reality keeps testing that hypothesis, though, and eventually you find out if the hypothesis was "correct"... Is Treacy saying that management is about doing something that connects with a reality that is more influential than strategy? (Sidebar: I'm reminded that Columbus had a theory about how to find what he was looking for. His theory was wrong, the world's not flat; but he "managed" reality, and wow, look what he found. The question is, what's the chance he could count on a payoff like that twice in a row, using a bad theory? Let's just say, with our excellent 20/20 hindsight, that we'd let him cruise a small planet, but we wouldn't put him in charge of the space station rendezvous...)
Take Three: If pervasively consistent logic can be had from something other than strategy, is it the management team that is the source? If yes, maybe what's being put up front is Leadership, which is not the same thing as strategy. Meanwhile, I can't help but notice that strategy and leadership are both forces of Alignment.
But being customer-focussed does not magically "turn managers into leaders" -- and if growth comes from customer focus, maybe it's because (and only when) leadership is strong enough to draw growth from customer focus...
Which leaves me with three thoughts:
First, what the heck would make a strategy a "best" strategy if there was not correspondingly great management available to back it up?
Second, certainly there are leaders who mainly try to draw growth from strategy. For those who see customer-focus as a strategy, they're also likely engaged in using great management to draw growth from the strategy. Maybe a "contest" between strategy and management is only happening when the leader feels it and feels like one of the two must change.
And third, once again, what makes great management great? Well, just try to find a great management team that doesn't have great communication. And what do they talk about? The same things that a strategy would ask them to talk about... Why is this so interesting? Because one of the top reasons that senior managers and executives voluntarily leave their positions is that they feel their views are not being taken seriously. And what is the focal point of reconciliation of divergent executive views? Strategy.
Posted by Malcolm Ryder at 4:04 PM | Comments (0) | TrackBack
Managing Knowledge in the Knowledge-based Business
Although few businesses immediately think of knowledge management as an extension of ERP, many kinds of enterprises have come to see their captive knowledge as a top-priority "enterprise resource" that must be managed.
The path they've travelled to come to this stance has been as varied as the types of operations they use to gain and hold their market positions. But two approaches stand out quite prominently amongst them all -- the "human capital" approach and the "process improvement" approach. Convergence of the two is increasingly dominant, as big companies rediscover what good small companies never forget: the process works because people bring knowledge to it.
As the well-known stories have put it simply, the rediscovery has often been a surprise:
- a business may have learned the hard way that the most valuable "asset" it has actually walks out the door every night at closing time; worse, a competitor stole a key player whose know-how made them the go-to player.
- the implementation of a great idea dissolved in the face of employee resistance; you can take a horse to water, but you can't make 'im drink...
Lessons learned from those experiences promote knowledge to the top of the list of critical success factors for productivity and value, and emphasize a need for coordinating the management of knowledge assets and change. This idea leaves a lot of details to be figured out, and that means a company has to find a motivation for not just starting it but keeping it up and seeing it through. Hopefully, we then can look at the highly motivated ones for a history of trials and errors that can teach us how it should be done.
When knowledge is actually your main product, could there be any greater motivation? Even so, KM can be elusive. This idea is behind the work of some key business analysts such as Bruce MacEwen, whose blog "Adam Smith, Esquire" routinely examines and advises on the problem of recognizing, planning and leveraging knowledge management opportunities and objectives in law firms. Always attentive to the people issues of KM, Bruce surveys KM evolution in articles such as:
KM, Meet "Peer Production" [my vote for the "must read" group]
Knowledge Management & Uncharted Professional Networks
What KM and Legal Outsourcing Have in Common
and...
Who You Know or What You Know: How About Both?
Try this trick at home.
Posted by Malcolm Ryder at 9:49 AM | Comments (0) | TrackBack
June 22, 2005
Managing the Productivity of Knowledge Work
Co-founded by a group of organizations including Accenture, Microsoft and Xerox, the Information Work Productivity Council drives a sustained collaboration intended to build a framework that measures productivity in "the information-centric business environment of the 21st century."
Early research released from the Council stresses the importance of some evolving ideas for understanding productivity in "information work and knowledge work" through a combination of lessons learned from manufacturing and I.T.
However, Accenture's Institute for High Performance Business emphasizes that a definitive reference model for measuring this productivity is still not on the horizon. And the IWPC itself states, "Although recent surges in productivity have been attributed to the use of IT, we still have no effective way of measuring or verifying its impact on information work."
In no small part, according to Accenture, this is due to ongoing debate about what to include in the kind of work being scrutinized for productivity, even including a sense that the popularity of the term "knowledge worker" might be missing the point by arbitrarily discouraging attention to equally important issues of information-based productivity.
But while Accenture makes those comments with a view on the internal needs of a given single business organization, I think it is absolutely necessary to step beyond that and propose that the "industrial" landscape of 2005, compared to the landscape of 1985 or 1965, quite loudly demonstrates increased "productivity" in the form of 2005's awesome diversity of types of viable business attributable in the main to business IT adopted in the last few decades. Proposed more simply, IT productivity really manifests itself at the market level moreso than at the enterprise level. Likewise, "knowledge productivity" manifests itself at a higher level than operations, in the form of a sustainable diversity of fully viable business capabilities. Discuss...
The intensity of the "productivity" investigation is certainly not at all in doubt, but the majority focus is on a somewhat different point, as both executives and academics are going "all out" to credibly factor the business reliance on information work (including knowledge) into the equation for business value and business valuation. That effort (and accompanying debate) would account for how knowledge work affects the conventionally measured productivity of a business's company.
Nothing strikes me as more certain to inhibit the effort as would a failure to unravel semantic confusions that inspire solving the wrong problem. Credit IWPC for stepping on that same stone, but in my view what follows from that point is a brief sprint down a course of resolution different from IWPC's -- not to a necessarily different or further endpoint, but in an alternate direction at least for the time being. My premise: there should be a view of the productivity of the actual work itself, providing a precedent baseline logic establishing why and when the work contributes to the productivity of its consumers and beneficiaries. In particular, I'll focus on knowledge.
1.
To begin, let's presuppose the reason behind our certainty about the criticality of knowledge in the modern business.
The fundamental operational issue for the business is to maximize opportunity at minimal risk, and to convert the opportunity into necessary benefit at minimal cost.
Correspondingly, utilization of knowledge is needed to, and proven to, impact opportunity in three essential ways:
- accelerate its development;
- differentiate it; and
- secure it.
Meanwhile, utilization of knowledge enhances the foresight and awareness of risks and costs pertinent to the opportunity.
The elaborations of that utilization are seemingly infinite, if accounted for by the organizational variations of one company to the next. However, the principles for the utilization do not change from one company to another, which means that there is a common reference regardless of the commonality of practices.
2.
The next presupposition, however, is the most critical one to my direction -- namely, that the term "knowledge worker" is NOT a synonym for "information processor".
IWPC's namesake distinction of information from knowledge is an important precedent for including "information work" beyond "knowledge work", signalling the belief that really meaningful talk about productivity requires an expanded field of terms. But a more fundamentally important observation to make is that "processing" is work, and that knowledge workers are process managers.
The key question is, what processes do knowledge workers characteristically manage? What's necessary here is to answer the question the right way, assessing the activity being conducted instead of the department (e.g., marketing or finance) commissioning the work. And this activity can be assessed in terms of knowledge, without the expansion into "information work", as follows.
This next short list highlights the distinction that is most relevant to the business issue of knowledge work productivity. These processes have outputs, and the business challenge is first to understand the significance of the outputs and second to understand the practical options for optimizing the generative processes:
(1) Strategics: a term coined here as a placeholder, this is mainly the interpretation of projected conditions with the goal of modeling their relationship to objectives.
(2) Heuristics: this is the use of a hypothesis as an instrument of iterative examination.
(3) Diagnostics: this creates and applies systems of identification and classification to distinguish the constituent elements of conditions and entities.
(4) Forensics: this discovers and determines items as relevant elements of a proposition that is a candidate "fact".
Then, the important consideration is the matter of how those activities are proceduralized, such that their respective underlying methodologies become portable to other workers. Logically, this is one of the responsibilities of the individual knowledge worker: initially adapting the activity's methodology to the real environment for operations. This adaptation is the basis of the activity's effectiveness. But the adaptation can also be assisted and formalized, to increase the efficiency of applying the methodology by the given worker. Any external assistance can be considered an "input" to the management of the processes.
Here, another distinguishing point emerges regarding direct measurement of knowledge work's productivity. The person identified as a "knowledge worker" could be evaluated as a "resource cost" -- but that type of evaluation is likely arbitrary without comparative benchmarks that describe the same activities and assists applied to substantially similar circumstances. In effect, the "resource cost" view presents the "knowledge worker" as a kind of function, for which availability and quality are actually the key measurable characteristics. But in that case the productivity issue derives from the management of the worker, not from the worker's own effort. We still want to understand the worker's effort itself.
3.
What really matters to business improvement is the impacts of the knowledge processes. For example, there are two basic categories of significance holding four types of results that should be treated as target business outcomes of the knowledge work:
- (impacts related to liabilities) risk mitigation and lower opportunity cost
- (impacts related to benefit) quality certification and innovation
As the source of these impacts, the knowledge processes managed by the worker thus protect and expand the business's measurable ability to affordably create and capitalize on opportunity. This means that, when successful, they produce a new "resource" of greater value than the business's ingoing investment in acquiring, deploying and maintaining the knowledge worker as a resource. That defacto statement of ROI addresses the motivation behind executive attention to the improvement of knowledge work.
Posted by Malcolm Ryder at 9:33 PM | Comments (0) | TrackBack
June 21, 2005
Strategic Factors in Managing Performance
The working definition of "performance" takes hold for managers in the ability to define desired effects and to measure degrees of achievement towards those effects.
When it comes to achievement, the organization has two basic outlooks: prospective or forward-looking, and retrospective or backward-looking.
Putting those perspectives into practice, an organization approaches the issue of achievement primarily through motivation and accountability.
Motivation looks prospectively at achievement, with emphasis on establishing an awareness of why what we do is valuable and how we are identified with that value.
In general, a value system represents "necessities" and "priorities" as understood from a certain point of view or major objective. The main challenge is to establish agreement to the objective by all key players, even when not all players have the same stake in the benefits (and risks) of the agreement.
Accountability looks retrospectively at achievement, with the goal of identifying how achievement was developed from operations.
As with other types of development, design and testing of the achievement are fundamental to assuring the quality of the final executed result.
With those factors in play, organizations are often put in a position where the chance of maximizing actual performance originates in the organization's ability to make and "sell" strategic policies to its constituent members, and to likewise make and sell strategic processes to them.
Policies represent the agreement to the objective. Specifically, policies represent the company member's commitment to be self-governing in terms of the objective. Policies include the protocol and business rules that characterize the "sense and response" posture of the organization to its circumstances. As seen in organizations -- especially teams -- that rise to the occasion during crises or competition, the ability to rally around and rely on a sense of identity and purpose originates in a cohesiveness that reflects a common sense of what matters and how to execute on it. Policy is the container of that common sense.
Processes represent the methods behind the achievement. Specifically, processes represent the integration of skills and knowledge to organize control of the quality of achievement and of each individual's contribution to it. Processes explain how people get to make things work.
The irony of performance management is that so often it is dominated by measurements of effects instead of measurements of causes. Effects must be measured, but the effort to get future effects to match or exceed them requires acuity in the observation of people's experience of identification and inclusion .
Because operational performance is so largely dependent on people's identification and inclusion, performance improvement and optimization should logically be focused on improvement in the supporting policies and processes.
Related to that, experts agree that two critical approaches to fostering greater motivation and accountability are, respectively, collaboration and performance modeling.
Collaboration proactively incorporates multiple points of view into the goal of creating agreeable policy, by making the creation co-operative. Performance modeling clarifies the logic of cause and effect while communicating how requirements relate to individual contributions. Together, they increase the sense of empowerment within the organization.
The most important point to make about using these approaches is that collaboration applies to both motivation and accountability, and likewise modeling applies to both. Collaboration negotiates rules and roles; and modeling relates them both. Both collaboration and modeling allow the organization's members to perticipate in the actual envisioning of the mission and the operations that will execute it.
Meanwhile, a key observation to make is that neither collaboration nor modeling is dependent on measurement, but both may generate measurements. As real-time management touchpoints, measurements allow practical monitoring, which affects the decisions that constitute management.
Posted by Malcolm Ryder at 10:13 PM | Comments (0) | TrackBack
Harvesting Tacit Knowledge
Most experts in the knowledge management arena have special interest in the problem of "tacit" knowledge. This collection of knowledge, which is the knowledge residing in people's heads and not externally documented, is generally considered to be the "largest amount of knowledge" contained in a company.
Considering that people enter the membership of a company largely due to the knowledge they demonstrated or professed aforehand, this can't be a surprise, and indeed it isn't treated as one.
However, what becomes freshly intriguing about that knowledge is that it has a largely unleveraged lifecycle in the company.
That is, despite hiring practices and process-guided daily operations that drive deployment of an employee's knowledge:
- much of what is initially available for use is not used;
- much of what is then added to it is untracked and unnoticed; and...
- much of where the additions come from is not premeditated as a source.
In fact, this means that we really have little idea as to what the population knows overall, which certainly questions the idea that "most" of the company's knowledge is tacit.
Furthermore, assuming some degree of overlapping (redundant)knowledge, immature knowledge (incomplete), and misinformed knowledge (incorrect), we might wonder how much of the total tacit knowledge is worth keeping and using, and whether in fact the amount that would survive such a vetting is greater than the explicit knowledge collection or not.
We still don't have the magic wand that let's us see the total inventory of tacit knowledge. And let's face it, taking that picture would have to turn into a movie, not a snapshot, akin to filming the waves on the ocean. So how does it make sense to compare the two sets of knowledge?
Obviously, one term of comparison looks at whether the knowledge in question is "effective" knowledge. In order to be effective, the knowledge would have to satisfy some minimum criteria that are probably beyond debate, such as:
- being conceptually relevant to the particular user's task;
- being credible in a way that can be validated; and,
- being obtainable at an expense that does not exceed the value of its usage.
Even those three "tests" pose a significant burden of accountability on a person making the evaluation of effectiveness, since in each case there is potentially huge variety in the characteristics of the situation that qualifies the knowledge. For example, how big is the range of knowledge users when considering the difference in their intellectual proficiencies? What mechanisms can and should be used to validate the qualities of the source of the knowledge? And how is value defined for the application of the knowledge at the time it is applied? While those are issues that have already found numerous important solution approaches, they testify that for the measure of effectiveness, one size solution is unlikely to fit all.
An even more fundamental problem of identifying "effective tacit knowledge" is the problem that the main repository is people -- about whom we can say only one thing for certain: everyone has four conditions related to how they are "knowledgeable", both tacitly and explicitly:
1 - being aware of what you do know;
2 - being aware of what you don't know;
3 - being unaware of what you do know; and,
4 - being unaware of what you don't know.
Right off, we assume that we'd like to go get the knowledge available from conditions #1 and #3. But conditions #2 and #4, which involve missing knowledge (not just tacit) are equally important for knowledge management to address, because the nature of personal involvement in an organization is that we continue to have new experiences that can change us and change what we pay attention to. The related business issue is that so many instances of missing knowledge are tacit instances, escaping notice and therefore having unmeasured impact on processes and decisions.
So overall, the challenge isn't to just circulate things that are not in broad enough circulation yet, but rather to cultivate knowledge availability in a way that promotes both progress and benefits in all four conditions or states of knowledgeability.
What should be happening in each state, to properly manage the potential knowledge utilization of the community?
Without declaring a definitive answer, the following illustration points in the direction of an implementation of knowledge management functions that should be considered.
From left to right: By facilitating 24x7 capability to conduct a relevant action for each state of knowledgeability, processes are fed to evaluate the situation. These processes respond with a function that generates enhanced resourcefulness from the situation by refining the knowledge and directing its flow through key modes of community-wide access featuring references, alerts and coaches. Successful KM will further try to motivate action at the left and market availability at the right.
Posted by Malcolm Ryder at 1:00 PM | Comments (0) | TrackBack
June 19, 2005
Evaluation versus Value
Evaluation closes the loop of management activity that begins with idea definition and continues through design, implementation, operation and support.
Following and actually overlapping "support", "evaluation" determines when the effects of operation are complying with initial standards and objectives, and whether the effects are compatible with requirements that have emerged and become newly current during the elapsed time of the idea's actualization and employment.
For managers, that current compliance and future compatibility mean something primarily because of the initial justification for the idea being actualized. This justification is often simply called the "baseline", and one of the primary goals of evaluation is to generate information that supports decisions about how to respond to changes from the baseline. As a result, performance information feeds change management to protect value.
Normally, the justification is a description of "value" to be gained by realizing the idea. Compliance will mean that the terms of the original justification are being met, but compatibility to new requirements means that expectations about future value are still reasonably positive.
An evaluation that cannot include both perspectives -- that is, of original and current expectations -- is at least incomplete, if not downright suspect. For example:
- an evaluation based only on the (earlier) original expectations might describe work done properly to produce something whose intended impact is no longer possible or relevant by the time it is actually delivered.
- an evaluation based only on current expectations, ignoring the previous forethought behind how the current conditions developed, might mistake a presently mismatched organizational stance towards requirements for a lack of capabilities instead of a lack of direction.
Another problem in evaluations is confusion about what approach yields information of the right type of importance. For example, these three following approaches are distinctive enough in purpose and capability; they can and should be complementary but are unlikely to successfully do each other's job:
Assessment - a determination of what kind of value should be associated with something, not just how much something is worth. In determining what kind of value, the assessment process examines how something actually creates value, and/or how it fails to do so.
Measurement - a determination of the degree to which something has a given quality or property.
Analysis - a determination of something's constituent parts and especially their inter-relationships, explaining a particular characteristic of something.
As an example of why these must be correctly used, look at the common need that organizations have to conduct performance assessments, performance measurements, and performance analyses. Casual conversation might use these three terms interchangeably, but in actual practice they will not correctly provide the necessary decision support if misused.
A performance assessment should investigate, and report on, the likelihood that an operation can meet the demands of given types of requirements. Along with this, but regardless of what current requirements are the established ones of record, a performance assessment should expose what types of requirements the operation is most likely constitutionally fit to meet, based on knowledge about how such requirement types have been successfully met in the past. This is usually where notions such as best practices are referenced.
A performance measurement should investigate and report on what level of compliance the operation has achieved regarding specified target levels of impact for certain types of impact. Typically, benchmarks are referenced in measurements instead of elsewhere.
A performance analysis should investigate and report on why measurable performance levels have occurred, regardless of what the measured levels are; then based on the reasons why, the analysis should predict the levels and types of performance that are most likely from the same dynamics. Forecasting is usually expected here.
However, the three approaches are complementary:
- Assessments and Measurements can share categories
- Measurements and Analyses can share data
- Analyses and Assessments can share models in common.
Taken together, the three approaches provide a complete reference for describing the relationship of operational effects to the objectives that for managers represent creation of value.
A full evaluation that includes assessment, measurement and analysis will give a description that traces the logic of what is actually happening in a way that accounts for expectations. In that way, managerially practical comparison of original expectations to current expectations should be possible, identifying the underlying conditions that are shaping or being shaped by operations.
Posted by Malcolm Ryder at 7:41 AM | Comments (0) | TrackBack
June 18, 2005
Strategy and the ROI in Change
Strategy moves from being an intellectual awareness to a progressive practice when strategists describe strategy in a way that describes manageable processes of the business.
However, this does not simply mean translating strategy into operations.
Instead, "strategy" is the model for the ROI in Change.
By definition, all "change" involves a comparison of states.
In strategy, Change is a difference (of states) described in two dimensions: impact and risk.
Regarding impact: the difference in states is between the currently expected state and the future actual.
Regarding risk: the difference in states is between the preferred normal and the allowed incidental.
Strategy acknowledges that you have a stake in changes, and it expresses a theory of how you structure and leverage your stake for benefit.
This commitment to change is essentially an investment, and strategy models the return on that investment.
The model for the ROI in Change cannot be reliable if "ROI" itself is misunderstood. The essential observation to make about ROI is that the "return" comes as an asset that is a potentially more valuable resource than was the resource consumed to produce it. Famously tired and dry arriving at a roadside hotel in a strange town after midnight, I was desperate for a soft drink from what incredibly was the only nearby source - a vending machine that took only coins, of which I had none! The sixty-five cents in coins that I bought from another late traveller for a dollar bill was worth far more to me than the dollar bill.
Strategy models an ROI by coordinating highly plausible differences into a pattern that is manageable.
To do that, strategy must find a way to identify differences as resources and design a process that converts them. This is basically what is meant by "seeing change as opportunity".
Strategy research takes responsibility for formulating the terms that identify the differences -- including current expectations, future actuals, preferred norms and allowed incidentals.
In the language of forecasts, targets, standards, and exceptions, strategy recruits management practices to critically intervene in the course of events and relationships, making them resources.
Much of this intervention is seen in practice as discipline, for which numerous aids are employed including methodology, processes and automation to improve execution.
But the emphasis on discipline too easily makes the strategy seem to be the product of the discipline, instead of the discipline being a service for the strategy.
Creative interventions, focused on the findings of strategy research about change, are an ideal goal of operations but too often current operations are a protected resource themselves, unavailable for "unusual" strategic deployments.
This puts pressure on the quality of the strategy in its role as the model for ROI. Operations must become available on demand to strategies, and this means that the constraining presumptions of conventional discipline must be overcome by the logic of returns from change.
Posted by Malcolm Ryder at 8:29 PM | Comments (0) | TrackBack
My Daddy Spent Two Weeks at the Strategy Table, and All I Got was this Lousy KPI
Here's a story for IT management, but bear with me.
Marketing guru Seth Godin was annoyed by companies just not trying hard enough, so he busted them -- leaving them with the JSLogan strategy teaser Would You Rather Have Great Marketing and Sales or A Great Product?
Well, let's see.
First let's assume that there is a difference between a customer (someone who buys something) and a user (who is just someone that somehow already has something). Products often have WAY more users than there are customers.
Great marketing often creates customers. Mediocre products often get rid of them.
Great products do not create customers; great products keep them.
But the problem isn't really dealt with unless you include the issue of sales. If you don't need sales, then you're just in a whole different game than if you do need sales.
Marketing doesn't create sales. Products don't create sales.
Customers create sales. (Remember? It's their money, and they have to give it to you or there is no sale!)
If you need sales, you want your marketing to get out there and create those customers, so that they'll have a chance to create sales.
If you don't need sales, then you can use your resources instead to produce great products.
So if you had to choose, which is more important?
This seems like just a game, but when you think about it, don't most companies ask themselves "Why can't we have both?" And for any company that does ask the question, the problem quickly arises of having the issues competing against each other, forced by the boundaries of the budget and the hurry-up of more competition from outside.
Strategy then tries to work out the problem, providing the rationale for deciding relative importance. Prioritizing is always annoying when it means that you have to play the choose your pain game. But without prioritizing, there's little point in trying to "manage performance", and without managing performance there is little point in strategy...
The challenge in prioritizing is that it requires a lot of logic, and faulty logic will probably leave you with any of three good performance inhibitors:
- focussed on the wrong problem
- replacing action with debate, or
- trying to get from point A to point C without going through point B!
So, thinking through the activity measurements you use now, especialy the ones you call "productivity", how many of them are dedicated to faulty logic? Are they trying to show products creating customers?
Now how about this: are they trying to show IT creating business results?
IT doesn't create business results; business relationships create business conditions conducive to events that produce business results. IT supports business relationships. Is anyone measuring the relationship support? How about the business conditions? What are the forms of relationship support provided by IT? If those forms are not known or understood, then how can an activity measurement possibly be a key indicator of performance?
There are three ways to spin off from this story.
One: bad strategy, which comes from bad logic, is a bad thing.If it cranks out misguided KPIs, and you put a lot of energy into executing on those KPIs, you'll redline your organization. Better go check out the performance logic in the strategy.
Two: IT doesn't only support relationships. Obviously, technology has the power to directly create environments too, meaning "conditions", in which relationships can grow and prosper. Likewise, technology can directly create "events" by empowering certain things to happen that otherwise just couldn't... But the business logic of these things is that your company assigns technology to do those tricks and leverage them in the context of the purpose of the relationships -- so they are basically forms of relationship support.
And three: internal relationships that build the company count too. The parts of the organization that do marketing, or sales, product development, etc., all consist of key relationships driving their respective results, and IT must support those relationships. Strategy doesn't make the suport of one less important than of another. Instead, strategy tailors the particular way of supporting each one, by declaring what characteristics of each one are currently most necessary.
So, once that KPI (key performance indicator) is presented in the IT plan, it's worth "auditing" it to be sure that it is really about solving the right problem.
Posted by Malcolm Ryder at 6:24 AM | Comments (0) | TrackBack
June 17, 2005
CIOs: Managing the business's IT Agency
In the new industrial revolution, IT is at the center of the business evolution, and CIOs are at the center of the IT revolution in business.
Business now knows that reliance on IT means that IT is a business element, not just a tool. In the old dysfunctional relationships, LOBs get burned by providers, CFOs get angry about the wasted money, and CIOs take the heat. As strongly reflected in the Deloitte survey on outsourcing (covered by Christopher Koch at CIO magazine), companies have definitely found that the dysfunction isn't departmentalized internally or externally but instead ecologically systemic. Thus, merely leveraging lines of authority (for example, against the IT organization) doesn't make it go away; instead, capability maturity must set in with executive management of the relationships.
The biggest barrier to climbing the maturity ladder is the perspective that the IT organization is simply a repository of skills and assets -- a store -- instead of a management center for business operations. This perspective essentially displaces operations strategy with procurement, and then laments the poor state of the architecture on which enterprise economy of scale is supposedly built.
To have a shot at operations strategy, the business needs CIOs to manage the relationships between CFOs, LOBs and service providers. Experience has taught the enterprise that CFOs and LOBs alike must be able to count on the CIO function to provide knowledge, assurance and leverage of the providers of IT and IT services.
In effect, the CIO function should be an executive-level broker of IT and services for the enterprise, and with the overview of enterprise needs the CIO also manages the opportunities of importance to the service providers.
In governing provision against requirements, CIOs "own" the work of IT services providers, to generate ROI for the CFO and the enterprise, while likewise generating and protecting value for the LOBs from the services. Whether the providers are internal or external, CIOs must manage supply and demand equally well.
In managing the performance of the IT work, CIOs must focus the work to satisfy the business customer. This means the work must be executed in business-terms, to assure continued quality of service against the objectives of the business.
Run like a business, the new "IT Organization" features a blend of internal and external resources. At minimum, the CIO needs to:
- know where the strengths lie with all the involved providers,
- be able to call on them reliably, and
- know when to rebuild, reposition, or replace them, to keep up with the business.
But lessons must be learned from those who have the most experience. The performance of this new organization is modeled most clearly by the situation of external providers. Since they ARE businesses, their performance has always determined whether they got new business and stayed in business. They set the bar. Internal providers must work well based on the same type of competencies that make external providers successful performers.
Core competencies of external providers include managing skills and customer relationships to ensure that work such as projects and infrastructure changes align with the business and with required service levels, both current and future. As complex as that often is, the even bigger challenge is to understand how to collaborate on business requirements at the operations level instead of just at the infrastructure level. In collaboration, roles are the key, and provider competencies only count in terms of the role. Here, the critical differences are between being a contractor, a facility and a partner. All three are responses to the question of "how the business' work gets done" ... but providing the client's operations with (respectively) a business resource, a business environment, or a business competency are drastically different responsibilities for a role to address. Mismatches of client expectations and provider roles are lethal. To proactively align them or reactively reconcile them, the CIO should model the collaboration of providers as an operations strategy, and market the strategy both internally and externally.
Posted by Malcolm Ryder at 7:56 AM | Comments (0) | TrackBack
June 16, 2005
Linking Business Performance and IT Performance
Usually this subject starts off with the word "alignment" in the banner, which amounts to a freebie in getting folks' attention. Why resist here?
The idea of "linking" instead of aligning comes from the sense of correlating Business results and IT results, just as we would say "evidence shows that the consumption of lots of butter is linked to weight gains" or that "drug abuse is linked to higher crime rates".
Correlation generates something we can call the tension of implied causality. The challenge is to see through the implication and find out where the correlation is coming from.
If we take the word "performance" to mean "the degree to which functional outcomes have achieved targeted levels", right away it becomes important to see what distinguishes the IT targets from the business targets.
The business-side follow-up to that step is to ask, "in what way are the targets of the IT functions relevant to the business?"
Examining relevancy turns out to be the breakthrough. For any business, there is a general way to describe its functional ambitions.
- Every business needs opportunity, and operations with which to pursue them.
- In the face of market forces, the business must be concerned with supporting both the operations and opportunity, and also with transforming them as necessary.
The key business question is, given those two facts, what does IT do that matters?
As shown here, IT contributes to establishing and protecting the ability of the business to leverage the environment that it is in. With IT's contributions, the business can develop itself against requirements at an acceptable level of risk. The business has four really big stories to tell.
Each of the four stories -- Agility, Effectiveness, Deployment and Availability -- represents a major capability of the business functionality that responds to a critical requirement. IT's role is to "provide for" (not simply to supply or deliver) the capability. For the tactical capability to support business operation, the business looks at IT's contributions to Availability, such as through service management. A strategic capability, such as for transforming opportunity by exercising a competitive competency, tells the business to look at IT's contributions to Effectiveness, such as through BPM. IT would likely bring Change Management contributions to Deployment, allowing risk-controlled reconfigurations of workgroups and systems to enable transformation of operations. And so forth.
The punchline of this picture is that, seen through targeted contributions to business capability, IT performance is "linked" to business performance in a way that is best discussed as IT's business value.
IT's strategy for making those contributions is not the same thing as the business strategy, but the business strategy will impose priorities and weights on the four general capabilities, and IT will then strategically respond to that. By understanding how those business weights and priorities originate, IT managers can be more proactive in foreseeing and recommending IT contributions that are strategically sustainable and valuable.
Posted by Malcolm Ryder at 4:00 PM | Comments (0) | TrackBack
KM as a System
Often we define "benefits" quite simply -- as "needs that are to be satisfied". In daily operations, the needs that are perceived to be most challenging often seem so because they require use of assets that, on the occasion, seem to be either hidden or moving targets.
As a critical influencer on the organizational asset we call "knowledge", knowledge management (KM) needs to solve business problems, and it must do so both pragmatically and strategically. In asset management, the most important pragmatic strategy is focused on capacity.
How does capacity management pertain to managing knowledge? We're targeting the robustness of our ability to distribute good ideas effectively against any level of demand. Here, the concern is the marriage of intellectual assets that contain ideas, and digital assets that contain and carry the intellectual assets.
I.
Capacity here needs to be seen in two ways.
- One aspect is about the supply of "knowledge-delivery capability" available on demand. Typically, we want capability to be systematic. So, this looks at all components of what might be considered as, or developed into, the delivery system.
- Another aspect is about the supply of the content being delivered. We're concerned about whether the "right" content is available to deliver, regardless of the probable level of demand.
Consider how wide-ranging the elements might be to help the need . Dramatizing the point, what if an American workgroup needs to bolster a PDF proposal brief with an argument based on the latest concept update or breakthrough, but at that time the latest demonstration of the concept actually exists only in the form of a Shockwave clip in Italian used by the Milan sales office?
II.
Solving such an outrageous problem would be really great, and even circumstantially necessary. It might be a pragmatic motivator for a KM initiative -- but not necessarily sufficient as a basis for enterprise KM. Conducting knowledge-support of a business event such as this one might only be an ad-hoc procedure, a point-solution, or a one-off custom application.
On the other hand, if we look at what accomplishments that support ideally includes, we readily see the catalog of basic benefits from any kind of practical asset management. (Below, simply replace the word "asset" with the word "knowledge"...)
- Avoid unnecessary duplication of asset acquisition costs
- Maximize convenience and effective speed in the search for and discovery of needed assets
- Confidently secure rights to utilization of assets
- Sustain an optimal balance of asset quality vs. asset location
In those cases, we're happy to report that satisfying any one need usually offers a bonus by partially satisfying other needs too...
But to meet any of those needs, it's first necessary to create an infrastructure that supports the efforts for getting those benefits accomplished.
The most important efforts supported by the infrastructure usually sound like "best practices" that need to apply at all organizational departments and locations, and across their functions.
1. Optimize asset storage and retrieval through classification
2. Establish "version control" in the use of similar assets
3. Continuously track asset distribution and asset changes, against type of user and type of usage
4. Proactively manage demand on assets
Overall, these practices sound like a job for a sophisticated system. And they are not the only justification.
III.
The idea that "knowledge is an asset" ckearly makes sense... But this idea deserves some refinement.
For example:
- we can easily appreciate that there is a big difference between data and concepts. The nature of that difference is that concepts are all about "meaning" while data exists happily outside of that.
- Similarly, there is a difference between information (which is a lot like data) and knowledge (which is a lot like concepts).
Now, we're used to the idea that our information systems manipulate our data.
But how about a knowledge system that manipulates our concepts?
The motivation for doing that would not be unusual at all. We attach value to data in the context of the meanings we think the data will help to generate. Attaching value to it is what makes us think of data as an asset. In the same way, we come to think of information as being an asset -- if information supports concepts then it is generating meaning, in the form of knowledge. We attach value to the information, and so we think of the information as an asset.
Treating things as assets is a real sign that we care about them! We tend to build systems to be sure we will take care of them effectively.
Primarily, the reason why we think concepts are important is because they help us get things done, which is a subtle but critical observation. When we say what concepts "mean" to us, we're normally talking about their usefulness, not their intrinsic enlightening qualities. Likewise, the context that makes knowledge valuable, and that makes it an "asset" to manage, is its application.
This emphasizes the need to make knowledge "available for application", which zeros in on the set of practical issues that a KM infrastructure and system must address.
If we have a "knowledge system" to manipulate our concepts, the key manipulations are those very same moves -- i.e, best practices -- that support satisfaction of the needs we initially listed above.
IV.
To enable those manipulations, concepts will have to be "captured" and packaged in portable form. In looking (as we do below) at the range of techniques that meet this requirement, it quickly becomes apparent why so many different kinds of tools are brought to the KM effort.
Meanwhile, it's most important to see this packaging from the "knowledge consumer's" point of view. We refer to the package delivery and acceptance together as "transfer of knowledge" -- which precedes the consumer's application (use) of the knowledge.
In knowledge-transfer, there are three success factors: concepts must be (a.) deliverable; (b.) understandable; and (c.) relevant. Without these factors, the knowledge transfer effort risks simply becoming information exposure.
1. Concept delivery:
- Conversation packages concepts and transports them from one person to another. Memory makes conversation repeatable. Requirement: the ability to engage anyone who remembers the conversation or who originated the concept.
- Documentation provides a "proxy" for engaging the concept originator or other concept holders. Not being interactive, documentation has to be tailored in advance to the presumed interpretive abilities of the recipient. Requirement: the ability to use a medium (language, format, etc.) that offers fidelity to the description of the concept. [Two sidebars here. One, just because something is animated doesn't mean it is interactive. Two, form should follow function, but the medium can definitely hide the message; I own one of the only remaining copies of the Excel Users Manual in Polish: fascinating as a curiosity and, since I never learned Polish, absolutely meaningless to me as instruction.]
2. Concept recognition:
- Categorization allows one concept to be identified in more than one way, and it also allows multiple concepts to be identified in one way. This keeps differences amongst types of users (and their differing points of view)from preventing identification of the potential usefulness of the concept. Requirement: the ability to cross-reference concepts with types of usages.
- Translation allows different types of users to grasp the same concept through different means. Requirement: ability to generate, maintain and identify multiple versions of the same designated concept.
3. Concept incorporation:
- Comparison takes into account the fact that the awareness of how to use a concept may be a sudden and/or unprecedented event, because the usage situation may not have called on the concept before. Although we usually have a good idea of how often previous problems have been addressed with previous concepts, it is relatively mysterious as to when and where a genuinely new problem will occur, demanding research. Here the immediate point is to make the research easy. Requirement: ability to test or certify the relative quality of a concept for the purpose -- including testing concepts against other concepts.
- Protocol governs the communications behavior between two parties, factoring in the known or suspected impacts of certain modes of (as we usually call it) information transfer and knowledge transfer. Requirement: ability to manage users' access rights to concepts by profiling users.
As we step through those three success factors, looking for the combination of concept availability and concept usability, we can imagine everything ranging from teleconferencing and IM, to voicemail/email and blogs/portals, to taxonomic systems and concept matching and XML, to content management and artificial intelligence and business rules. Along with myriad other tools and approaches, these help to construct an infrastructure for KM. Integration of these into a knowledge system is part art, part science and likely to be an ongoing evolutionary effort.
Then, in executing processes that manage knowledge as an asset, the general conversion of ideas into "reusable content" becomes a routine expectation of the population of knowledge-users.
V.
With that expectation in place, management has a couple of even bigger fish to fry.
One, when users see other users as the knowledge provider, there are many issues, particularly of protocol, that social relationships have resolved but that are largely undetermined and unresolved between users who don't know each other. KM requires intervention on a level of cultural norms, changing norms to accomodate successful interactions explicitly independent of social relationships yet compatible with them. Unlike in academia, most companies have not readily organized their protocol around knowledge-peer networks that rival the authority of the org chart...
Two, if the idea of usefulness is not being managed, then the idea of managing knowledge availability loses a lot of its value. The single most hospitable environment for KM is an environment in which the population's common awareness of the organization's strategy is very high, driving the perceptions of resource usefulness. Strategy Management should be assessed as one of the very first steps in planning the development of a Knowledge Management practice in the organization.
Posted by Malcolm Ryder at 7:06 AM | Comments (0)
June 15, 2005
Business-IT Convergence? What happened to Alignment?
CIO Magazine, covering thinking from their CIO's Perspectives on Enterprise Value conference, reports that we've gotten ourselves into another semantic knot. But not a tough one. The debate pits "convergence" versus "alignment". Is Convergence the new and improved Alignment? Is it time to change horses again?
Perhaps what's going on here, in this overall discussion, is just reverse-engineering the underlying systems of a good plan...
Alignment (noun) is a process having the objective of real-time structural compatibility. But convergence (noun) is an event, literally a co-incident, with the characteristic of having critical influence on the state or direction towards some outcome (which is why we care to notice it).
Fundamentally, alignment emphasizes compatibility -- essentially, "usefulness". Convergence emphasizes concurrence -- essentially, "agreement".
But the two-ton idea casting a shadow over both alignment and convergence is "Integration". What hasn't changed with the terms-du-jour is a goal of integrating whatever is called "business strategy" with whatever is called "IT strategy". What has changed is that we now can usually distinguish the need to have operational motives align from the need to have operational outputs converge.
As we move into performance management, we kick things up a level where we then start working on the problem of "making outputs align" and "making objectives converge"; but we already call that "planning."
Posted by Malcolm Ryder at 6:50 AM | Comments (0) | TrackBack
June 14, 2005
Archestra Topical Framework
The purpose of the Topical Framework is to organize Archestra content as an explanation of how the "functionality" of the enterprise structurally relates to the strategy. In effect, it "reverse-engineers" the enterprise capability.
The architecture of strategy is based on the following idea.
First: every enterprise accomplishes its intents by taking four essential types of action:
- Model: design an idea in a form that explains its production
- Build: realize the model in a specific form that is practically applicable to operations
- Use: put the built version into live action
- Change: modify, "in effect", the idea through remodeling, rebuilding, and/or reassignment
Second: each of those types of action can be "strategically" significant in the sense that it can critically alter the status of essential constituent conditions that define the current enterprise capability. This includes five essential conditions:
- market position: the location from which effectiveness is predicated
- performance logic: the theory and method behind the successful exercize of distinctive capability needed in the market
- competency: the distinctive capability accompanying the motivation of the enterprise in its environment
- infrastructure: the constructed support facilities underlying the exercize of competencies
- ownership: the ultimately authorizing stake limiting the intent and scope of the enterprise constitution
Beyond planning, capability is expressed through execution, and execution is based on functions.
- Architecture creates "spaces" for functions. Neither just physical nor metaphorical, these spaces are actually the domains of the conditions structurally comprising the overall enterprise capability. Managing the domains creates the potential positions that the enterprise can take and leverage.
- Strategy creates "functions" for those spaces. Strategy proposes and directs the action that leverages the positions provided by the spaces.
The Archestra topical framework conceptually represents how the four basic types of action (functions) relate to the five primary constituent domains (spaces). In this way it identifies a universe of "touchpoints"; each touchpoint is a topic of study.
In real organizations, the twenty touchpoints influence each other, and therefore each touchpoint has both cross-domain and cross-functional "presence"... However, the framework argues that each touchpoint makes a distinctively critical contribution to the complete enterprise capability. The framework initially represents each touchpoint uniquely, with a representative label indicating the kind of requirements and decisions that distinguish each touchpoint's importance.
As used in the framework, the names of these touchpoints do intentionally reflect the usual objects tracked around the enterprise. However, even moreso, they identify a more abstract concept that is appropriate. This emphasis on concept explains why some of the names fit where they are shown. For example, while any particular implemented "system" (such as an IT application) might usually be thought of as an Infrastructure issue, the concept of "a system" is more important to consider, and here it is shown in the Performance Logic space under "Build", where it generically pertains to all kinds of self-contained structures for continuous rational interaction.
As the framework evolves, some touchpoint names may change, allowing improvement in representing the critical essence of the relation.
In the framework, each touchpoint in a space contributes to execution through a function, and it can be discussed in terms of how it pertains to the way its function is managed.
This issue of managing the functions (i.e., "practice")is detailed in the following way.
As affected by the practices, a touchpoint in turn impacts its domain and the overall potential of the enterprise capability. Archestra content can describe this chain of influence.
Posted by Malcolm Ryder at 2:53 PM | Comments (0) | TrackBack
June 12, 2005
Authorizations: The Logic behind the logic of Performance
Performance planning.
For actually getting desired performance, it's one of those things so automatically expected that we excuse ourselves for not even especially bringing it up -- AND we also excuse ourselves for obsessing about it.
Of course, in both cases there's the issue of who you trust to do the plan, but otherwise the main risk has typically been from head-in-the-sand neglect or denial of how the plan affects you. Often, the big picture plan has seemed too distant or fuzzy to be relevant to making the decisions that really count locally.
Now, with the return of accountability beyond accounting, we're more often forced to take a conscious stand about the plan. That is, even when we aren't the planner, we want to know how we are affecting the plan instead of affecting just the assignment in front of us.
On a personal level, this newly heightened sensitivity might be experienced in concerns about job security or advancement. We want to know "what it takes", and because companies are now so much less loyal to employees, it's more important than ever to know what the company is "really up to." That's one place where knowing the plan comes in, big time. Staying out of jail also counts, ya think? What's worth new attention on our part is whether the terms of performance evaluation are different from the plan!
On an organizational level, the performance evaluation issue is different. Organizational units are increasingly subject to cross-functional, integrated, partnered and/or "matrixed" lines of ability, permission and responsibility. Consequently, organizational operation and execution is more often a pressing issue of negotiating an output from the immediate environment, with the plan lurking somewhere nearby in the background.
That raises a question about whether the greatest practical value of the plan is to direct manipulations of the environment for action or instead to manipulate direction of the activity itself.
Rather than risk a contradiction or competition between the two, a good plan should explicitly configure the organization for the necessary functions. Multiple levels of planning detail should ensure that the configuration has some structural integrity, by offering the blueprint for linking things together. Usually that turns into process flows -- a concentration on the action and on resources for the action. But that is only half of the story.
Getting from plans to results
As demonstrated in accountability, the interplay of environment and activity makes for interesting and complex twists in the plots -- the same plots that accounting detects and documents regarding how we wind up wherever we do. Accountability for performance has to track through cascades and intersections of more than one way to be "planful." This exposes the corresponding difficulty of promoting planned action appropriately in the first place. Question: how do you know when it's not all just voodoo?
If "performance" is the name for the relative level of success achieved in meeting planned objectives, then performance planning should be the name of the process that designs the logic of the activity behind meeting objectives.
Of course, what most often distinguishes such an actual plan (before the actions) from just an accounting (a description after the actions) is that the plan's logic proposes the activity whereas an accounting confirms activity.
This is interesting because it helps to remind us that once everything has been cranked up and let out of the gates, there is a difference between describing what is evidently working and describing what is supposed to be working.
To consistently organize and share that description, imagine being able to simply stay on top of the following, less evaluating it:
- Planned cause, versus actual cause
- Planned effect, versus actual effect
And further, as if completing the visual aid above, imagine that you had a reliable way of:
- knowing what all four things were,
- knowing who else knew which of them, and
- knowing when that knowledge was really driving activities. It's enough to make you feel discretionary, or even in charge.
It further shows that, rationally, real performance management has to make decisions about when reality is posing more of a problem than it is offering a benefit, and vice-versa...
Either way, that means considering whether an actual diversion from the plan is, perhaps, a really good clue that the plan should be changed.
But managers have to earn the privilege to make that change. How?
The performance environment
If the plan's logic is not being demonstrated, but instead the logic of the actual events is either compelling or unavoidable, then performance management must first determine whether realizing the plan logic was prevented or whether things just worked around it for their own reasons.
Why? Because presumably, the plan's performance logic was also about a good shot at reaching necessary performance levels repeatedly and predictably for the duration of a designated time period.
So, either the alternatives to the plan need to similarly measure up, or the quality of the plan's logic needs to be re-evaluated. The performance manager should cover this. Of course, the result, which is a revised or reiterated proposal, will face the same potential challenges as its predecessor: the organization must have both a reason and the ability to run with the plan. That is, it must conform to the plan.
The part of the logic that configures (i.e., conforms) the organization includes the rules and priorities that authorize the organization to set in place "these" ways of doing things instead of "those" ways -- in real-time or "runtime". As a result, it turns out that authorization, by organizationally instituting proposals, is the crux of performance management.
(What! Let me see that plan again.)
Posted by Malcolm Ryder at 11:57 AM | Comments (0) | TrackBack
June 11, 2005
The Business Optimization of IT
Should enterprise IT organizations (ITOs) be modeled to run like an autonomous business partnered or contracted to its enterprise client, or to run like a captive business within the enterprise business?
It may seem that the jury is permanently out on this, as various theories abound on the relationship between the enterprise's business model, business strategy, ITO models and IT Strategy. Over time, certain relationships may prove to predominate for businesses of given industry, scale and maturity.
Meanwhile presuming that the business pays for IT, which means that the business is the "customer", what should surface as a set of "constants" is the breakout of how IT management is optimized to business concerns, and how that optimization actually makes a difference to the business.
Every business must organize IT in a way that is visibly logical when handling three critical challenges to business-oriented control and capacity:
- Availability versus Costs
- Demand versus Operations
- Risks versus Requirements
The following Archestra framework illustrates the relationship of issues pertaining to that optimization and differentiation.
Posted by Malcolm Ryder at 5:08 PM | Comments (0) | TrackBack
The Business Management of IT
Should enterprise IT organizations (ITOs) be modeled to run like an autonomous business partnered or contracted to its enterprise client, or to run like a captive business within the enterprise business?
It may seem that the jury is permanently out on this, as various theories abound on the relationship between the enterprise's business model, business strategy, ITO models and IT Strategy. Over time, certain relationships may prove to predominate for businesses of given industry, scale and maturity.
Meanwhile presuming that the business pays for IT, which means that the business is the "customer", what should surface as a set of "constants" is the breakout of how IT management is optimized to business concerns, and how that optimization actually makes a difference to the business.
Every business must organize IT in a way that is visibly logical when handling three critical challenges to business-oriented control and capacity:
- Availability versus Costs
- Demand versus Operations
- Risks versus Requirements
The following Archestra framework illustrates the relationship of issues pertaining to that optimization and differentiation.
Posted by Malcolm Ryder at 5:08 PM | Comments (0) | TrackBack
June 1, 2005
A Business Relationship Management Framework for IT Service Provision
The organizational structure of a business creates "organs" which have functions vital to the business. The IT organization created by the business will make the most sense as a component of the overall business system. Since business organizations at any time are different amongst businesses, and are different for any given business from one time to the next, the subject at hand is not so much what the ideal IT organization looks like but instead how to be an optimal IT organization for the particular business.
I. The organizational mission
Cows and people both have hearts, but one heart won't substitute for the other.
All businesses are enabled by IT. Seen as a functional business organ, the IT organization has both a primary responsibility and a primary objective.
The IT organization's objective is to manage enablement of ongoing business fulfillment of customers' (and other stakeholders') demand.
This enablement is executed within business preferences and tolerances -- targets set for both the types and levels of the enablement effort's performance, value, quality and risk.
Meanwhile, enabling business fulfillment is not solely accomplished through IT. For assuring the desired enablement, the IT organization's special responsibility is to succeed in managing information technology (IT) in three dimensions:
1. Requirements (representing business needs)
2. Changes (representing the business environment)
3. Assets (representing business investments)
Of the three dimensions, Change is the most directly challenging to manage.
All three dimensions feature difficulties stemming from complications (such as incompatibilities amongst many separate factors) that accumulate over time. But relative to the other two dimensions, changes involve much more direct struggle with complexity (such as interdependencies and their uncertainty).
To optimize the business cost/benefit of change against complexity and uncertainty, the basic job of managing IT systems must be executed within policy constraints that are nothing less than how the business explicitly prioritizes and accounts for its dependency on IT.
Meanwhile, because business-change is the rule rather than the exception in the life of the business, IT Management is naturally responsible for maximizing it's ability to manage changes to the "business-enabling" IT.
In that scenario, IT Change management is the central and most critical issue in the IT organization's mission. To tackle this, there needs to be a good picture of what the business impact scope of IT Change includes, along with a corresponding picture of the scope of both business management and IT management practices to be applied.
II. The architecture of enablement
IT's execution on enabling business's fulfillment is conducted on three levels of competency above and beyond hardware and software systems:
1. Processes - which are measurably composed, objective-driven activities.
2. An operation - which is a resource-managed integration of processes.
3. A "service" - which is an operation that is policy-based and customer-driven.
This scope of activities must be woven together in both IT and business practices. With change being the crucial issue in the reliabiity of the business dependency on IT, current business priorities always set the legitimate terms for alignment of IT's practices with the business's.
In this alignment, the overall arc of business expectations is as follows. Typically, business activities subscribe and leverage assets, consuming them on at least a temporary basis. Business assets include things, money, information, time, skills,and processes. From the business perspective, services convert these assets into on-demand resources and so are an essential link allowing the business to use its assets to meet its requirements. Therefore, managing services is an essential business competency, and managing changes in business finds the management of services to be a critical success factor.
"Performance" in IT's enablement of business fulfillment therefore refers mainly to a level of success achieved in providing appropriate services, on demand but also across continual change. From this perspective, the provision must be affordable and reliable. Business value comes from that performance tightly tracking with business priorities. And business perceives quality in the IT effort mainly through the consistency with which the effort delivers value through the current level and structure of management. Finally, the business sees risk in the effort according to the evident likelihood that the quality can be effectively leveraged for the requirements of the business-level priorities.
All of these business perspectives identify the IT organization's handling of assets, changes and requirements on business terms -- regardless of how the information technology is designed and deployed. As the famous saying goes, although a drill makes a hole, customers aren't paying for drills, they're paying for holes. In the form of IT services, the IT organization makes the drills, but the reason for doing that is to deliver business services -- the holes.
III. Re-aligning ITIL
The defacto standard for IT Service management is ITIL, which identifies a comprehensive approach for defining and managing services as products such that IT organizations can maximize the cost/quality ratio of the services for the business.
But taking another step in this consideration, the IT organization must acknowledge that no product actually delivers value except through the way that it is used. To more directly address that, the following framework describes and relates management processes of the IT organization as they are dedicated to the business utilization of IT services.
While incorporating the management process distinctions now standardized in the ITIL vocabulary, this Archestra framework positions the processes such that their different roles are quickly targeted from a perspective more sensitive to business drivers that generate demands on IT -- such as needs, investments, and the business operating environment. Each of those drivers significantly influences the business's perception of its relationship with the IT organization as opposed to just with the services.
(For an enlarged view of the graphic, click here then right-click and print landscape.)
The framework offers a very symmetrical assignment of management concerns. The symmetry more explicity recognizes the major business issues of the IT environment (not just of the current IT infrastructure); and it readily refers to the enterprise operation as extended to third parties beyond the corporate campus.
A key benefit of this reframing is to stage better predictive power and "normalized" tactical comparisons between legacy vs. evolving (or otherwise heterogeneous) enterprise architectures. The framework makes the point that change management is the nexus for all key business issues addressed by IT architecture and must strategically integrate them. Furthermore, the framework decodes the exciting buzzwords agility, integrity, reliability, and of course alignment by explaining where and why they should enter the conversation. For example, agility is spotted as a demand-driven crossing zone or balance point between support and delivery, reflecting IT service value.
The other significant specific difference between this framework and the ITIL publications framework is that "Continuity" is associated here with Support instead of with Delivery. The reasoning for this is that aside from the contingency planning (i.e., the design) aspect, Continuity is primarily and essentially an issue of problem management and recovery. Meanwhile, the more important aspect of its classification is that it falls on the side of enterprise risk management.
For a discussion on how the framework generates and tracks ITSM process integration, email me.
Posted by Malcolm Ryder at 2:10 PM | Comments (0) | TrackBack