Emerging Tech

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@prevoyancegroup.com

About

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 ...

7 comments
pmaina2000
pmaina2000

Let's first understand what a business case is and what its not. ==================== A business case IS: ==================== 1. A persuasion document for investment appraisal 2. A baseline document for performance measurement 3. A snapshot of the current business environment and projected value of desired changes at that time. ======================= A business case is NOT: ======================== 1. A Business Plan - which is a living document that defines the overall business and which keeps changing in response to external forces. 2. A Business Strategy - which is also a living document concerned with surviving and growing over the long term. 3. A project plan which is another living document with very limited scope - delivering specific results through a temporary endeavor. ======= EXAMPLE ======= Say you have strategy x in your business plan. To achieve strategy X, you identify 3 projects A, B and C. However you have constrained resources such that you can only execute 1 project in your current financial year. How do you choose between project A, B and C? Right! You conduct an investment appraisal. What tool do you use for that? Exactly! The business case! So essentially any organization will have: - one business plan (overall) - a small number of strategies within the business plan - a number of programs with dozens of projects, business cases and project plans. From the points above, you can already start to see that it is unrealistic to expect all business cases to be reviewed whenever there is a change in the business environment (Bottom Up approach). You would need an entire department dedicated to that task! Better perhaps to take a Top Down approach and review the Business Plan first - then only look at projects falling within affected programs, and then only update the business case when a change in direction is necessary! At this point, its should be somewhat aparent that the Business Case is really a STATIC SNAPSHOT/BASELINE DOCUMENT. Not convinced? Read on... ========================= From another perspective: ========================= Business Need = Desired Situation - Current Situation At the core of the business need is a FUTURE PROJECTION incorporating assumptions derived from an analysis of the current situation. Therefore: Desired situation = Current situation + (Projections x Assumptions) Keep in mind, the current situation is FROZEN at that point in time. Current situation tomorrow is not going to be the same as Current situation today. Also remember that assumptions are based on an extrapolation of the current situation - hence a strong dependency between the two. This means therefore that the business need is based on our understanding of the current situation + assumptions based on the current situation. i.e. its FROZEN at that particular point in time. Here's an example to illustrate this: New laws can be passed which completely invalidate yesterday's assumptions (which were based on yesterday's current situation). The result is that the business need and certain performance parameters (including failure criteria) must, at that point, be considered as INVALIDATED. This also illustrates the need for change management: Business need + New circumstances = Revised Business Need ==> Change Request The change request, if received midway during project execution, will have certain implications on project constraints. Therefore all change requests should result in a Supplementary Business Case specific to the change. Such a document would explain the impact of the change given the new situation. Change request + (old Business Case + Supplementary BC) = BC v2.0 In this case Business Case v2.0 becomes the NEW STATIC SNAPSHOT of the current + desired situation. This explains why it is unwise and probably a waste of time / resources to attempt to define Failure Criteria in the business case. A project might be scrapped for wrong reasons - based on outdated assumptions! On the other hand - defining a SUCCESS CRITERIA for BC and the Supplementary BC is wise and valuable since we are defining baselines! ============================== SO WHERE DOES THE PROJECT FIT IN? ============================== To realize the Business Need, we set up a temporary endeavor (project) with specific deliverables which are expected to give certain business benefits. Therefore: SUM(cumulative Benefits of all Project Deliverables) = Business Need This proves that it is right for a project manager to focus on DELIVERABLES - provided the initial analysis of how business benefits would be attained was correct and a reasonable requirements change management mechanism is in place. The project plan incorporates the STATIC business case as a performance measurement criteria. ========================================= PITFALLS OF NOT SEEING THE BIGGER PICTURE ========================================= 1. Dynamic business case ("per se'") results in shifting goalposts increasing likelihood of failure 2. Unrealistic expectations from senior management Try to see the business case as a Budget. You set your budget, freeze it and then measure against actual performance. When you need to make changes, you create a supplementary budget (like an addendum) which updates overall budget - and which is then frozen. It's a bit paradoxical but if you look at the biggure picture, you'll realize that the Business case is comprised of nothing but SNAPSHOTS and such a static format is sufficient for its intended purpose. Cheers! copyright 2008. all rights reserved. :-)

santeewelding
santeewelding

I am impressed. Your previous, and now this, stand also as something else. With but changes to nomenclature, you present comprehensible, dynamic, and extensible organization of self. That the self of your subject is business, and that what you say stands so well, attests to your grasp.

don.saracco
don.saracco

I was struck by the assertion that a business case is intended, in large part, to "sell" projects. The truth is that IT professionals are staff members whose responsibility it is to serve the legitimate needs of the business. A business case is not just an argument for doing something that must be crafted to ensure agreement from empowered stakeholders. It is a thorough analysis of the conditions and circumstances that exist which provide opportunity to further the organization's goals or which inform management stakeholders of the risks involved in a particular employment of technological capital (and therefore dollar capital). I think that the idea that a business case is always a sales pitch demeans management professionals and robs senior managers of the intelligence and expertise of their staff people. Please, this is supposed to be a dispassionate assessment, not a con game.

sachin99
sachin99

So your thinking of starting a home business and working for yourself. Your tired of that crabby old boss, always on your back, and after all, you'd rather work for a sweetheart like yourself. Business Ideas

tonyc
tonyc

Your implication that sales pitches are ipso facto a con game may be similarly demeaning. The reality is often that IT professionals can only serve the business by painting a clear picture of the business benefits of a proposed new system to non-IT managers who otherwise simply wouldn't 'get it'. Yes, they must honestly present the risks and costs along with the benefits, but more often than not, there must be a 'pitch' that will break managers out of their traditional mindset, in which they may have a vested interest. I think Patrick's article makes this point very clearly.

CharlieSpencer
CharlieSpencer

Business ideas, jewelry, cell phones; you're a multipurpose spammer whose account should have been deleted a week ago.

don.saracco
don.saracco

I fear that I must disagree. The assumption that is still evident in your argument that "It is the way things work" has no basis in anything except consistent experience. I should think that the rather dismal results (a majority of projects fail) of this process of selling would reveal its weakness. Business people don't need to be educated about what their business is, but IT professionals certainly do. Any education of business managers begins with a demonstration that the business is clearly understood from the business perspective. The IT reputation of being enthralled by new technology that promises more than it delivers will not change until this is understood. Technology in nearly all business environments provides means and not ends. The ends must drive what organizations adopt, not technical expertise.

Editor's Picks