In this Cutter Consortuim Executive Update, we introduce our top five guidelines for helping projects deliver business value. These guidelines allow the project manager to focus on delivering business value when he or she is under pressure to deliver intermediate work products or software. In addition, they show where effort should be expended on a project to derive the most benefit.
THE FIVE COMMANDMENTS
1. Deliver Business Value, Not Features
Most project managers want the best for the business. With that said, it’s interesting to note that many managers end up focusing on the process, the documentation, or the software rather than delivering value to the business.
Traditionally, projects are scheduled according to the functionality provided rather than the amount of business value delivered. In our experience, many projects slice the requirements (i.e., dividing requirements across multiple deliverables) such that operational costs, rather than business value, increase. Projects should be phased to deliver based on business value and cost. Quite simply, a project creates business value when it increases or protects profit, cash flow, or ROI.
Business value was the driver behind a project we worked on recently. The project involved a credit risk effort to manage the exposure of a company in the event that a counterpart goes bankrupt. The original business case introduced a system that would reduce losses by 20 per cent if that situation were to take place. It then examined the defaults for the previous year and projected them forward to derive an annual value of the system.
This value was challenged on two fronts, however. First, the number and size of defaults for the previous year (which was the year Enron and WorldCom filed for protection under U.S. bankruptcy laws) had been exceptionally high. Second, no one knew how the system could reduce losses by 20 per cent.
With the business value model, we took a completely different approach. It turns out that the credit risk department did not trust its existing system. As a result, the credit limits were lower than desired, which was restricting the growth of the business. A new system should be more accurate and allow credit limits to be increased. The business value looks something like the following:
-Current profit = $10 million
-Increase in business = 10 per cent
– New profit = $11 million
-Current losses = $1 million
-Increase in losses = 10 per cent
-New losses = $1.2 million
-Net profit = $0.8 million per annum
-Estimated project cost (over 12 months) = $1 million
-Net gain over five years = $3 million
2. It’s a Model, Not a Number
Business value should be presented as a model rather than a statement. This allows the business value to be challenged and reevaluated as conditions change or further information is discovered.
It is almost impossible for business management to make a sensible decision when simply presented with a statement such as, “This project will generate an additional $15 million in profit.” It is much easier for management to assess such a statement when also presented with a model in which the model developer states the assumptions and inputs. For example:
This project will generate an additional $15 million in profit. The model is based on the following assumptions:
-We achieve 20 per cent of the sales of existing product XYZ ($100 million a year).
-The total cost of designing and producing the product is $5 million.
– Our product is first to market.
– We are able to release the product two months before Christmas.
In effect, the project builds a financial statement with explicit assumptions about market conditions, revenues, costs, and risks. It’s important to remember that the model is not the goal, but rather a tool to achieve business value. The model should be barely sufficient, providing just enough information to enable senior management to decide whether to continue; anything more is a waste of time and energy.
Defining business value is difficult because it’s often hard to see what’s wrong with a business value statement. It may feel right, but without proper understanding, it can destroy rather than create business value. Let’s look at some examples:
“Project X will generate revenue of $1 million.” This statement is expressed as an absolute rather than a model. The greatest problem with this statement is that it’s impossible to reevaluate the business value if market conditions change. Further, there is no mention of the cost of generating this revenue or the amount of capital investment required to generate the revenue. This investment may deliver less than the required rate of return for the organization.
“Project X will generate savings of $1 million.” As with the previous statement, conditions can change, resulting in the savings not being available or another solution emerging. Projects based on savings must be carefully monitored, as any increase in costs eats directly into the savings. In addition, you need to know what generates the savings to ensure that the project implements these things correctly.
“Project X will automate the current manual process.” This focuses on a specific solution without detailing the benefits or costs of implementing the change. Automation for its own sake is not always a good idea. The emphasis should be on business value (which may result in automation) rather than on automation for its own sake.
“Project X will deliver world-class operations and systems.” Once again, there is no reference to business value. World-class operations for their own sake may destroy value. A better statement would consider unit costs, customer service, or ability to adapt to exploit opportunity, all quantified to identify the business value they generate.
“The regulator will shut us down if we don’t do this.” This statement may be true; but what is the loss of profit, and how much will the project cost? It may well be that a more minimal approach is appropriate. In response to new regulations, some organizations create multimillion-dollar solutions, whereas others create a manual process involving a spreadsheet.
“Project X allows us to achieve straight-through processing.” This is a solution, not a statement about business value. Once again, the business value should be identified and an appropriate solution adopted. Implementing straight-through processing may cost more than its business value.
“Project X provides a real-time profit-and-loss statement.” This is a description of a feature. How does the real-time profit-and-loss statement generate business value? In reality, it may be a nice-to-have feature for an important member of the organization — in effect, an “ego app,” which is prevalent in many organizations. If the individual is a senior executive, a project team may begin delivering his or her requirement without fully questioning the reasoning behind the request.
3. Deliver Business Value Today
As Tom Gilb observes, “Traditional phased planning is based on ‘trying to do it all at once.’ It starts by asking the question: ‘How much can we deliver within our recognized constraints?'”
Gilb advocates delivering systems on an evolutionary basis, pointing out that we create more problems than we solve when we try to estimate the costs and plan for and implement such large systems. We agree that an incremental approach is best; it helps deliver the most important parts of the system early and often. A project should deliver business value on a regular basis, with small increments being optimum. The longer you take to deliver an increment (we get nervous about an increment that takes longer than three months), the greater the risk that the business will have changed in the meantime.
To choose the best delivery strategy for the credit risk system project, we broke down the high-level requirements to demonstrate the business value for each component:
-Calculate exposures — 25 per cent
-Collateral — 25 per cent
-Manage limits — 20 per cent
-Synergy — 30 per cent
Each component was broken down again. For example, the collateral portion was broken down further into five parts: letters of credit and four other kinds of collateral. Despite the fact that letters of credit form only 20 per cent of the requirements for collateral, they account for 75 per cent of the business value for collateral as a whole. In other words, we get 75 per cent of the value from only 20 per cent of the work. The business value for letters of credit, therefore, is $56,250 ($3 million net gain from the above value * 0.75 * 0.25).
This value was logged against the letter of credit requirement (or in the nomenclature of Extreme Programming, an “XP story”). The business value for the other kinds of collateral was not sufficient to justify the cost of their development.
Once the business value had been allocated to all the XP stories, the business sponsor chose the stories for each iteration based on their business value.
4. Continuously Reevaluate and Improve
The business environment is continually changing, so with each delivery, you should reevaluate the business value model to ensure that the project is on track. Further, you must reassess the business value model with what you have learned from the components that have already been delivered. Business value tells us when to stop. When the cost of implementing subsequent requirements is greater than the business value generated, the project should cease until either more business value is identified or the costs are reduced.
5. Conduct Acceptance Testing
We always encourage project managers to write business value acceptance tests, which are specified in advance of the development. The intention is to expose the provision of the business value so we know when it has been achieved. Where appropriate, the tests should be automated. They are used in both user acceptance testing (does the system do what we want?) and post-delivery testing (does the system deliver what we expect?).
Post-delivery testing is critical to determine how well the system actually delivered the planned business value. By continually monitoring the actual business value delivered, the business is in a better position to make sensible strategic decisions about future system releases.
BUSINESS VALUE AND AGILE PRACTICES: Agile practices complement business value. They deliver value early, which increases the net present value of the project. To develop a system, the project should develop a business value model and then allocate a portion of the value to each requirement. The business value should be recorded against the requirement, for example, on the XP story card. A graph of business value against time can then be plotted to show the progress of the project.
