How to Write a Business Case

Most of us have had to write a Return on Investment or a Business Case for projects we have worked on. The purpose of these documents is to define the overall benefits and costs of a project at a very high level usually aimed at Project Sponsors. The document allows you to provide much more diligence on the costs and benefits, while still not requiring you to actually go through the effort of specifying the work at this time. All Software Projects go through iterations of detail definition as more is known about the project. They key is to set the expectation of the degree of schedule confidence at each level of specification. At the Business Case Level the confidence in the schedule is very low.

When the Business Case is accepted by the Project Sponsor it is time to write a Project Charter and Project Scope Document which can be used to finalize the Project Plan and Work Breakdown Structure.  It is ideal to have the project team identified once the Business Case is accepted. If not, it is vital to have the majority of them identified by the time you finalize the Project Plan, Work Breakdown Structure and Schedule.A feasibility study is used to provide much more diligence and understanding about whether the project is feasible or not. In fact, the feasibility study might be a project in itself. The study might just be a more detailed analysis of the viability of a project and may not require a small project structure.

The result of the feasibility study is a document that is also called a Feasibility Study. There are a number of areas of feasibility that should be analyzed.

• Technical. Is the project technically feasible? If it is you should state any technical risks associates with the project.
• Financial. Is the project financially feasible? This would be especially important if the cost of the project was material to your company. It is possible that a project could have a cost that is significant enough to put the entire company at risk. You may have the ability to budget for the project now, but you might also analyze what the impact would be of a significant cost overrun.
• Operational. You should make sure that you have the ability to run the products that are built by the project. It is possible that the project itself is feasible, but you may have significant risk in being able to operate the product after the project is over.
• Geographic. Is the project feasible given the physical location of the project team?
• Time. Is the project feasible given the amount of time it will require from the participants? This is a big worry on larger projects. You may have the budget to execute the project but you may realize you cannot free up the project team for enough time to execute the project. .
• Resource. Do you have the staff, equipment, supplies and other resources necessary to complete the project?
• Cost/benefit analysis (high level). You still have to complete the cost/benefit analysis as a part of the feasibility study.
• Recommendations. The conclusions and recommendations should be noted. One technique that can be used is to look at a number of alternatives for how the project should progress (if at all). For each alternative discuss the benefits, costs and risks. This will show the reader that the right level of diligence was performed and that a number of alternatives were considered. Your final recommendation should address assumptions, risks, ROI (return on investment), estimated cost (with a confidence factor that is fairly low), priority and next steps to be performed.

All of this information provides further detail on the nature of your study and provides your management stakeholders with the complete set of information they need to make the best decision on how to proceed.