« June 2005 | Main | August 2005 »
July 30, 2005
Why Strategy Execution begins with Portfolios
Everybody has a strategy.
But it's not a commodity; and if strategy was easy, everybody would have one that works.
The science of "strategy failures" is intensive. Discounting 20/20 hindsight, the main factors in the failures are predictable -- they are the same ones that would have led to success:
- goals (that are clear),
- priorities (that are shared and supported),
- requirements (that are validated and adopted)
- and methods (that are instituted and controlled)
But how does the failure develop?
Strategy starts out as an idea that becomes a plan. When the strategy plan is not being realized, the holdups or breakdowns occur at one or more of the four points above, making their interdependencies untenable. Underlying that, the most critical missing ingredient is stakeholder commitment to generate the needed interactions.
Usually a failed realization is discussed in terms of an execution failure. Although that might be the punchline that people seem to care about the most, it might be missing the point.
By analogy, imagine an application that is installed on a network. It depends on the network components to establish the links between its various parts and its users. But as we have all heard, and as nearly every experienced consultant can confirm, an application will not achieve its aim if the network is not configured OR if the users are not trained. Just because the application is "installed" doesn't mean that it is going to "run" -- it has to be implemented before it can effectively execute.
To implement a strategy, appropriate commitments must be made to ensure that the key factors (goals, priorities, requirements and methods) are addressed in ways that allow them to successfully interact.
The traditional view of these commitments involves three key resources managed to the need: people, processes, and technologies. The main problem to solve is to resolve "competition" for the availability of these resources while verifying that the quality of the resources is sufficient.
The source of the competition for resources is where implementation must be prepared; in most companies, most resources are not at-large, and the deployment of resources may be following a plan driven by legacy jurisdictions, budget allocations, or disparate perceived needs not aligned with the support needs of the strategy.
But if managed as a portfolio, the various resources can be deployed as investments in the objectives of the strategy. In that way they constitute the "infrastructure" needed for the dynamics of the strategy's realization. Without this level of resource control, the implementation of the strategy is far less assured.
Posted by Malcolm Ryder at 9:31 PM | Comments (0) | TrackBack
July 29, 2005
Understanding the Value of Quality
Why do we care about quality?
Another way to go at this is to point out that quality is important only if someone cares.
That makes the opening question, "Who cares about quality?"
As a business issue, we go right to the stakeholders to start working this out. A producing organization provides a product, and it does so to a lesser or greater degree of quality. But what does quality mean to the stakeholders of the production and the product?
In every stakeholder's case, quality is a characteristic that satisfies what the stakeholder needs the most. In the following diagram, we quickly catalog what this means. In general, value is a distinction that the perceiver holds in highest priority. Quality is an enabler of value. That allows us to understand quality as the "success factors" of value, making quality definable and even measurable.
Probably the most overlooked aspect of the above is not that there are, according to the role involved, different elements of perceived value that "quality" should support. Rather, the neglect is of the fact that often a single party has multiple roles simultaneously. When multiple roles are active concurrently, it is far more likely that the party will express needs that are some blend of numerous success factors but a somewhat random blend. If quality is to be managed to support value, this blend will need to be sorted out so that the proper set of responsibilities and constraints can be identified with (and assigned to address) each factor.
Posted by Malcolm Ryder at 8:47 PM | Comments (0) | TrackBack
July 28, 2005
Managing without Metrics?
Metrics mania is for real, and not having it could be more of a problem than the problem we have with surviving the mania. Why? Most managers would not be able to communicate effectively without metrics, and with the pace of change in business, new metrics are necessary. The intense community-wide pursuit of more metrics means that there is always a better chance that the new ones you need are already discovered and available.
But management didn't grow from metrics; management adopted metrics. There is something deeper than metrics that characterises true management.
What is it?
Here is the really big notion that always drives my own sense of what "management" means.
Start with the idea that there is initially an item of some kind (an organism, process, object, etc.) going through changes and/or behaving in various ways, independently of your influence on it. Then, as soon as you have a particular objective for the behavior or changes of that item, you begin attempting to exert some logical influence on the changes or behavior to cause it to conform to your objective.
But you don't just take your best shot at that and see what happens.
You sustain attention and influence on the item's changes or behavior as much as is necessary to maintain and/or improve its conformity to your objective. This effort includes the possibility that you will at some point change your objective but attach it to the same item as before. Practically speaking, that may cause you to change the specifics of how you influence that item's changes and/or behavior.
As a result, you'll be busy with determining why things you've been doing are working well or why they are not -- and that is a two-way street: how manageable is something, and just how is it manageable?
The key to succeeding in your influence is to identify the characteristics, attributes, properties, etc. of the item that you can "engage" with the characteristics, attributes, properties, etc. of your mode of influence, such that your influence is *at least virtually* causal towards your objective.
I say "virtually" only because in practice the success of "the influence" is sometimes hard to confirm as being a coincidence versus a direct effect. I usually define that more precisely -- as confirming whether something is a prerequisite (exhibited by correlation) versus a cause (exhibited by testing). A prerequisite allows something else but does not necessarily cause it.
But here you can see why management is essentially dependent on a logic. The whole idea of management assumes that your influence on something is effective because it is "logical".
This means, furthermore, that obsessively measuring stuff outside of a logic of action to influence progress towards a designated objective (other than measurement itself) is NOT "management".
At the same time, the notion of "measurement" needs to be understood broadly. Here, the working definition of measurement is:
the determination of a significant distinction,
with the type of distinction being already named so that
comparison is straightforward.
That is, measurement determines that:
something is, to a discernable degree, of given state X,
and is therefore not of some other degree or some other state.
In the practices and measurements of a particular field, what becomes really crucial to management is to decide the reasons and standards for using the "degrees" and "states" being researched, referenced or communicated. From that, a logic of influence can be agreed and developed, and measurements appropriate to the logic can be cultivated.
Posted by Malcolm Ryder at 6:46 PM | Comments (0) | TrackBack
Why performance evaluation must precede cost reduction
"Vision" and "Mission" intend to continuously guide organizations to a position and stance that is considered "optimal" for the business.
As defined by Princeton's Wordnet, optimal means "the most desirable possible under a restriction expressed or implied".
Certainly, companies consider "excessive costs" to be an expressed restriction -- but worse a restriction that actually represses desirable outcomes.
To understand how costs amount to a repression, cost must be seen in a variety of contexts.
Investments that create resources build capacity; capacity creates opportunity to respond, and response creates the differentiating impact measured as "value".
- But expenses that deplete resources or capacity or responsiveness risk altering the potential impact and can therefore erode or prevent value. (This might be expansions or alterations of property or systems that increase use by some but provoke inhibiting problems for most other users.)
- And excess capacity carries costs that are therefore unavailable as investments in other uses. (For example, consider funds that are allocated to maintaining systems that are not being used.)
- Likewise, expenses that intend yet fail to create capacity hold potential alternative investment hostage, decreasing opportunity to respond. (Here, think of projects that fail, or purchases that acquire the wrong thing.)
Since value is defined both by type and by level of impact, the question brought up by those circumstances above is this:
- Given the demonstrable use of current capacity, does the organization consider the value actually currently expected, which is the real value at stake, to be "the best possible position" ?
If the answer to that question is no, then what is the proper correction?
- Should managers concentrate on removing the risks to higher levels of that expected value?
- Or instead is there some other type of value (that is, some other differentiating impact) that should be installed as the target?
Although we can see that one of those choices should be taken, neither decision necessarily lowers costs!
Meanwhile, the only way to rationally answer either question requires that first we validate the currently targeted type of value as the correct type.
This brings up the issue of mission. A mission is simply a definition of an intent to produce a certain differentiating impact. If current capacity does not support a likelihood of succeeding at the mission, then the value promised by the mission is clearly at risk and potentially impossible.
When capacity mismatches mission, the only two corrective choices are to change the mission to fit the capacity or to increase the capacity.
The chief obstacle to those correctives is a contract or other formally binding agreement that does not allow adjustments without an additional expense that outweighs the related cost-benefit of making the adjustment.
Whether literal or metaphorical, the oneous "switching cost" can raise the cost of a capacity correction beyond practical acceptance, while leaving the capacity imbalance unresolved.
Further, in that way, the consumed-to-date portion of investment in the mismatched capacity becomes "sunk" cost, and the prevention of capacity reorganization increases the effective cost of some potential alternative opportunity (i.e., "opportunity cost").
Overall, what this means is that cutting costs is an action that actually needs to generate a return on investment greater than or equal to the amount of costs cut. Oversimplified, this says that a ten-dollar cost-cut needs to target a twenty-dollar gross benefit. Why? Because if the saved ten dollars is needed at all, it should become an investment working to earn its own way.
This "ROI of cost-reduction" will not materialize except through renegotiation of the agreements underlying the switching costs. Wherever the renegotiations don't offer stakeholders equivalent-or-better benefits compared to what they already have, the mission of the organization remains potentially compromised by stakeholder resistance.
This illustrates that change management is a prerequisite to the success of cost-reduction.
Then, to understand what must be changed and thereafter derive a cost strategy, stakeholder roles in the proposed new configuration of capacity must be mapped out such that their performance under the new agreements will logically produce a mission success suitable to replace the old (mismatched) mission results.
By comparing the proposed performance logic against the bases of current performance, change requirements emerge, and costs related to the changes surface, which allows adjustments of current costs to be made more rationally. Punchline: cost reduction is not an action: it is an effect.
Posted by Malcolm Ryder at 11:34 AM | Comments (0) | TrackBack
July 27, 2005
Performance Improvement requires Change Management
Performance Management is a concept best defined by business solution developers. That is, it is based on a definition of a problem called performance, and by focusing on a theory of the problem it derives many approaches and components of "solution"...
In a comparison of myriad definitions from vendors, analysts and industry journalists, the working common denominator appears to be "management of the alignment of people and technology to improve the effectiveness of their run-time support of business objectives."
One of the more significant notes about that consensus is that it does not include "processes" in its grasp. This might be for any of several (debatable) reasons, such as:
- business process management (BPM) is thought to be a peer of performance management rather than a part of it
- solving process problems is not thought to improve the solution of performance problems.
While both of those notions seem unlikely to be true, what makes them provocative is the way they force us to defend our theory of the "performance" problem. Indeed, since process management has already had intensive attention for years through automation and reengineering initiatives, the current idea that the "performance" problem has remained unsolved lends credibility to the sense that a focus on process is at best necessary but insufficient. The suggestion, then, is that a focus on performance is at least more important than, if not actually an alternative to, process management.
Put as simply as possible, the difference between process management and performance management is, respectively, the difference between "how to" and "how well"...
Defining the performance problem as "how well" readily explains the collection of interests addressed by performance management.
At the core of the problem theory, there is a set of target levels of activity impact or event impact.
The impacts are meaningful in any of several ways (contexts):
- financial
- legal
- operational
Standards or benchmarks are established and adopted to set impact targets in any of those contexts.
The compliance of operational outcomes with the impact standards is continuously monitored, which provides alerts and data for supporting further management decisions.
The fundamental issue is therefore how to manage impact targets and manage impact compliance.
This two-pronged management requirement means:
- deciding on what specific examples, mechanisms, and evaluation models to implement regarding targets, and
- doing likewise regarding compliance to the targets.
Given that perspective, it isn't surprising to hear lessons learned such as that offered in Intelligent Enterprise by former corporate planning chief and Hackett Group cofounder David Axson:
"you can put all sorts of policies and processes in place to try to achieve compliance, but if [that] doesn't change practices and behavior, your investment in compliance [initiatives] is of marginal value..."
And why is this a predictable outcome?
While policies deliver explicit guidelines and definitions to identify priorities and permissions, their effect is essentially environmental, leaving inhabitants with the politics and preferences of adapting to the environment -- in other words, with the latitude to not comply.
And while processes prescribe the rules of activity, they don't set the motivation. And the more complexity exists in the design of a process, the more opportunities there are for motivation to vary from what is minimally required by the process to meet its execution requirements -- in other words, to not meet the "standards" for support.
The punchline is that if "performance" is essentially the degree to which execution meets impact targets, and execution is a variable phenomenon driven by behavioral issues, then there is a two-tier prerequisite to performance improvement:
- successfully managing performance (to meet targets) will be critically dependent on deliberately managing the changes that affect behavior; and...
- successfully changing the impact targets (to define "improvement") will specifically require managing behavioral adaptations to the perceived opportunities and risks of the "working landscape" offered by the new environment that compliance prescribes.
So what about technology? How does that play into the situation?
The two dominant ways that technology affects the situation are procedural automation and communications. Typically, business requirements for speed and accuracy in work flows mean that people depend on the efficiency gained through technology to "effectively" initiate, intervene and interact. However, leveraging technology functionalities offers appropriate impacts when in the right hands, and risks inappropriate impacts in the wrong hands. What makes this particularly important is the pervasiveness of the technology. Consequently, the secret to technology's role in its alignment with people is in how the administration of the technology allows the organizational structure to drive value by meeting targets. That is, technology is a critical environmental factor of organizational behaviors, affecting behaviors while also asking for behaviors to adapt to it.
Posted by Malcolm Ryder at 5:36 AM | Comments (0) | TrackBack
July 22, 2005
The ROI is dead; Long live the ROI
It makes perfect sense that CFOs would be the ones to consult about what is acceptable in measuring IT's economic impact.
Ultimately, the CFO determines the pace and level at which IT is funded.
This puts the CFO in a role that handles IT the way a real estate developer handles a commercial property. The expected value of the property is based on the utilization of the facilities and services that the property, appropriately prepared, will provide, protect and host.
That is, the impact of the "whole" property is taken as a new factor in the commerce of the area, while the commerce is the vehicle in which arrives the economic justification for approving the property. Ultimately, what is measured is the value of the commerce, with the property being simply a key enabler.
But that commerce is meanwhile constrained by zoning, competition, legal changes and weather. Properly acknowledged, these constraints are part of the considerations in the design of the property, but the property is not really expected to control or eliminate those constraints.
Let's look into what aspects of the CFO's view on IT are analogous to the above.
Some costs are purely about acquiring the property.
Acquiring the property is followed by preparing it.
Regulations and ambitions are negotiated into a development plan.
Construction and security commence.
Marketing is initiated in due course.
Occupancy is cultivated through rights and contracts.
Those steps cover the costs of creating the property and allocating/distributing it to users -- in other words, all of the asset deployment. Therefore, to package this group of costs even more tightly, let's call this group the resource delivery costs.
The upcoming financial issues are about the balance of maintenance and other upkeep (renovations, additions) versus income taken from the occupants. But from the developer's standpoint, that income need only "pay off" the delivery costs, and it might also pay back more than those costs.
Delivery provided a resource for the occupants. The occupants' situation was not to create the resource but to access it and utilize it. In the worst case scenario, the entire group of occupants fail to generate a net positive cashflow from their utilization. This case does not negate the fundamental potential for the property to return financial benefits greater than delivery costs. If all of the occupants were evicted, the property could be sold to a different management group, for the amount of its estate value, which is in effect its market value.
By analogy, IT has an estate value; it has inherent functionality that can be put to many different uses.
But as "developed" property, the IT infrastructure represents the managed configuration of the property, which underlies (encourages and supports) the benefits from its usage. Thus the managed property configuration has what I'll call the projected maximum resource value.
In real life, because occupants (users) and property managers are quite variously effective in their handling of the property, their changes can cause the equation for the final impact on the value of the commerce to deliver different answers.
Consequently, there is no directly causal relationship between the resource delivery cost and the commercial potential -- and obviously then neither between the asset and the final economic impact.
There is, however, a logical relationship. Logically, what should be understood and tracked is how the asset functions in the dynamics that result in the final economic impact. Initially entering those dynamics, is the asset an inhibitor, catalyst, accelerator or what? That is, what does the asset "do to" the outcome of the formula for final economic impacts?
The question is meaningless until the formula is available. Focusing on the dynamics must precede assessments of the assets. The dynamics are described at minimum in two dimensions.
- One: managing the purpose of resource utilization, and managing the actual utilization itself, is layered on top of managing the resource delivery and managing its underlying development. The logical linkages between these four layers of management are one dimension of the dynamics.
- Two: the other major dimension is the set of opportunities and constraints on each layer. Those factors determine what each layer can offer to its linkage with other layers.
The general challenge is to identify and exercise the controls that establish linkages and that select the opportunities and constraints actually being addressed in the linking.
Final economic impact is going to be the result of the throughput of these interlinked layers -- as applied to the prevailing conditions into which the final output arrives.
Accordingly, predicting economic impact involves assumptions about future states at each layer of management in the dynamics.
This means that the final representation of so-called "financial performance" (ROI) is a probability of a value.
Most of the attention to the economics happens when something is proposed that will ask internal workforce or work-partners of the company to:
- modify the infrastructure (engineering)
- modify the control of the infrastructure (maintenance),
- modify the ability to change the infrastructure or its control (management),
- modify users' leverage of the infrastructure (administration)
Keeping in mind that we see the infrastructure as a resource, the following diagram's framework of considerations represent coverage of opportunities to track the logic of potential economic throughput:
Financial and methodological commitments, which can support each major assumption about value throughput, should be called out and reality-checked for the opportunity and limitations that their current states present. These are, for better or worse, the controls on the throughput. By making them explicit, the overall dynamics of the investments become clarified as a set of requirements whose fulfillment can be measured. In this sense, achieving the desired throughput is a visibly active performance on the part of the company.
Posted by Malcolm Ryder at 11:04 PM | Comments (0) | TrackBack
Needs versus Requirements: the battle of Why versus How
There are many different enablers of higher performance in business, including capital, relationships, knowledge, position, tools and others. Of the more tangible ones amongst those various enablers, the alignment of tools (technologies) to the business still features the most vivid stories of uncertainty here in the post-dotcom period.
For most kinds of businesses, acquisition of technology has only one essentially distinctive purpose: to secure relatively uncontested on-demand access to the functionality of the technology, within the desired timeframe. Business interest in technology acquisition is not hard to understand at all, but the experience of acquisiton too often leads to buyer's remorse. What's worse, the same kind of failures occur year after year, as if we can't learn from the past. How do we get past this problem?
The marketplace offers truly great opportunity for technology access. But each of the key touchpoints in this access -- technologies, vendors, groups of users, and capital -- runs day-to-day on an agenda independent of the others.
Meanwhile, a company targeting technology access is running day-to-day on a mix of divers operations and users that generates many disparate demands, both planned and ad-hoc.
The result: supply and demand do not "self-organize" into well-matched sets. The connections have to be planned.
A technology access plan always navigates a path from the options provided at the access touchpoints to the necessities generated amongst the many company demands.
Normally, the path laid out will try to explain why the ultimate access to the targeted technology will be successful. But this level of concern is not the right place to start. Rather, the starting line is back where the "necessity" for the proposed access is being formulated and accepted.
Failure to clarify that formulation and its terms of acceptance will lead to technology implementations that fail to be adopted by the targeted users. Naturally, this adoption failure eliminates most of the basis on which productivity and ROI was predicated, while also ramping up sunk costs, contingency/recovery costs, and opportunity costs to fearsome levels.
The political fallout of the situation can be summed up as reactions to failed expectations of the implementation. For that reason, understanding the ideas about "necessity" that drove the implementation must involve the psychology of the expectations.
This explanation of "necessity" begins with the problem of identifying goals and assessing opportunities. Their combination is the basis of the behaviors that characterize the approach to the implementation.
These behaviors are mainly directed by beliefs, which are typically set forth as requirements and priorities.
Let's see how behaviors and beliefs interact to generate the perspective on "necessity":
This exposes the bases of how value is being attributed to whatever happens next. A key point to note here is that not all decision makers start at the same question in this matrix, and multiple stakeholders (different participating decision-makers) may not agree on the answer to any given question.
Such variety of perspective must be reconciled if the path to adoption is going to be successfully completed. Furthermore, it is important to not leave any of the matrix's four questions unanswered -- which partly explains why reconciliation will be challenging: no one gets let off the hook. To make the point even clearer, let's look at how this fundamental matrix translates into management-speak such as approval criteria:
Now it starts to emerge how so many business cases and other justifications produced may not logically account for adoption of the implementation even though they support approval to do it. The approval criteria (goals, capabilities, resources and effects) tend to test the current state of acceptance about specified conditions. This current acceptance is based on the interaction of factors that generate the "working versions" of reality and desire. (For example, consultants who provide assessments normally work in these terms, ofering a chance to validate or audit the presumed current state versus the "actual" current state, thus gauging a client's "readiness" and/or a tool's "compatibility".) By logically connecting the issues (clockwise within the matrix) from Goals (top left) to Effects, a comfort level is reached for approval, based on a story of "how this makes sense".
But the remaining problem, which is demonstrated by implementations that fail to be adopted, is the problem of "why" the implementation makes sense.
The key to exposing this is to understand that implementations work when they corespond to the behaviors that the company wants. And we know that behaviors are directed by beliefs, so the expectations of the implementation must correspond to beliefs. To represent this correspondence -- and get to the root of the "necessity" thought to exist -- the company must be willing to understand and agree on the terms of "why", which are more about the company itself and explain what the imlementation is actually supposed to address:
Again moving clockwise, from Motivations on around to Benefits, can the company confirm the logical links all the way around, and in particular, is the last link -- betwen the benefits and the motivation -- revealing something that can be attributed to the impact of the implemented technology?
The vocabulary of our last matrix challenges the specification of the implementation to describe enablement and support in terms of the company, but will reveal whether the company knows itself well enough to successfully adopt an implementation with reason to presume effectiveness. This is particularly critical in cases featuring multiple stakeholders, who hold the adoption cards rather than the approval cards.
Posted by Malcolm Ryder at 8:13 AM | Comments (0) | TrackBack
July 20, 2005
Managing versus Measuring: IT's Value to Business Performance
At CIO Decisions Magazine, Thorton May serves up results of an excellent survey of approaches being used to understand the value of IT to the business.
In general, the results indicate that the practicing managers of corporate IT range hugely in their established opportunity and intent for representing the way IT impacts business performance.
The survey does not investigate what lies behind the opportunities, so we don't get into the availability of time and tools that create the "business-perspective" visibility on IT. However, it is axiomatic that the way you look for something determines most of what you can see. In that regard, "formulas" that represent IT influence are more important than the tools and time used to apply them.
The four most important "takeaways" of Thornton's discussion are:
- IT is pervasive in the business the same way that management is pervasive, so it may be illogical to try to isolate "IT value" as a single global variable except in the various specific contexts (occasions) of IT usage.
- There is a difference between "value" and "performance"
- Measurements representing IT influence are not always numeric.
- Too much measurement is more bad than good.
One possible cause of the persistent confusion about value in IT is that the effort to connect IT Value to Business Performance doesn't make sense until after the connection of IT Performance to Business Value has been established.
If IT outputs are first associated with conditions that the business defines as important to the business, then a logical representation of "IT performance" exists. IT execution can be measured in those terms of performance, thus a picture emerges of when, how and why IT contributes to the enablement threshholds that the business agreed are needed for business functions to have their shot at meeting business goals.
Thus having the "business value" of IT performance defined, managing IT execution is a straightforward effort to have IT performance meet business needs. As a start, this is exactly what should be represented by a service level agreement (SLA).
Then, the performance of the business is nothing less than the results obtained from the business's execution of functions enabled by IT's performance. Presumably, the business has some functional targets to hit, which will be how business execution will be rated for its value to the business.
The biggest issue emerging from this is the need to separate the business's achieved capacity of enablement from the business's achieved competency of capacity utilization. IT can provide the capacity of enablement, but (contrary to the mythology of automation) IT simply cannot make the business use the enablement wisely.
If the business does not have working definitions of those two things, that furthermore unfailingly distinguish them from each other, there is no reason to believe that IT's influence on the business performance can be logically designed, tracked or analyzed. Naturally, this also means that no attempts to determine ROI are actually meaningful; instead, they are simply sophisticated statistical fictions prone to being evangelized or rejected by company politics.
The only exception to that assertion is the case of IT actually preventing a business function from being executed -- a huge issue driven by the way that the business relies on IT. In this case, we think in terms of a "negative contribution" -- one that is usually either unexpected or not officially tolerated. But in this case, what is important is to not suddenly have a double-standard of measurement methodology. If the contribution measurement philosophy is based on describing how IT relates to intended consequences, then the description must also neutrally cover how IT relates to unintended consequences. As we do this, it is important to neutrally separate IT's relation to desirable consequences and undesirable consequences.
This neutral and comprehensive perspective, which prevents arbitrariness in political tolerances, forms the basis of understanding otherwise neglected issues such as opportunity costs incurred by the influence of one IT implementation versus another. Since the business is responsible for deciding on those tradeoffs, it is clearly a matter of management and strategy more than of IT per se. When "negative contributions" occur, they must be defined and recognized -- as the results of:
- either bad decisions or bad enforcement that should not be politically written off;
- or bad luck (such as natural disasters or external attacks) that probably should be politically written off.
Posted by Malcolm Ryder at 8:11 AM | Comments (0) | TrackBack
July 19, 2005
Management Performance versus Performance Management
All businesses want a return on their investment, and ROI considerations nearly always begin with a valuation of the assets to be consumed.
However, one of the key themes amongst items posted here at Archestra is the idea that an "asset" is not the same as a "resource" -- and that it is the value of the resource that needs to be managed, not the value of an asset.
In this view, an asset becomes a resource when it is given and maintained for a certain assignment; in a performance perspective, the value of an asset without an assignment is "undetermined"... So to the extent that people, processes and technologies are dealt with as resources, the whole ROI situation rests on the competency of the managers who turn assets into resources, and the performance issue has to do with the results of management.
This always makes me sort things out by thinking in terms of "management performance" rather than "performance management" -- and it differently organizes the thinking about what kind of things really need to be measured for their "results" (outcomes).
The claim here is that management outcomes, not asset inputs, are the building blocks of what is referred to as "performance", and the value that is associated with assets can never be separated from the way they are managed -- except when the assets are simply being bought or sold "on the market".
Industry analysts characterise the practice of Performance Management as one in which alignment of people, processes and technology to common objectives is the lever for generating the desired value and effectiveness of those people, processes and technologies -- while the motivation for the alignment is to improve "business results". It is noteworthy, we think, that business results might be measured differently from its components' value and effectiveness, but perhaps annoyingly we have to be able to do so since we know from experience that both luck and "winning ugly" do happen and also that best practices don't always cause best results but rather merely allow them.
Parsing that within the perspective of assets versus resource management means seeing things as follows:
- execution is the utilization of the resource,
- alignment is the compliance of the execution to objectives,
- performance is the outcomes of the execution
- value is the significance of the performance
This ultimate focus on value (as defined here) replaces the typical narrowness of "financial impact" and allows "strategic impact" to come full force into the picture. Likewise, it broadens the concept of "returns" on the investment into a set of concerns that more accurately and comprehensively describe the realities of what allows a business to be successful -- not just arbitrarily in the moment such as at quarterly report time, but over the life of the business as represented by the sequence of positions in the market that it could (and did) hold. This is where "significant" things such as risk mitigation, change management, quality improvement and other critical business enablers and sustainers come into play as goals.
Also pushed aside is the narrow definition of "assets", since identifying resources is more important and we know that things such as time, relationships, knowledge, permission and position are all resources along with money and labor (skills and tools). This goes a long way towards explaining why a concern with performance management sprouts in so many different occasions and sectors of the enterprise.
The punchline, though, is that what really must be attended to is the effectiveness and value of management, and the logical target payoff of so-called performance management is not a return on assets but a return on management.
Posted by Malcolm Ryder at 7:44 PM | Comments (0) | TrackBack
Fast, Pretty, and Cheap
Bob Evans over at Information Week wrote up the importance of HP's new CIO Randy Mott to its strategic needs. Mott is the mastermind behind Wal-Mart and Dell superiority in IT enablement of business performance.
Is strategic success portable? Evans points out that, "During the five years Mott was CIO at Dell, the company's revenue grew more than 60%... among Mott's biggest contributions were helping the IT team set strategic priorities and putting in place global standards... At Wal-Mart, Mott specialized in cutting latency out of the supply chain and ultimately increasing customer intimacy by helping to ensure that the seller was offering what the buyer wanted, when the buyer wanted it, and at a price the buyer accepted. As a result, in the six years that Mott was Wal-Mart's CIO, the company's sales almost tripled..."
Clearly Mott is a guy who knows how to get things done. But let's recap that: Mott focused his (IT) operations on three things:
- speeding up the runtime throughput of operational processes
- aligning IT's support of the business to its clarity about buyer's requirements
- making that sustainable and affordable in a way that allowed continuous progress over several years.
In a nutshell, he made operations fast, pretty and cheap.
The official joke about fast-pretty-cheap is that you can pick any two of them but you can't have all three. But evidently, getting all three really is possible, and when it happens you become Number One in your niche.
So, what's interesting to think about is how those three impacts rely on each other. In general, we're looking at how the operation establishes a fit with (a.) its environment, (b.) with the prospective customer/beneficiary, and (c.) with the market. When productivity feeds quality and quality feeds acceptance, you get a winner.
Faster operational throughput presumes that the chain of inputs and outputs that link functions and processes together is "streamlined". That is, the functions and processes all know what is the right direction to go in, and they offer little resistance to the environment they are moving through. "Efficiency" is an easy way to refer to minimizing resistance while strengthening direction, but policies and standards actually go directly to the problem in a more profound way. By reducing the number of operational variations that will be attempted in the first place, policies and standards reduce the volume of necessary downstream corrections and distractions, while making it easier to recognize when recurring activities are actually generating benefits or risks.
Clarity about the impacts of activity underlies operational quality, and quality is pretty. Impact clarity means that the downstream benefits and risks of most importance can be targeted more accurately and confidently. As a result, quality promises can be made more rationally and certainly, which increases the customer's interest and attraction.
Customer requirements come from the perspective of the customer's needs, and the greater the need is, the more valuable it is to satisfy the need. But meanwhile, the usual laws of supply and demand apply. The availability (supply) of that satisfaction is a strong lever in prices. But the customer's need (demand) can also range in two ways: from critical to merely discretionary, and from few people to many. So, the smart business wants to focus on the most valuable "sets" of requirements. By tailoring the fulfillment operation to quality for a particular importance and volume of need, economy of operational scale is easier to determine, and improvement there allows more attractive pricing and coverage for customers. Then, of course, what finally makes quality inexpensive to produce is better sales that readily pay off the investment in quality.
So the fast-pretty-cheap trick is not about which one of them to leave out. Instead, it is about how to order and align them. This also reflects CIO Mott's approach when he first arrived at Dell. His first steps were to reduce the number of planned projects by 90%, leaving only those most important to business capability for making products more marketable and sellable. Recognizing that cost is always a critical issue, his initial emphasis was actually on prioritization and focus, not on cost. As Bob Evans quoted him saying, "once we got our priorities set, we were able to be a lot more effective." And we know that both Dell and Wal-Mart are price leaders as a result of their effectiveness. It looks like the best way to reach "cheap" is to stop wasting effort, and do the right work.
Posted by Malcolm Ryder at 7:55 AM | Comments (0) | TrackBack
July 18, 2005
Collaboration and Analytics: driving production with intelligence
Most organizational managers may not admit it, but the myriad complications of managing costs lower in order to increase net operational gains mean that this approach hits a point of diminishing returns much sooner than anyone prefers. Thus, in order to increase value, the approach of growth-oriented management becomes an immediately critical alternative to cost-orientation. Collaboration and analytics are two of the strongest tools for leveraging existing resources towards value-generating growth.
How? Collaboration and analytics are two modes of discovering and synthesizing intelligence for driving production.
As such, they are both decision-support mechanisms that can make a critical difference to the effectiveness of operations within the time-span of the operation's execution.
In decision support:
- Collaboration, using coordination, especially integrates varied expertise to create competencies from at-large communities.
- Analytics, using formulae, especially distinguishes latent patterns to create information from data collections.
How do coordinating expertise and formulating patterns contribute expertise and information, at a level particularly critical to production value?
Actually, Collaboration and Analytics each provide competencies and information, to recognize and productively incorporate new and unexpected influences -- in less time.
One view of this involves seeing them work together.
Collaboration can leverage analytics by using analytical findings to support decisions that adjust or guide the integration within collaboration. An example of this would be to have, based on forecasts, certain links in a supply chain modify their individual current outputs and/or output schedules to preserve the timeliness, cost limits, volume or quality of promised deliveries.
Conversely, larger data collections can be developed more quickly via collaboration; so, analytics can leverage collaboration to explore a wider range of alternative data sooner. This, within a given time period, can produce more patterns and/or perform more validation of given patterns. An example of the former benefit is identification of viable product alternatives that attract new business or contingent actions that reduce risks; an example of the latter is determining from multiple perspectives whether an idea really meets a quality standard for stakeholders, such as through a peer-review process in academia or in business approvals for complex proposals.
In practicing collaboration or analytics, a basic problem is one of providing an underlying model for organizing the activity. However, in collaboration there must be a model for putting things together, and in analytics, a model for taking things apart. For that and other reasons, another view on their potential delivery of benefits must consider the two techniques separately.
Collaboration is a special form of co-operation, in which all participants are adhering to the same goal for the same reason. The model that is needed in collaboration will, in effect, offer operational objectives to be mutually respected by all participants. More importantly, the model, usually called a "policy", will prioritize activity options that are offered by the various participants or that develop as interim possibilities during operations. This sounds very much like how any process is regulated, but the difference is that in collaboration the operation is constantly open to new inputs that were not anticipated before the operation started. Collaboration therefore requires the ability to effectively re-organize the operational integration based on the new inputs. Distinctively, while the operation is already in progress, a collaboration invents the solution to reaching the goal.
Analytics is a special form of de-composition, in which a pool of data is tested for its key contents -- namely, what it might include that is pertinent to a given fact or assumption. The model needed for analysis, usually called a "hypothesis", describes cause-effect relationships behind "factual" events or conditions (states). However, in an attempt to discover and confirm significant relationships, the analysis must isolate and identify the key factors of the relationships -- thereafter looking for clues or evidence of the factors. Sometimes it turns out that the "suspected" factors are not the real ones, or that the factors presumably needing to be investigated are not relating as suspected. This detective work is usually mandated as auditing; but the difference is that in analytics (for example, with weather reports), it is more important to discover possible futures than the confirmed past. As a result, although analytics are typically used to find proof of something, the primary basis of value in analytics is actually an objectivity that is focused on credible explanations agnostic to the data.
In those various ways, collaboration and analytics should bolster management-based effectiveness. But what does that look like? It's fair to look at progress from the "performance" perspective that a business typically brings to measuring effects; progress means both sustained improvements in operational quality and timely development of desired business advantages. Since there are many management techniques for pursuing those outcomes already, what motivates an embrace of collaboration and analytics?
An important issue clearly suggested by collaboration's inventiveness and analytics's neutrality is innovation -- or the ability to take new approaches to problems, due to having freedom from prior restraints such as resources or points-of-view.
Yet "continuity" is no less important to support. Here, collaboration and analytics matter when a breakthrough is needed for progress that is not, so far, being successfully driven by the capacity of solo efforts. Flexibility and objectivity (as supplied by collaboration and analytics) are key to getting the needed breakthrough.
The challenge is that managing operations towards a repetitive sameness is a technique we have fully embraced in the name of process improvement. Yet all processes are constantly confronting the eventuality of change at many different constituent levels including their resources, controls (management) and beneficiaries (perceived value). The danger of protecting "as is" processes is that they will become inflexible or irrelevant over time -- in short, counter-productive. The shift in operational habits that collaboration and analytics both encourage is straightforward but potentially profound. It is nothing less than a different approach to effectiveness -- requiring us to:
- stop protecting (in the name of efficiency and predictability) the "as is" form of operation; and instead,
- work to grow the operation's effectiveness by continually shaping it to broader opportunities that are more extensively qualified.
For some managers, this may throw their dedication to "optimization" under unexpected pressure. But in that case, it becomes appropriate to give the idea of optimization a revised context, by working on it specifically to support operational growth. An example of this approach is the attention many managers give to pursuing optimization mainly within the guidance of maturity models that are growth-oriented, explicitly sensitive to how the manageability of change (i.e. agility) regenerates and multiplies capacity over time.
Posted by Malcolm Ryder at 9:07 AM | Comments (0)