As stated in the first post in this series, a business case is about business. Whether for IT or non-IT projects, the business case must be written in business terms.

We create business cases for two reasons: we believe there is a problem to be solved, and we believe that the value in solving the problem exceeds the costs we'll have to incur to solve that problem. The starting point, therefore, is a statement that a problem exists. We call this statement the hypothesis.

According to Webster's Dictionary, an hypothesis is "an unproved theory." The hypothesis, or theory, of your business case is an opening assumption that a problem (or improvement opportunity) exists and that there is value to your organization in addressing it. A thoroughly researched and well-written business case will prove the theory. It's really that simple. (We'll discuss research methods and comparative analysis in upcoming posts.)

The hypothesis is the first of four primary aspects of a sound business case. Those four aspects are:

Hypothesis
Evidence
Analysis
Recommendation
So, as you start the planning for your intended project, you might hypothesize that your company's current procurement process is inefficient and hinders your ability to negotiate effectively with vendors. Your hypothesis could further posit that implementing new procurement software would favorably address this issue. That's it. That could be your opening hypothesis. The business case could be launched from something that basic.