Following is an approach to establishing the business case for project approval.  This assumes a project idea has been initiated by the business.  IT staff are engaged early in “ideation”, such as a business analyst or relationship manager.  The next step is to measure costs and benefits and establishing the business case.  Typically, a project manager is assigned to complete the business case with support from Finance, IT and business staff.  


Step 1: Meet with key stakeholders to develop a set of project assumptions as a basis for the TCO

  • Include business management, IT project managers, relationship managers, business analysts and Finance
  • High level business and technical requirements for a proposed solution should be discussed and noted and factors that drive costs should be discussed (e.g., hardware requirements)
  • The discussion should include all components of the TCO, one-time and on-going costs
  • Not a lot of detail is required at this point but there should be a set of general assumptions.  For example, a new application is expected to have 1,000 users in 20 sites


Step 2: Enlist key stakeholders to discuss and define benefits in terms of business outcomes expected from the project/initiative

  • This could be done at the same meeting noted above if it is a multi-day session, or separately
  • The same people noted above should be included
  • Discuss capabilities of the solution and what it will do to improve business results
  • Benefits generally fall into four areas: increased revenue, decrease in costs, asset optimization, productivity improvement
  • Identify the benefits with the greatest impact that have linkage to strategic goals
  • A metric should be defined for each benefit to track benefit realization
  • As noted in the cost estimate, the benefits do not need to be captured at a detailed level.  Identifying a category of benefit (such as a sales increase) and a source to measure would suffice at this point
  • The key to the discussion is to focus on business impact and outcomes, not what the technology can do for you 


Step 3: Gather data for cost estimates

  • Generally, finding the source of cost data is not difficult
  • Start with the information that was recorded at the initial meeting
  • Remember to collect both one-time project and ongoing run costs
  • Work with business management to identify business costs such as training and staffing.  Work with IT resources (such as engineering and operations) to identify technology costs such as consulting, hardware and software
  • Technology costs typically are based on an initial technology design package completed by engineering.  If before the design phase, then engineering should base the technical requirements on historical data
  • Direct and indirect costs should be captured.  An example of a direct cost is consulting support for development.  An example of an indirect cost is the cost of internal labor working partially on the project
  • Estimates can be based on historical data.  For example, if time tracking data indicates that a large-scale project requires 1 project manager, 4 engineers and 2 operations staff for 6 months, then that can be the basis of a resource estimate of a comparably sized project
  • If historical data is not available, use data from other sources like research firms or industry groups that have trend data
  • Cost estimates should have a clear set of assumptions so any challenge to the estimate has supporting information.  An example would be an estimate for hardware that is based on the number of servers and network devices assumed to be required based on an architectural design and business requirements.  The estimate can be challenged, however, the discussion can focus on the business requirements and architectural design and not the cost
  • Variability of the cost estimate should be defined based on the project phase.  This qualifies estimates for business management who likely are looking for preciseness, which is difficult in the early stages of a project.  Following are criteria to be considered
  1. After project initiation: +/- 25%
  2. After project design: +/- 10%
  3. Before implementation begins: +/- 5%


Step 4: Gather data for benefit estimates

  • The biggest challenge in developing a business case is determining where the benefit information comes from
  • Start with the information that was recorded at the initial meeting
  • Work with business management to identify benefits in more detail in terms of business outcomes.  This is a crucial step to assure benefits are business-driven, not technology-driven
  • Hard benefits are not difficult to develop, similar to putting together the TCO.  An example is estimating cost savings from headcount reductions.  Staffing reports and compensation data should be readily available for these computations
  • Soft benefits are where the challenges arise.  How do you quantify things like increase in customer satisfaction, improving brand awareness, better employee morale, and establishing a more secure network?   Often these benefits are linked to non-financial objectives of the company
  • Soft benefits should be identified and linked to a quantifiable measure if possible.  An example is the benefit of a new security system that will lower the risk of a security penetration.  No direct linkage to revenue growth or cost reductions can be made.  Although the measure could be the cost associated with a potential penetration.  This could include the impact to the brand should a penetration occur.  An example is the Target security penetration.  There was a measurable loss as a result of a substantial decrease in sales from damage to the brand.  A new security tool is a preventive solution to avoid a negative impact to the business financials
  • If a soft benefit cannot be quantified but is relevant to a potential significant business outcome, then it should be noted in the business case
  • Benefits should have a business owner for accountability.  So if there is to be a reduction in business operations resources, then the business lead of that organization should be accountable for those resource reductions and resultant cost savings.  If there is no business accountability identified, then it should escalate to senior IT and business management and the project should be put on hold until the business accountability is assigned
  • Benefit estimates should be qualified like the cost estimates.  Variability of the benefit estimates should be defined by phase, same as noted under costs
  • Business impacts and outcomes are benefits only if they contribute to business objectives.  The following table includes examples of objectives that may come within the business case scope, taken from the book, The Business Case Guide. (4) 
Business ObjectiveBusiness Outcome
Sales and Marketing
  • Increase sales revenue
  • Improve market share
Financial/Business Performance
  • Increase cash flow, margins, or profits
  • Improve earnings per share
Operational/Functional
  • Shorten new product development time
  • Increase order-processing capacity
Product/Service
  • Improve customer satisfaction
  • Update the product line
Image Enhancement
  • Recognized as a provider of leading-edge technology
  • Known as a leader in environmental protection
Internal
  • Improve employee morale
  • Provide a challenging career path for employees
Other Business Objectives
  • Establish strategic alliances
  • Become a "total solution" provider



Step 5: Once the data collection is complete, calculate TCO and ROI of the project 

  • The financial analysis should not go beyond three years, as the accuracy of estimates are lower the further out you go in time.  Generally, three years is enough time to capture benefits
  • There are many methods to calculate ROI.  I will use two that have worked for me in the past: Net Present Value (NPV) and payback.  NPV shows the net aggregated cash flow reflecting a discount for the time value of money.  Payback is a measure of the time it takes to recover the initial investment.  If NPV is too ambiguous to management, then payback will offer a simpler view
  • As noted previously, the TCO is factored into the ROI calculation
  • TCO costs can be based on full cost, or based on incremental costs.  An example of a full cost would be the specific cost of all resources dedicated to the project.  An example of an incremental cost is the cost of only the resources added. Be careful, as I have seen some business cases mistakenly include a mix of both.  For purposes of this analysis, I use a full cost basis
  • Soft benefits can either be estimated as noted in Step 4, or be noted separately from the financial analysis as a qualitative benefit in a benefits section of the business case
  • Showing different scenarios with varying assumptions, TCOs and ROIs, is a good addition to the business case so management can see “best case” and “worst case”.  For projects that show limited financial benefit but have key soft benefits like risk of non-compliance, showing “business as usual” with the cost of such risks can drive home the point of the risk of not doing the project.  “Too often, business case developers overlook the single biggest competitor of all projects- doing nothing!” (5)
  • Go to this link to see an example financial analysis worksheet


Step 6: Develop the business case document


Executive Summary

  • Do this last as it should be a brief summary of the content of the business case document
  • The first paragraph should be a brief description of the purpose of the business case, the opportunity/problem being solved and any background information
  • The second paragraph should be a financial summary including the TCO and ROI, and a statement of the key benefits
  • The third paragraph should highlight the key assumptions, risks and critical success factors
  • The last paragraph should be a summary of the conclusions and recommendations


Introduction

  • Background
  1. A history that leads to the opportunity or problem to be solved
  • Subject of the Business Case
  1. Describe what the business case is about
  2. Description of the opportunity or specific challenges and impacts
  3. Discuss how the initiative will address the stated issues/needs
  • Purpose of the Business Case
  1. Describe who the audience is for the case and what the key messages will be
  2. State how the final report will be reviewed and approved (e.g., to be reviewed by the Technology Steering Committee on August 1, 2014)


Approach, Scope and Assumptions

  • Approach and Scope
  1. Project boundaries– things we will and will not do in the initial release
  2. Include the scope of the business case in terms of time, location, departments or divisions, or technologies in use
  3. Describe how the scope will be delivered
  4. Build vs. Buy
  5. Multi-phase rollout
  6. Leverage existing platforms
  7. Describe any integration with segment and enterprise platforms
  8. Include logical architecture or other conceptual diagrams to illustrate the target state and key components at play
  •    Assumptions
  1. Description of the assumptions behind the business case financials, benefits, technology use, etc.  This should be comprehensive enough to support challenges to the data, conclusions and recommendations
  2. Market assumptions (e.g., market penetration will be 30%)
  3. Economic assumptions (e.g., inflation will be 3%)
  4. Business volume assumptions (e.g., 10,000 subscribers)
  5. Pricing assumptions (e.g., product pricing is $10/month/user)
  6. Technology assumptions (e.g., five servers per 5,000 subscribers)


Project Structure & Resources

  • Project leadership
  • Project structure and key governance takeaway
  • Main work streams and work stream leads
  • Resource needs


Key Milestones and Dependencies

  • Preliminary dates for key phases, stage gates, launch date
  • Any known dependencies that will extend the timeline


Business Impact

  • Business Benefits
  1. List and describe drivers of the quantitative benefits included in the ROI, such as revenue changes, cost decreases, etc.  Details are not necessary on the financials since they will be included in the financial section
  2. List and describe the “soft” qualitative benefits like customer/user experience improvements, brand enhancements, improvement to employee morale, etc.
  • Strategic Fit & Cross-Segment Linkages
  1. Describe how this initiative aligns to the business unit and enterprise strategy
  2. Describe how this initiative will build and enhance key capabilities
  3. Describe the key linkages to other business unit and technology programs
  • Financial Analysis
  1. Cost Assumptions                                                                                                                                                                                                  -- Include assumptions for both one-time investments like consulting rates and hours, hardware configuration and pricing, internal labor average salary, etc., and ongoing costs like hardware and software maintenance contract pricing, maintenance labor support average salary and resources, etc.;                                                                                                                                                                                                -- Include assumptions for how costs were accounted for (capital vs. operating expense), amortization rates, tax rates, discount rates, etc.   
  2. Benefit Assumptions                                                                                                                                                                                              -- Include assumptions on the quantifiable benefits such as average salary and number of staff for savings from staff reductions, product pricing and number of sales for a revenue projection, etc.
  3. Benefits Accountability                                                                                                                                                                                           -- List of benefits, metrics and accountable parties                                                                                                                                                -- This is important to assure success for the benefit realization assessment to be completed later
  4. Financial Summary Spreadsheet                                                                                                                                                                           -- Copied from the Financial Detail Worksheet                                                                                                                                                      -- Show multiple scenarios if appropriate


Risks

  • Business Risks
  1. Should align with the project assumptions to indicate the probability of the assumptions not materializing.  Examples would include probability of an economic downswing, resource availability, timing of a regulatory requirement, etc.
  2. Risk can be measured as high, medium, low
  3. Include risk mitigations (e.g., to mitigate the risk of staff not being available for the project is to hire consultants)
  • Technical Risks
  1. Should align with the project assumptions to indicate the probability of the assumptions not materializing.  Examples would include probability of a timely delivery of hardware components, timely completion of application testing, quality of testing, etc.
  2. Risk can be measured as high, medium, low
  3. Include risk mitigations (e.g., to mitigate the risk of delays in hardware installation is to engage a backup vendor)


Conclusion and Recommendations

  • Conclusion
  1. Synopsis of options and scenarios.  An example: Option A has a higher NPV than Option B and has fewer risks.
  • Recommendation
  1. Recommend the course of action.  For example, Option A is recommended due to the factors noted in the synopsis
  2. Include Critical Success Factors- Factors that can be managed or controlled to some extent to qualify project success.  Examples are staff training, partnership agreements in place, senior management support
  3. Next Steps- who needs to do what and when


See an example Word document template at this link. This would be the full version of the business case and would contain all details that should be documented.  See an example PowerPoint document at this link.  This is an abbreviated version and presents the highlights that are important for management to know to be presented to the Technology Steering Committee and other senior executives (10 pages or less)


Step 7: Review the draft of the business case with project members and stakeholders

  • Distribute to everyone who had input into the business case, including business owner/sponsor, business operations managers, business analysts, application managers, relationship managers, engineers, operations
  • It must be sent to the business managers who will be accountable for benefits.  There could be a negotiation to settle on benefits.  The business case should not go forward until the business signs off on the benefits
  • Distribute to the business and IT PMOs
  • Make changes as appropriate.  Be sure there is agreement on the content.  If not agreement with all parties, then acceptance.  The stakeholders required to be in agreement are the business owner/sponsor and accountable parties
  • Finalize the draft and create the presentation to the Technology Steering Committee


Step 8: Schedule a project review meeting with the Technology Steering Committee

  • Work with the IT PMO responsible for committee meeting agendas and the project portfolio
  • Distribute the business case document and presentation in advance or as requested by the Technology Steering Committee organizer.  Do not submit the business case late and miss the deadline for materials sent out in advance of the meeting.  Ideally, you would like everyone in attendance to have already reviewed the material.  This will make for a smoother conversation during the review session
  • Invite key members of the team and stakeholders, such as the business owner/sponsor, project manager (yourself if completing the business case), and an IT senior manager responsible for the project.  Often these sessions are brief and require only a few representatives due to meeting logistics
  • Take notes during the meeting including whether final approval is given or if there are follows-ups required that are contingent on approval.  Validate your notes with the PMO representative attending the meeting


Step 9: Communicate outcomes of the meeting with key stakeholders and project team members

  • Surprisingly, this is often a delayed step.  But the team needs to be ready to execute the plan upon approval

Business Case Development

Results that make a difference