The first step was " Scope". In the last post I said that this is where we can avoid a lot of back-end confusion if we clearly define the business case contents and project plan. This is so true and I'll share with you some of my personal experiences below. I guess an easy way to describe "scope" would be to say "who expects what?" Would you agree? I also said that "a business case is far too important analytically and too highly visible politically to contain avoidable mistakes." Again, very true.
During an engagement with a major client, I was invited to a meeting where the VP of IT would be delivering a business case for the next project I as slated to be working on. I spoke briefly with him before the meeting and he was confident this would be a slam dunk. He told me that this project had the best ROI of any project currently under consideration, the risks were minimal, and the investment level was acceptable. Sounds like he had everything in line didn't he? Guess what? He didn't get his funding. He lost out to a non-IT project to remodel a manufacturing plant. That was something he didn't even consider.
I remember one of my first forays into putting business cases together. I had spent a lot of time on this plan and was sure that the majority of the investment decision would be based on hard-money savings and a smaller portion on non-quantified intangible factors. Guess what? I was wrong. The total opposite was true, so back to the drawing board for me.
In the two experiences I just gave you above, a lot of disappointment came from poor assumptions about the scope of the business case. In hindsight these disappointments could have been avoided if we both would have spent a small amount of time to determine the exact nature of the investment decision and the process in which the decision would be made.
In the scope phase there are three tasks that will ensure that those mistakes that were made above don't happen to you.
#1: Define the business case drivers and boundaries
one thing I can tell you for certain is that investment decisions just don't happen spontaneously. Somewhere in the deepest, darkest recesses of your company are major business factors that drive the need to make a decision now, rather than 6 months ago or 6 months from now. Your job, and that of your team, is to flush out and document these key drivers. The correct drivers establish the direction of the business case and set the stage for the theme of your business case analysis. A good business case will clearly link the functionality of the solution being considered to the high-level management concerns. Let me give you an example: In my former employer there was a statement made by the upper levels of management that they needed to find an economical method to provide secure remote access to applications and web content for "day one" employees that were part of outsourcing deals and acquisitions. So that was my primary business driver that addressed issues/challenges that were a direct concern of senior management. The primary business driver will always address those issues of direct concern. If the proposed drivers do not meet this test, then you need to dig more until those drivers are found. One very key piece of advice I'll share with you here. Take extra time to be sure that the business drivers are correct. My advice is to talk to one or more of the most influential decision makers and ask them what are the strategic business conditions that are causing the need to make this investment decision right now.
Let me touch on boundaries for a minute, as this is the one thing that would have saved that VP of IT in my example above. Boundaries, as the name implies, identifies exactly what is and what is not included in the business case relative to:
- investment options to be assessed
- span of the systems to be justified
- organizational units involved in the value assessment
- level of detail of the business case analysis and report
- people and resources to be consulted
#2: Identify your Deliverables, Team, and Schedule
First thing, you can't do this on your own; form a solid team. These are the people who will be responsible for the development and delivery of the business case so choose wisely. Keep in mind that in this task, the deliverables (e.g. the final report) and project timelines should be specified in detail.
#3: Solidify your Executive Sponsorship
Critical, critical, critical. If you don't know it already, the rule is any document that will influence anyone in upper management in making IT investment decisions requires an executive sponsor. Here is what an effective executive sponsor should be able to do for you:
- has access to and the confidence of the decision makers who will use the business case
- knows how the organization works and the realities related to the project being justified
- understands clearly the IT investment decision process, and I do mean both the formal and the informal components
- has enthusiasm for the potential value of the project under consideration
- can encourage SMEs (subject-matter experts) to cooperate with you and your team
- will actively support, guide, and encourage you and your team
I learned early on, and I can't stress enough to you all now, how important it is to have that good executive sponsor. It's hard enough work putting a quality business case together, but having someone as a sounding board, coach, etc is priceless.
The next step is "criteria". If there is anything that you want to ask please feel free to email me.