Take a look at that beat up old aluminum bookshelf in the disused conference room, or in the remote corner of the CIO's or CFO's bookcase, and you'll likely find a dusty binder or two containing a long-forgotten business case. After hours of sweating through minutiae to complete the document and heated exchanges over its finer points, too often business cases end up nestled between volumes like Getting the Most from MS-DOS 3.0 and Punchcards: The Future is Now on a neglected shelf. Not only is this a wasted effort, but the business case just may be one of the most important, yet often neglected components of an IT project.
Most people are familiar with the use of the business case to justify a project. Essentially the business case presents the cost and benefits of a proposed project, and is used as a tool to "sell" the project to the organization. While this is an important function, it's not the most critical aspect of a business case. Rather than solely being used to sell the project, the business case should serve as a frame of reference for all critical project decisions on an ongoing basis.
A good business case offers a vision of the future of the organization as a result of some intervention (the project being proposed), and should be used as a tool to see if the project is actually marching towards that vision of the future. As we become mired in the operational aspects of completing a project, it's all too easy to make expedient decisions in the moment, and gradually wander away from the original intent of the project. These tiny changes in direction usually go unnoticed until after months or years of hard effort and expense, a project is delivered that does not meet the needs of the requestor. The work may have been successfully completed, but the wrong objectives were met, causing the project to fail. This is where the business case becomes an invaluable tool. If the project appears to be deviating from the course specified in the business case, a critical question must be asked: has the vision of the future changed, or is the project in need of a course correction?What's in the business case?
Before delving too deeply into the use of a business case as a project's "sanity check," it's worth reviewing the basic components of a business case. There is a great deal of detailed information that has been written about what should be in a business case, and rather than cover old ground, let's review the three critical areas every business case should cover, and how they relate to the success or failure of the project as a whole. Every business case should cover:
1. The Pitch (business benefits)
2. Objectives and Measures (what does success look like?)
3. Failure Criteria (when to hold or fold)
Not only should each section serve some function in determining if the company should proceed with the project, but more critically, the business case should provide the top-level measurement of a project's success. The business case serves as an overall barometer of a project's health once the work is underway.The pitch
The pitch is what most people think of when they consider a business case. This section provides the detailing of what monetary benefits are expected from the project over its lifecycle, and what the associated costs are for committing to implement the project. Often, this section serves as a tool to gain acceptance for a project in dollars and cents terms. In the best of times it contains rigorous financial analysis jointly developed with IT and financial representation, which could be the VP of a business unit requesting an IT project or perhaps the CFO, and in the worst of times, contains fudged numbers from vendors or idle speculation.
The best pitches are largely developed with IT serving as advisor, rather than being the primary party responsible for producing the pitch. For example, if the company is considering a new CRM system, rather than IT attempting to tease numbers out of sales and marketing and calculating returns, IT should ask pointed questions of these business units to get a better understanding of the project's expected benefit to the company, then ask the business to determine the financial benefit of each item. With benefits in hand, IT and the requesting organization can determine the costs of the project, with IT covering the technical piece and the business covering sensitive areas like change management and organizational design. Some sample questions to start these discussions include:
How will your organization be different as a result of this project?
How will this project impact products/competitors/markets/customers?
What personnel will be freed from administrative or low-level tasks?
When will each benefit be realized?
While these are only a few examples, the key to these types of discussions is getting the conversation to move beyond the technology, and focus on how the organization will be in a better state due to the project. Once you have an understanding of that improved state, you can put savings behind each element. Just like a well-done advertisement, the pitch briefly reviews the current state of affairs, provides a vision of the future with its associated financial and organizational benefits, then lays out the cost.
In the next installment, we will review the remaining two aspects of the business case, and discuss how the business case impacts project decision making and serves as a "living" document.
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 firstname.lastname@example.org.
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. Patrick has spent over a decade providing strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at email@example.com and you can follow his blog at www.itbswatch.com. All opinions are Patrick's alone, and may not represent those of his employer.