In an effort to justify IT investments, we have increasingly looked to quantify the "business value" of projects. While there is merit in doing this, in practice it can generate more heat than light. There is a limit to the accuracy with which we can predict the future, how much data we can collect, and the extent to which business decisions can be expressed as mathematical formulas. The result is that "business value" is neither ubiquitous language for IT projects nor an absolute measure of IT effectiveness. Still, there is value in business value: properly applied, it provides guidance for project decisions and is another mechanism through which IT aligns with business objectives.
Not Every Dollar of Business Value is the Same
The first thing that usually comes to mind when thinking about "business value" is revenue or cost savings resulting directly from an initiative. But business value can take other forms. It can be represented by costs that are difficult to show, such as risk reduction or employee turnover. It can also be intangible things which simply make the business more competitive, such as greater brand awareness. These variations make business value apples-to-carrots-to-high-fructose-corn-syrup comparisons, and a single definition elusive. There are also limitations to just relying on numbers: they lack context, are more estimate than fact, and may not reflect the full scope of a situation.
When estimating value, we have to take into account the business context. Consider an initiative designed to build brand awareness that might not create customers until the following fiscal year. In pure accounting terms, this might appear to be a less attractive
Advertisement
investment relative to other projects. However, if the business cycle is such that it takes that long to convert a customer, we recognize that it would be very dangerous to do something that undermines the future of the business. Context, then, can be difficult to capture in a formula.
There is a limit to the confidence we can place in business value numbers. There are time and resource limits to estimating, collecting, and analyzing results. In addition, estimates and analyses aren't facts. We can forecast revenue, but we must realize that forecasts may not materialize. We can analyze changes in revenue but may incorrectly conclude reasons for variation. The same can be said for estimating cost reductions. We can estimate savings for doing something, and estimate costs for not doing something, but these estimates are laden with assumptions. For example, we can assert that not making a marketing investment will create a revenue shortfall that will lead to higher cost of customer acquisition. This might be true, but any effort to quantify it will be mostly conjecture.
Finally, we have to consider the completeness with which an IT solution delivers business value. IT solutions are typically not turnkey, but one component of a larger business initiative. If a solution is customer-facing, it must have proper marketplace promotion; if internal it must work with effective supporting systems. It is, subsequently, difficult to measure the impact of the IT contribution in isolation.
This is not to say that business value is without merit, only that not every dollar of business value is the same. In an IT context business value is an important indicator of the potential business impact of IT systems delivered, and is a useful source of guidance for project decisions. However, there must not be an expectation that this is ubiquitous language for IT projects.
Business Value Pile-On
Even within a single initiative, business value can take multiple forms. Consider the following situation:
Due to a new financial accounting standard, existing investments and their derivatives must be revalued by the end of the current quarter or earnings in a future period will have to be restated. Restatement is a catastrophic event that would cost millions and undermine the stock price.
This same regulation will also affect corporate finance decisions regarding future investments. These decisions occur daily and are subject to the same regulation. Finance requires new analysis tools so that these decisions can be optimized.
Finally, this regulation increases operating costs. Operational efficiency will reduce under bureaucratic burden, and quality problems may creep into the exercise of compliance.
In this scenario there are multiple forms of business value:
Bottom-line impact of a re-statement of existing assets as well as optimizations of future investments;
Loss of investor confidence that could damage the stock price;
Ongoing business risk of a restatement due to inadequate process; and
Operating costs.
The combined "business value delivered" in this scenario is not the sum of satisfying all of these objectives because:
The catastrophic restatement is based on current data.
The cost of sub-optimal investment decisions cannot be known until the problem is modeled.
Ongoing risk mitigation is the cost of failure by the probability that it will occur. While risk assessment is unquestionably valuable, the value lacks accuracy as a statement of "business value" compared to the restatement and optimization costs.
While the compliance cost is real, determining that cost is guesswork. Furthermore, the initial implementation is likely to be sub-optimal, inflating the cost of compliance. Cost reduction achieved by improving on a poor implementation is dubious "business value."
The loss of investor confidence is difficult to estimate.
There are people and process factors beyond the IT component which will determine success or failure.
In this example, there is not a "total business value of IT contribution." There is, however, valuable guidance for the decisions that will be made over the course of the project.
Shaping Project Decisions, Influencing Portfolio Decisions
One of the most interesting Agile practices is that requirements are expressed as independent, valuable, granular expressions of business need. Decoupling requirements, assessing a business value for each, and delivering in an iterative fashion provide a more factual basis for presenting cost versus benefit. Even if requirements are decomposed into collections of tasks, none of which completely satisfy the business need, there is still traceability of everything being done to business value. As the saying goes, "what gets measured is what gets managed." Keeping focus on the business intent over the technical solution reduces wasted effort.
Having business value front-and-center can also impact the way requirements are shaped, leading to better solution fitness. It may be possible to stratify the portfolio such that three independent requirements respectively eliminate the restatement risk of 45%, 30%, and 22% of the total portfolio value. It may turn out that it will be less expensive to revalue some assets manually than through an IT solution. It might also be possible to code a "simplified valuation model" that may lack accuracy but better matches the finance department's capability to respond to this new regulation. Business value, then, can have an impact on how requirements are shaped which, in turn, should lead to better project decisions.
Business value can also influence project portfolio decisions. With contextual awareness, one project can be compared to other projects in the same class (e.g., what is the cost of acquiring customers through other means?) More importantly, it is easier to assess whether a specific project is, within its context, continuing to meet its business case.
But this is where we must be careful not to run amok with numbers. Every project balances time, people, quality, and business needs. While those needs can be expressed in accounting terms, the confidence, context, and completeness of those numbers make them potentially incompatible expressions of "value." Reconciling all of these to maximize return on technology investment over the course of a project requires skilled project management and a highly collaborative business-IT relationship; a financial model cannot substitute for this.
Deriving Value and Respecting Obligations
Requiring an assessment of business value for each requirement helps to shift the language of a project from IT-speak to business-speak. This creates several additional benefits:
Project decisions are more likely to be taken relative to intent, not technical requirements, because all tasks can be critically analyzed as necessary to meeting the business objective.
All project members become drivers of business imperative.
Business Analysts become more effective, working less as "requirements scribes" and more as "assessors of business impact."
People in IT become more acutely aware of their contribution as business impact cannot be assessed until after solutions are in production.
While this can influence better business-IT collaboration, taking it on carries a set of obligations:
Because IT deliverables are rarely independent of people and processes elsewhere in the organization, business and IT leadership must make all participations solution aware.
There must be accountability for "business value" estimates and measurement of business value achieved, so this isn't gamed. For example, a system produced because it is expected to yield cost reduction should trigger a reciprocal budget reduction upon delivery.
There must be a commitment to post-flight, holistic analysis of the impact of what is delivered with the intent of improving the organization's business-value estimation capability.
"Partial credit" cannot be given for business value delivered. Any amount of business value delivered must be available, in production, and independently making a contribution to the bottom line, or it is not realized.
In doing these things we strengthen our confidence in our assessment of business impact, and their value as guidance improves.
A Strategic Indicator
Using business value to qualify IT contribution runs the risk of reducing IT to a transactional service and potentially undermines its partnership with its business partners. Business value should instead be used as a communication vehicle, a means by which the business-IT partnership can be strengthened. By shifting the conversation to the business, and interpreting the subtleties of the numbers, IT can use business value as a means by which to align IT with business objectives and enable it to better become a driver of strategic imperative.
About the Author
Ross Pettit has 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement. He is currently Director Professional Services for SourceForge Enterprise.
Articles 
