Business Case Document

7/28/2019 Business Case Document

1/27

DEP Information Technology Business CaseTemplate and Instructions

FINALVersion 1.0


2/27

REVISION HISTORY

Date Description Version

9/1/07 Created DRAFT 1.0

1/3/08Circulated to IT Coordinators for comments incorporated

comments received and conducted editorial revisionsDRAFT 2.0

1/22/08 Approved by CIO, R. John Willmott FINAL 1.0


3/27

Table of Contents

TABLE OF CONTENTS..............................................................................................................................................3

INTRODUCTION.........................................................................................................................................................4

1.0 COVER PAGE........................................................................................................................................................6

2.0 EXECUTIVE SUMMARY.....................................................................................................................................6

3.0 BUSINESS PROBLEM/NEED(S).........................................................................................................................8

4.0 BUSINESS OBJECTIVE(S)..................................................................................................................................9

5.0 CURRENT STATE...............................................................................................................................................10

6.0 ALTERNATIVES.................................................................................................................................................12

7.0 PROPOSED SOLUTION.....................................................................................................................................13

8.0 PROJECT SCHEDULE & RESOURCE REQUIREMENTS..........................................................................17

9.0 COST-BENEFIT ANALYSIS..............................................................................................................................20

10.0 RISK ASSESSMENT.........................................................................................................................................26

11.0 REVIEW AND APPROVAL ............................................................................................................................27


4/27

Introduction

The Project Management Office (PMO) within the Office of Technology and Information

Services (OTIS) has developed this business case template to assist DEP programs in analyzingand documenting the business justification for an information technology (IT) project. The

purpose of a business case is to systematically examine alternative solutions to a stated business

problem, need or opportunity. A rigorous business case analysis provides the necessary elementsto support managers in selecting and prioritizing those IT projects that should be approved and

funded.

The business case is a single document that contains the business, financial and technicalinformation required to provide a thorough justification for a project. The project sponsor and

the respective business area, not IT, own the business case. The business case provides a

comprehensive view of the proposed project and provides financial justification for that project.It makes the case for change and tells the story of the project in non-technical, easy-to-

understand language. The business case should be a compelling justification for the project. As

such, it must clearly detail the business need and objectives, expected benefits versus the costs,an alternatives analysis of other potential solutions and an overall risk analysis.

A business case always focuses on the non-technical reason for conducting a project. Whilethere may be a technical solution that is proposed to solve the business need or problem, the

business case must justify that there is a clear business need or problem being addressed and that

any technical solution proposed will result in a defined business improvement.

The business case contains the following elements:

Cover Page

Executive Summary

Business Problem/Need

Business Objective(s)

Current State

Alternatives

Proposed Solution

Scope

Project Phases & Milestones

Work Breakdown Structure (WBS)

Business & Operational Impacts

Project Schedule and Resource Requirements

Cost-Benefit Analysis

Risk Assessment

Review and Approval Process


5/27

Using the business case document, the reader should be able to understand what the project is

about, the role of the project in the departments business and strategic plans and the business

justification for the project. The reader should also understand how the project improves theoverall efficiency and effectiveness of the Department and/or state government as a whole. Once

completed, the business case analysis should contain all of the information to assist management

in evaluating and, if appropriate, approving the proposed project.

The remainder of this document is to be used as a template for any DEP business cases for IT

projects. Each section contains instructions (in blue text) and guidelines in brackets []. Whendeveloping your business case, be sure to remove the bracketed instructions text and replace with

the text pertaining to your specific business case.

The DEP business case template is scalable to the nature and impact of the proposed project.The number of pages of any specific business case will vary, depending on the subject matter of

the case. It may be a brief 2-4 page document or an extensive evaluation consisting of 20 to100

pages. However, the length of the business case should be kept to a minimum, ensuring it stays

on topic, presents relevant information in a clear and concise manner, and is focused onsupporting management in making decisions. The time and effort spent on a business case

should be in proportion to the scope of the problem. A general rule of thumb is that a businesscase should take approximately 5-10% of the expected actual project time. For example:

25 day project to implement the business opportunity = 2 days to put together a completebut straightforward and simple business case

3 month project to implement the business opportunity = 9 days to put together an

appropriately detailed business case

1 year project to implement the business opportunity = 1 1.5 months to put together adetailed business case

3 year project to implement the business opportunity = 3 months to put together a

comprehensive business case

As an option, you may use the Schedule IV-B Feasibility Study methodology in place of

this DEP business case methodology. The Schedule IV-B Feasibility Study templates

were simplified and adapted to form the basis of the DEP business case templates herein,so they may be used as an acceptable substitute. You can download the Feasibility Study

documents at http://trw.state.fl.us/iv-b_downloads.cfm.

5
http://trw.state.fl.us/iv-b_downloads.cfmhttp://trw.state.fl.us/iv-b_downloads.cfm


6/27


7/27

If possible, the Executive Summary should be a maximum of two pagesin length.]

7


8/27

3.0 Business Problem/Need(s)

[Describe in detail the specific business problem or need that is drivingthe proposed project. Focus on the business side of the problem, notthe proposed technical solution. Remember that the business caseemphasizes the non-technical reason to conduct a project. Forexample, enhancing an existing software system may improve overallsystem performance, but the business need being addressed may befor increased customer satisfaction through improved systemperformance.

Address the business needs in three categories:

Strategic affecting the entire organization and/or key external

stakeholders

Tactical affecting multiple business units Operational affecting specific business processes within a given

functional area.

If there is a legislative mandate associated with the project, note this,but it does not obviate the need to describe the underlying businessneed or problem. ]

8


9/27

4.0 Business Objective(s)

[Describe the business objectives that the proposed project willachieve. Business objectives are distinct from (although related to) theproject objectives. Business objectives address the business need(s)identified above; the successful execution of the project would allowthe agency to achieve the business objectives and satisfy the statedbusiness needs.

Business objectives can be strategic, tactical or operational in natureand correspond to the business needs in the same categories.Examples of objectives include:

Improve customer satisfaction by reducing processing time from

1 hour to 30 minutes, by March 2009

Reduce administration costs from $2.2 to $1.1 million for the

2010 fiscal year Increase access to data for stakeholders

Improve coordination of services between business units

To the greatest extent possible, identify quantifiable businessobjectives like those specified in the above examples. Theseobjectives can then be used to define tangible benefits in the Cost-Benefit Analysis.]

9


10/27

5.0 Current State

[Describe the current state within which the business operates as itrelates to the specified business need(s) that will be addressed by theproposed project. This will help in understanding the businessprocesses, stakeholders and current technologies that will be affectedby the project and the level of business transformation that will berequired for the project to be successful.

Include the following information:

Current Business Process(es) - Describe the current businessprocess(es) that will be impacted by the proposed project. Includeinformation on how the project will improve the current processes tomeet the stated business objectives. Describe how the related

business functions are performed using the current system orprocess (if one exists)whether it is automated, manual or acombination.

Ideally, include a process flowchart describing the current process.The process flowchart for the business case analysis should be at alevel that describes the overall process without providing excessivedetail. The intent is to provide a management-level understandingof the process that the proposed project will be augmenting orreplacing.

Stakeholders- Identify all DEP organizational units and externalparties (other government agencies, permitees, the general public,etc.) who will be affected (positively or negatively) by the project.Identify those stakeholders that will be primary (directly impactedand involved in the project), and those that will be secondary(impacted but not directly involved in the project).

Current technology/system Identify any impacts to any existingsystem(s) and technologies that are supporting the businessprocesses. Include such areas as infrastructure, servers, software,databases, etc. List all impacts related to the affected areas in

moving forward with the project.

Assumptions and Constraints - Identify any departmental, state,federal, or industry standards or unique business requirements thatmight limit the range of reasonable technical alternatives. Identifyany assumptions and constraints that affect the problem oropportunity being addressed through the proposed project and that

10


11/27

may affect the implementation and acceptance of the proposedsolution.]

11


12/27

6.0 Alternatives

[Describe the alternatives that are available to address the problem orneed and meet the stated business objectives. Always include thealternative to do nothing (i.e., maintain status quo) as a valid option.Clearly identify the pros and cons of each alternative and why theselected solution (that is, the proposed project) was selected. Defineeach alternative in sufficient detail to enable identification of specificimpacts (Business & Operational Impacts), project risks, and benefitversus costs. Include any detailed requirements analysis in anappendix.]

12


13/27

7.0Proposed Solution

[Define the parameters of the proposed solution (project). Include thefollowing elements:

1. Scope (In Scope & Out of Scope) Provide details of theproject scope, both what is in-scope and what is specifically out ofscope.

2. Work Breakdown Structure (WBS) A WBS is a graphicaldepiction of the major project phases and significant project workpackages or deliverables. The WBS defines at a summary level allwork that will take place within the project.

A WBS is also an important part of developing the schedule.

Whereas the project schedule is calendar-based, the WBS isdeliverable-based. While there are no dates directly associated withthe WBS, the WBS helps you create the project timeline andultimately, a resourced project schedule. Breaking down, ordecomposing, the phases into the required work packages ordeliverables helps in clearly identifying what work must be done.Only when you understand what work needs to be done can youassociate that work with the dates in the project timeline andultimately a schedule that includes necessary resources toaccomplish the work in the WBS.

For the business case, you do not need to decompose the WBSdown to the task/activity level, but do decompose the WBS down tothe level of the major work packages/deliverables. Figures 1 and 2provide an example of a WBS framework and a typical WBS for asoftware development project.

13


14/27

Figure 1: Work Breakdown Structure Framework

14


15/27

Figure 2: WBS for a Typical Software Development Project, with Some Branches Fully Decomposed

15


16/27

3. Business & Operational Impacts Provide a list of allbusiness and operational impacts for the technology infrastructure,staff and business processes affected by the project. Describe theanticipated changes that would result from implementation of the

future process (the project). Do not consider cost at this point.Impacts include (but not necessarily limited to):

Required hardware

Required software (off-the-shelf or developed)

Other required technology

Infrastructure

Databases

Communications capabilities

Personnel changes (Hiring, Re-training, Re-alignment, Staff

Reduction) Recurring operations and support requirements

Change in service and/or products being provided]

16


17/27

8.0 Project Schedule & Resource Requirements

[Include a project schedule within this section. At this point, the schedulewill be high-level, but should be detailed enough so that managementunderstands the entire scope of the project, the required resource types andthe estimated project timeline.

This section should include:

High-level project schedule, deliverables and estimated

durations (not calendar dates) for completion. The project scheduleshould include the major project phases and milestones and it mustmap to the identified work packages from the WBS.

Anticipated resource requirements and types (e.g. J2EE

developer, project manager, network engineer, etc.), as well as

required skill level (junior, intermediate, senior) Expected number(s) of each anticipated resource, in full-time

employee equivalents

The project schedule should consider the following elements as applicable:

Planning activities (developing project plan, SOW and other planning

elements)

Procurement activities (Request for Quotes, Requests for Proposals,

Competitive Bid analysis, etc.)

Any (remaining) analysis effort

Requirements gathering and analysis

System Design, Development, Testing and Implementation activities

Development of technical documentation

Training for users and support personnel

Transition to production operations

Reviews and audits

Closing procedures

The following table shows a sample resourced project schedule. You mayuse any appropriate format (Microsoft Project Schedule, Excel, Word, etc.),as long as the required information is included.

Note: At the stage of business case development, all project aspects willnot be fully known. However, to the greatest extent possible, enough detailshould be provided so that your management can make an informeddecision to move forward with the project or not. For cases where there aretoo many unknowns, you may be directed to break the business case intomultiple phases, initially focusing on an analysis or discovery phase where

17


18/27

you will gather more detailed information to form the basis of a solidbusiness case. ]

18


19/27

Sample Resourced Project Schedule

Phase/Deliverable/Milestone

EstimatedDuration

Anticipated ResourceRequirement & Type

Resource SkillLevel

Phase 1 PlanningDevelop SOW/projectplan/resourced schedule

3 weeks Project Manager (1) Intermediate

Phase 2 Needs AnalysisDocument business needs 7 weeks Project Manager (1)

Business Analyst (1.5)IntermediateSenior

Generate functionalrequirements

3 weeks Project Manager (1)Business Analyst (1)Programmer/Analyst(1)

IntermediateSeniorIntermediate

Phase 3 Design 10 weeks Project Manager (1)Business Analyst (1)Programmer/Analyst(1)Systems Architect (1)

IntermediateSeniorIntermediateIntermediate

Phase 4 - Development 15 weeks Project Manager (1)Programmer/Analyst(2)Systems Architect (1)

IntermediateIntermediate/SeniorIntermediate

Phase 5 Testing 4 weeks Project Manager (1)Programmer/Analyst(2)

Systems Architect (1)QA testers (2)

IntermediateIntermediate/Senior

IntermediateJunior/Intermediate

Phase 6 - Implementation 4 weeks Project ManagerProgrammer/Analyst(1.5)Systems Architect (1.0)

IntermediateIntermediate/SeniorIntermediate

Phase 7 - Project Closeout 3 weeks Project Manager (1.0)Business Analyst (0.5)

IntermediateJunior

]

19


20/27

9.0 Cost-Benefit Analysis

[The Cost-Benefit Analysis (CBA) includes an evaluation of the costsversus the benefits associated with the proposed project. This allowsthe reader to easily understand and compare the initial and on-goingproject costs to the expected financial and non-financial benefits forthe project.

1. Identify all expected costs for the proposed solution. Theseinclude initial project costs to implement the solution, as well asongoing operational and maintenance costs over a five-year timeframe. If a time frame other than five years is used, justify thereason for using either a shorter or longer time frame and modifythe associated CBA Calculation forms accordingly.

Consider initial, direct, indirect and ongoing costs. Include thosecosts associated with:

Project team, with consideration to number of

resources, type and amount of effort hours the resourcewill be required

Required hardware, software and services

Anticipated training requirements (users and support

personnel)

Technical documentation requirements

Recurring operational and support requirements

Total cost of ownership analysis (development,

enhancement, maintenance and operations over the lifeof the project)

Consider:

When the costs will be incurred

Who will incur the costs

Certainty of costs

Uncertainty in the cost estimates

2. Identify both tangible and intangible benefits. A tangible benefit

is one that is measurable in terms of dollars. Examples oftangible benefits include: 1) Reduction in maintenance contractcosts of $200,000 per year 2) Reduction in costs to processpermit of $25,000 per year. An intangible benefit is not readilymeasurable in monetary terms and generally relates to broaderorganizational, social, technical, political or functional issues.Identify and discuss all intangible benefits.

20


21/27

Some examples of various types of project benefits are:

21


22/27

FUNCTIONAL AREA

DIRECT AND INTUITIVE

BENEFITS

INDIRECT AND STRATEGIC

BENEFITS

Agency/Office

Faster business transactionsIncreased access to information

Increased data integrationacross applications

Stronger relationship withcustomer/citizens

Enhanced responsivenessBetter serviceEnhanced agency reputation

InformationServices

More effectively integratedsystemsEase of support

Increased system availabilityMore satisfied end-users

CustomerService

Reduce manual effortReduce data entryReduce paper processAvoid hiring more staff

Faster, more effective customersupportLower burden on mailroomReduced process steps facilitate fasteprocessing of information

Finance Reduce discrepanciesReduce claims and adjustmentsReduce data entry

Process improvements inreconciliation of invoice, purchaseorder and remittanceReduced phone time/ improvedefficiency

Administrative

Reduce manual effortReduce data entry errorsReduce paper process

Reduce redundancyStreamlined time to processinformationAccomplish more without additionalhires

Ultimately, the decision to proceed with a project may hinge on

demonstrable evidence that the benefits of the project willoutweigh thecosts. Therefore, focus your attention on tangiblebenefits as opposed to intangible benefits. Consider thefollowing:

When the benefit will be realized

Who will realize the benefit

How will the benefit realization be measured and/or

assessed

Uncertainty in the cost savings estimates for tangible

benefits

3. Document the expected Tangible and Intangible Benefits in aBenefits Realization Table:

Benefits Realization TableDescriptio

n ofTangible

orWho

receiveHow is

theHow will benefitrealization be

Whenwill the

22


23/27

Benefit Intangible?

s thebenefit

?

benefitrealized

?

assessed/measured?

benefitbe

realized?

(MM/YY)

12345

23


24/27

a. Briefly describe each benefit that is expected fromimplementing the proposed project. Indicate whether theexpected benefit is tangible or intangible. A tangiblebenefit results in a business change with quantifiablefinancial value, such as:

i. New or increased revenuesii. New or increased reimbursements (grants, federalfinancial participation)

iii. Cost reductionsiv. Personnel cost reductions

b. Intangible benefits are positive business outcomes thatdo not have a clear financial measure. Some examplesof intangible benefits include:

i. Strategic fit between the projects technologyand the agencys technology standards

ii. Increased data availability enabling moreinformed decision-making

iii. Increased flexibility by allowing several peopleto perform a task rather than one person

iv. Reductions in backlogs or workloads that will notresult in program staffing or cost changes

v. Complying with statute or rule (may be tangibleor intangible)

vi. Improving current or enabling new customerservices

c. Identify the recipient(s) of the benefit.

d. Briefly describe any actions or processes that arenecessary for the recipient to receive the benefit (e.g., ashort statement of how the benefit will be realized).

e. Briefly describe how the program will assess or measurewhen and how benefits are realized within the intendedprogram(s).

f. Enter the proposed date (month and year) that the

benefits are to be realized. For multi-year projects,there may be recurring benefits that need to beidentified on multiple lines by year in the BenefitsRealization Table or with multiple dates in the benefitsrealization date column.

24


25/27

The identified Tangible Benefits are used in the subsequent Cost-Benefit Analysis to show the proposed projects return oninvestment to the program, agency and/or State.

4. Document the expected project costs and the tangible benefits in

the Cost-Benefit Analysis Calculation Forms. Refer to the Cost-Benefit Analysis Toolkit(Excel Workbook) for detailedinstructions on how to complete these forms.

5. Address the costs or impacts to the program area if the project isnot done. If needed, you may use the full Schedule IV B Cost-Benefit Analysis workbook provided by the Florida TechnologyReview Work Group at http://trw.state.fl.us.]

25
http://trw.state.fl.us/http://trw.state.fl.us/


26/27

10.0 Risk Assessment

[The Risk Assessment section provides management with anunderstanding of how typical IT project risks will contribute to theoverall project risk. The Risk Assessment section does not include alist of the risks you anticipate for this specific proposed project.Instead, the Risk Assessment Tool (Excel workbook) helps to identifyand quantify how typical risks will contribute to the overall project risk.The tool will highlight risk areas that may need to be addressed beforethe project is approved to proceed or during the project planningphase.]

26


27/27

11.0 Review and Approval

[The Review and Approval Section includes the signatures of thosewithin the divisions/offices management hierarchy who havereviewed and approved the final business case. At a minimum, the ITCoordinator, the project sponsor and the division/office director mustbe included in the review/signature list. Additional management levels(program administrator, bureau chief, etc.) may be included asappropriate. Use the following as a review/approval signature pagetemplate, adding additional reviewers as needed. Do not remove anyof the reviewers specified on this template.

Once approved and signed by the business areas management, submitthe business case to the DEP Chief Information Officer (CIO) for reviewand approval. ]

Approval Signatures

IT Coordinator:

Signature: Date:

Project Sponsor:

Signature: Date:

Division/Office Director:

Signature: Date:

OTIS Project Management Officer:

Signature: Date:

DEP Chief Information Officer

Signature: Date:

For OTIS Use Only:

OTIS Project Coordinator

Comments:

Business Case Document

Documents

Transcript of Business Case Document