« How Maturity Models Drive Timely Value-Capture | Main | Communications in Performance Management »

August 5, 2005

Value Capture through Execution

What is the real point of an IT business case?

Most proposed changes to the IT infrastructure of a business are intended to make "execution" better. Better execution goes by many names: productivity, efficiency, resilience, intelligence, and more. Since a proposed change typically competes for attention and support against other proposals, the idea of "better" cannot be separated from the sense of what is "necessary"... This means that agreement on priorities must occur, and the black arts of winning agreement commence.

Certainly, the job of presenting a business case is to win the agreement, just as a prosecutor or defense lawyer is out to win. Yet in competition, these adversaries are unified in taking the same piece of strategic advice: "Don't confuse your issue with facts!" In other words, they openly give each other permission to exercise poetic license. But if your business decides to accept this modus operandi from its managers, then it should also just dispense with the requirement to argue in terms of ROI, as well.

In fact, the ROI bit is often misguided, anyway. If building engineers were held only to the standards that ROI calculators so often are, we've have to conduct the business mainly in large disposable tents. Why build a business case that won't stand up?

Instead of ROI, the business case should be argued on value. Strictly speaking, value is what you call the importance of a difference. If that importance is measurable in dollars then so much the better; but since the dollars come from the value, you first have to make the value . And just how is that done? A business case must be able to identify and convey the value generation. To do that, it has to start with a logical understanding of the phenomenon.

Let's start that with a solid working definition. Execution is: the pursuit of a goal, as based on certain enablers (means), in the context of desired types of achievement.

Organizing activity in terms of execution is the typical result of planning. Plans therefore might be prescriptions, formulas, methods, programs, or other designs for interaction and interdependency of activities.

According to the achievement level realized in execution, we say that a certain "performance" has occurred.

According to the importance of that performance in its context, we say that "value" has been generated.

The most straightforward example of a practical context is an objective. That brings us to the key point: that value accumulates towards an objective, and different types of value may collectively apply to a given objective. (For example, imagine watching various contributions of cash, supplies and services push up the red dye in the big "thermometer" poster used to advertise progress in a fundraising campaign...)

The objective represents a concern such as a perceived business need -- essentially, a strategically critical success factor of the way the business believes it must be or act in order to generate "business success". The most straightforward description of the business success is (when properly defined) the mission statement. Usually, a mission depends on several different things coordinating and cooperating effectively, which indicates that there is a variety of ways to add value. At any time, based on the collective effect of those things, the status of the pursuit may thus be deemed more-or-less "successful".

From that perspective, the proposal's idea about changing the way that the business is enabled to execute must always be, logically, about:
- improving the value of its performance, which means...
- improving the achievement of its underlying execution, which means...
- improving the effects of its enablement.

Therefore, any enablement option is meaningful because of its presumed and targeted effects; this describes the basic level of discussion of a business case for an enablement proposal.

Will the witness please answer the question!
Typically, enablement is seen as a deployment of resources, with the now classic categorization of resources being people/process/technology. Of course, there are other resources -- such as time, money and permission -- that are equally critical. But here, the main point is that investment in enablement will be directly attached to ways that resources are affected (moved, added, changed, combined, deleted), and those ways will be described in a plan. The resource view of the investment, however, is merely the left side of the proposal...

The right side must attach the investment directly to the execution that will drive "performance." How? Since value is derived from execution-in-context, and since the context is about what kind of difference is made, then what must be understood is the difference claimed to be addressed by the type of enablement proposed for funding.

As described by example of the following chart, this is a general perspective on planning and justification. The chart gives answers to the question "what is it about the business that the proposed enablement will affect, and how?" The answers to "what" are (across the top) aspects of the business for which improvement is a desired benefit. The answers to "how" are (down the left side) itemized issues that represent success factors addressed in the planning for performance.

In viewing this chart, it is important to remember that the overall business goal is not "value" but instead that the goal is a "mission success" -- a success that is predicated on the value added, by execution, towards business benefits. These benefits (across the top), which are high-priority for the business, are thus understood to be "objectives"... Finally, in our scenario, where the proposal is going to bring a "new" configuration of technology to the existing situation, the IT organization gains more power to enable the business -- which makes the IT organization more successful; therefore, the types of enablement that the proposal identifies are logically seen as "objectives" (down the left side) of the IT organization. This lets us understand why funding the proposal is an investment in both the business objectives and the IT objectives.

What's clear from the above is the investment idea of value for money. Each of the issues in the chart (such as exposure, efficiency or capacity) is an opportunity to generate value, using the support of funding. What's important about the detailed logic of the discussion is that "value" is not left casually misrepresented by so-called ROI. Instead, value is something showing explicitly why the proposal makes sense; and in turn, that provides more logical support for economic impacts that are associated with the proposal. Without establishing the logic of the value-generation, calculations of economic impact are speculative.

Punchline: ROI does not validate the business case; instead, the business case validates the ROI.

Posted by Malcolm Ryder at August 5, 2005 3:08 PM

Comments

Post a comment