This last problem is especially important if you're trying to sell a technology project to a battered senior executive team that's in no mood to spend a ton of cash on a new project.
What this process is all about is the identification of real and political reasons to buy something or engage a consultant. This can be a very tricky process, since (because of the perennial competition for funds) there will always be project enemies, those just waiting to say "I told you so" when the project goes south. IT buyers -- especially in large enterprises -- have to make sure they've covered their flanks. The "business case" is therefore as much a "real" document as it is a political one.
Business cases are typically organized around questions designed to determine if the investment makes sense. Let's look at the key questions that you should answer before buying software, communications, or consulting services. Let me say up front that the answers to these questions should be in a 10-page document (with appendixes if you must): If you generate a long treatise on every investment you'll never get the time or respect of busy senior executives.
What business processes are impacted by the investment/application(s)?
The correct answer here identifies a process that's broken, a process for which you have empirical benchmarking data. For example, if you were selling LAN administration productivity tools, you'd have to know what you're spending now and that the costs were rising dramatically. You'd then need to know exactly what your performance target should be (e.g., reduce the costs by 25%).
How pervasive is the product or service among your traditional and unconventional competitors?
Many decisions about IT adoption are driven by what the competition is doing: It's always easier to sell something to a customer whose competitors have already signed on to the product or service (of course, this assumes that your competitors are smart).
What competitive advantages does/will the product or service yield?
In other words, why is this product or service so great and how will it help you profitably grow the business.
How does the new product or service interface with existing business models & processes?
This is a big question, since the "wrong" answer (like: "it doesn't") will often kill a project. If deployment means ripping out or enhancing infrastructure, then you've just significantly increased the price (and given your internal enemies ammunition).
Key Technology Questions
How mature is the product or service?
The point of these questions is to determine if the technology or service actually work -- and work well. You will need quantitative data here: It won't help to tell everyone about how great your brother-in-law's company is. Additional questions here concern scalability, security, modifiability, usability, etc.
What share of the market does the product or service own?
If the answer to the question is, "Well, one percent," then a major explanation will be necessary.
How does the new product or service integrate with the existing or planned communications & computing infrastructure?
This question is extremely important because it identifies any problems downstream that might occur because of decisions already made (that cannot be undone).
Key Cost/Benefit Questions
What are the acquisition, implementation & support costs & benefits?
Here you need to look at obvious costs, like software licenses, and less obvious ones, like training, indirect user and help desk support, as well as the expected operational and strategic benefits like expense reduction, increased market share, improved customer service, increased cross- and up-selling, improved customer retention, etc.
What are the support implications? How complex, how costly, how extensive, how timely?
Support is extremely important. You need to know -- empirically -- what the support requirements and costs will be defined in terms of dollars, people and time.
What are the migration issues? How complex, how costly, how extensive, how timely?
This may or not be relevant, but if another tool was in place you have to answer questions about how to get from one to the other.
Key Risk Questions
What are the technical, personnel, organizational, schedule & other risks to be considered? What's the risk mitigation plan?
The risk factors that everyone will worry about include scope creep, cost and time overruns, incompetent or irritable people, implementation problems, support inadequacies, training problems, and the like.
If risks are assessed as medium or high then a mitigation plan must be developed, a plan that either moves the risk down to the "low" category or eliminates it altogether. If the risks remain high, the project sale is dead.
The recommendation is go/no go/we need more information. The whole purpose of integrating a business case into the sales pilot is to avoid the "we-need-more-information-syndrome."
The business case should also identify at least two "accountable" people, people whose reputations rests to some extent on the success of the project. One should be from the technology side of the organization and one from the business side (if you can find the right hybrid). If there are no project champions, it's time to go home.
Steve Andriole is the Thomas G. Labrecque Professor of Business at Villanova University where he conducts applied research in business/technology alignment. He can be reached at email@example.com.