Rarely does a project become a project without some financial decision first being made.  And that financial decision is based on the business need, the return on investment (ROI), the estimated cost of the project, the available skill set to run the project, etc. etc. etc.  The list can go on and on.  But one essential piece of gaining the approval of any decent sized project is the business case.  Making a case for the project as a viable means to solve a business need or fix a problem that needs fixing or add functionality that needs added.  Someone, somewhere…usually starting with the project sponsor…must make a business case for the project.  It can be a formally documented business case, it may be somewhat informally documented if it’s a smaller project or a more informal organization or it may even be a verbal discussion – but the powers that be need to hear about the project concept and be convinced that it deserves to  have money thrown at it.

As projects are costly exercises, it is imperative that senior executives within the organization approve spending money on the project prior to undertaking the initiative. The way in which they are made aware of the project and commit themselves to this project is through the business case. Without a formal business case, the project is likely to be cancelled within a short period of time and will have resulted in a lot of wasted effort. The business case document therefore defines and assesses the proposed project. The business analyst develops the business case with help from identified groups, departments, and subject matter experts, and continues to update the business case in parallel while development takes place. The business analyst and project manager, together with executive involvement, should review and refine the business case into a workable document.

Potential Components of the Business Case

Potential Components of the Business Case


  • Risk management
  • Project requirements

    • Project definition
    • Functional diagrams
    • System functions
    • Operational concept
    • Customer responsibilities
    • Project or end solution characteristics
    • Functional interface definitions
  • Projected cash flow and/or ROI
  • Legal constraints
  • Specifications and standards
  • Methodologies required
  • Preparation for delivery
  • Maintenance and support