Business Case | By Kenneth Darter | Read time minutes
In order to get stakeholders or management to approve your project, you will need to build a business case to demonstrate why the project is needed and what the benefits of the project will be when it is finished. The reasons and benefits of your project may seem perfectly obvious to you and others who are intimately involved with it, but to stakeholders and other decision makers it may not be so obvious.
Oftentimes, they are dealing with a myriad of different business units and objectives and tasks that need to be done. A well prepared business case can help your project standout in the crowded field of everything that is happening in the company and might just be the key to getting approval and finances for your project. Here are the basic steps for creating the business case.
Step 1: The "As Is"
The first step is to document the "as is". If you do not understand where you have been (or where you are currently), how can you demonstrate where the project is going to take you or the company? This applies to software development just as much as it does to business organisation or any other industry in which projects are executed. Documenting the "as is" should involve a careful evaluation of the current business model and the tasks that are completed by the people who are directly involved in the processes. You might need to interview certain subject matter experts or follow a day in the life of the workers who are on the front lines of the business in order to document the "as is". Most importantly, all assumptions must be challenged and researched so that there are no surprises down the road when the project begins to change the "as is" to something new and better.
Step 2: The "To Be"
Once you know where you are or where you have been, then it is time to document the "to be". This is your time to shine by showing off what the project will do for the business. It might be a better software system or a new business process flow. Alternatively, it might be restructuring the office organisation to provide better support for the sales people. Whatever your project is going to do for the business should be documented just as carefully as the "as is" was documented. Again, challenge all the assumptions, work to evaluate carefully everything the project is going to accomplish. The final documentation of the "to be" becomes the initial scope statement for the project.
Step 3: Going From the "As Is" to the "To Be"
Now that you have a picture of the "as is" and a picture of the "to be", it is time to document the steps that will take you from the starting point to the end of the project. This does not have to be a detailed project schedule or task list, but it should give a high level overview of how the project team is going to take the business from one point to the next. This overview should include the resources and time that will be involved in the project. This road map will show the decision makers and the stakeholders how they can help make the idea into a reality and get the project off the ground.
Step 4: The Return on Investment
The last part of the business case is to show the return on investment. This is a vital piece for the stakeholders involved and the organisation’s management. Answer the question of how this project is going to help the business. If the organisation is willing to provide the time and resources to execute the project, what are they going to get out of it? This may be something like improved productivity for office staff or quicker processing of documents in the office. If the return on investment can be quantified into dollars in the form of savings or returns, then that will be a great help in building your business case; it is difficult to argue with hard numbers. Of course, all assumptions about the return on investment will be challenged closely, so be sure to do your homework very carefully when creating your business case.