The business case: What to do after the pitch

The key consideration to remember is that the business case is not only a vehicle to "sell" a project, but also a critical tool to evaluate and guide a project, tying its ongoing activity back to the company's strategic and tactical objectives.

In Part I of this two-part series, we discussed the three critical components of a business case and spent some time reviewing the first of these critical components. As a refresher, every business case should contain three broad pieces:

  1. <!—[if !supportLists]—><!—[endif]—>The Pitch (business benefits)
  2. <!—[if !supportLists]—>Objectives and Measures (what does success look like?)
  3. <!—[if !supportLists]—> Failure Criteria (when to hold or fold)

Since The Pitch was covered in the first part of this series, let's move on to the other two critical pieces of a great business case that serves not only as a tool to initiate projects, but as a sanity check to determine how they are progressing and when they should be cancelled.

Objectives and measures

Many business cases struggle when it comes time to lay out the benefits of a project, and how they can be measured. We often rush into complex machinations to determine ROI and present cash values when the starting point is vastly more simple: asking the question "What does success look like?" Every project under the sun, be it a new IT system or a new design for an airliner will change the current state of affairs. Rather than trying to attack this new state of affairs from the detailed level, start with your vision of what success will look like and work to the details from there. This discussion also ensures all stakeholders in the project under discussion have the same understanding and vision of success. While the second point may sound obvious, many a project has delivered a system or series of processes successfully, but what was delivered did not align with all stakeholders' vision of success, rendering the project an overall failure.

With a vision of success firmly in mind and agreed to, metrics can be established around that vision. If a shiny new sales automation tool is under consideration, one element to the vision of success might be a more rapid acknowledgement of an order from the back office. Take this element of the vision of success and put measurable terms around it. Should orders be confirmed in two days? Two hours? What are the cost savings or "new money" that might be generated by the different outcomes? What are the best and worst case scenarios? Flush each element of your vision of success down to an objective with associated measures and you now have an understanding of the project's scope, expected outcomes, financial benefits and quantifiable results, something many projects miss right out of the gate. The objectives and measures are the starting point for the next section of a well-formed business case: failure criteria.

Failure criteria

While it may seem overly somber to begin contemplating failure before a project even starts, counter intuitively this is the absolute best time to do so. Recall a failed project you have participated in, and it was likely a woeful tale of long nights debating the merits of cancelling, weighing investing "just a few more dollars" in the project, or heated exchanges over whether the scope should expand, contract, or move in a completely different direction. Contemplating failure criteria before a project even begins takes the pain out of the process; no money has yet been invested in the project, no adversarial positions have been established, and no careers are at stake. Debating what might cause the project to fail is academic at this point.

Should the project hit a bump in the road, the business case becomes the bellwether as to whether the project should be cancelled. Rather than late-night shouting matches, stakeholders can look to the business case for independent guidance as to whether they should hold, fold or double-down. Failure criteria also can be invoked before a project reaches a state where cancellation is a frequent topic of discussion. Every stakeholder meeting should briefly regard the failure criteria for the project and see if any should become a focus of concern.

Failure criteria should target two areas: project and environmental. Project-level failure criteria are derived from the objectives and measures set out in the previous section. Ask your team what objectives are critical, and at what point they jeopardize the success of the project and require immediate and large-scale response.

Environmental failure criteria are those whose occurrence is independent of the project, but whose occurrence impacts the project. These might be anything from a change in market conditions, to a merger or acquisition, to the failure of a key implementation partner or vendor. Most IT shops are now going through a painful process of trimming some projects and abandoning others, work that could have been made vastly easier if some consideration had been given to environmental failure criteria during business case development.

The business case: It's alive

A well-crafted business case covering the three dimensions we have discussed clearly spells out what a project should accomplish, what success will look like and how it will be measured, and what circumstances might prompt a reconsideration of the project. With this information, "selling" a project is a much easier task, but as mentioned in Part I, this is not the most important function of the business case. As depicted in Figure A below, the business case is the glue between an organization's IT project portfolio and the day-to-day management of a project.

Figure A

 Every change to a project can be validated through the lens of the business case, and each decision affecting the outcome of the project vetted against the objectives and measures, or evaluated to ensure it does not trigger any of the documented failure criteria. In this role, the business case becomes an impartial judge and jury. If there is a valid change to a project that does not work within the confines of the business case as it stands, update the business case. Rather than remaining a static document relegated to a dusty shelf, this use of the business case as a "living document" allows stakeholders to know exactly where the project stands at all times, and allows the business case to remain a key decision-making tool even as the project organically grows and changes direction.

The key consideration to remember is that the business case is not only a vehicle to "sell" a project, but also a critical tool to evaluate and guide a project, tying its ongoing activity back to the company's strategic and tactical objectives.

Patrick Gray is the founder and president of Prevoyance Group, and author of Breakthrough IT: Supercharging Organizational Value through Technology. Prevoyance Group provides strategic IT consulting services to Fortune 500 and 1000 companies. Patrick can be reached at


Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

Editor's Picks

Free Newsletters, In your Inbox