DEP Information Technology Business Case Template and Instructions

FINAL
Version 1.0

REVISION HISTORY
Date 9/1/07 1/3/08 1/22/08 Description Created Circulated to IT Coordinators for comments incorporated comments received and conducted editorial revisions Approved by CIO, R. John Willmott Version DRAFT 1.0 DRAFT 2.0 FINAL 1.0

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

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 analyzing and 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 elements to 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 technical information 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-tounderstand 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. While there 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

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 the overall 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 []. When developing 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 on supporting 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 business case 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 complete but 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 a detailed 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.

1.0 Cover Page

[Each business case document should include a Cover Page. The cover page must contain at a minimum the project name, division/office name, document issue date and version number. The document issue date and version number should go into the footer].

2.0 Executive Summary

[Provide a brief executive summary of the business case. The executive summary should provide a concise summary of the key highlights of the business case analysis. 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 Executive Summary should describe the objective of the project, the current state of the problem (why you want/need to conduct the project to remedy a particular situation) and the resulting opportunity. It should: Describe how the project will take advantage of an opportunity or meet a business/organizational challenge or fulfill a need Explain how the proposed solution will provide better service to the citizens of Florida and/or solve a standing problem that the Department is experiencing Describe the business impact and the risks of undertaking the project Conclude with recommendations and the financial impact of the project. Be sure to address the cost/benefit of not doing the project versus doing the project.

The Executive Summary should stand alone as the single source of the overall project objectives, goals, proposed actions, cost/benefits, risks and success criteria. It should assist an executive-level sponsor in assessing the value of the project and provide a reasonable expectation of a successful implementation. The Executive Summary Section should be brief enough to give a full understanding of the business case supporting the proposed project, including all relevant facts and key issues, and should be clear, understandable and precise. Although the Executive Summary appears at the beginning of a business case, it should be written last, once you have all of the additional pieces below arranged.

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

3.0 Business Problem/Need(s)

[Describe in detail the specific business problem or need that is driving the proposed project. Focus on the business side of the problem, not the proposed technical solution. Remember that the business case emphasizes the non-technical reason to conduct a project. For example, enhancing an existing software system may improve overall system performance, but the business need being addressed may be for increased customer satisfaction through improved system performance. 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 business need or problem. ]

4.0 Business Objective(s)

[Describe the business objectives that the proposed project will achieve. Business objectives are distinct from (although related to) the project objectives. Business objectives address the business need(s) identified above; the successful execution of the project would allow the agency to achieve the business objectives and satisfy the stated business needs. Business objectives can be strategic, tactical or operational in nature and 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 business objectives like those specified in the above examples. These objectives can then be used to define tangible benefits in the CostBenefit Analysis.]

5.0 Current State

[Describe the current state within which the business operates as it relates to the specified business need(s) that will be addressed by the proposed project. This will help in understanding the business processes, stakeholders and current technologies that will be affected by the project and the level of business transformation that will be required for the project to be successful. Include the following information: Current Business Process(es) - Describe the current business process(es) that will be impacted by the proposed project. Include information on how the project will improve the current processes to meet the stated business objectives. Describe how the related business functions are performed using the current system or process (if one exists)whether it is automated, manual or a combination. Ideally, include a process flowchart describing the current process. The process flowchart for the business case analysis should be at a level that describes the overall process without providing excessive detail. The intent is to provide a management-level understanding of the process that the proposed project will be augmenting or replacing. Stakeholders- Identify all DEP organizational units and external parties (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 impacted and 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 existing system(s) and technologies that are supporting the business processes. 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 that might limit the range of reasonable technical alternatives. Identify any assumptions and constraints that affect the problem or opportunity being addressed through the proposed project and that

10

may affect the implementation and acceptance of the proposed solution.]

11

6.0 Alternatives
[Describe the alternatives that are available to address the problem or need and meet the stated business objectives. Always include the alternative to do nothing (i.e., maintain status quo) as a valid option. Clearly identify the pros and cons of each alternative and why the selected solution (that is, the proposed project) was selected. Define each alternative in sufficient detail to enable identification of specific impacts (Business & Operational Impacts), project risks, and benefit versus costs. Include any detailed requirements analysis in an appendix.]

12

7.0 Proposed Solution

[Define the parameters of the proposed solution (project). Include the following elements: 1. Scope (In Scope & Out of Scope) Provide details of the project scope, both what is in-scope and what is specifically out of scope. Work Breakdown Structure (WBS) A WBS is a graphical depiction of the major project phases and significant project work packages or deliverables. The WBS defines at a summary level all work 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 is deliverable-based. While there are no dates directly associated with the WBS, the WBS helps you create the project timeline and ultimately, a resourced project schedule. Breaking down, or decomposing, the phases into the required work packages or deliverables helps in clearly identifying what work must be done. Only when you understand what work needs to be done can you associate that work with the dates in the project timeline and ultimately a schedule that includes necessary resources to accomplish the work in the WBS. For the business case, you do not need to decompose the WBS down to the task/activity level, but do decompose the WBS down to the level of the major work packages/deliverables. Figures 1 and 2 provide an example of a WBS framework and a typical WBS for a software development project.

2.

13

Figure 1: Work Breakdown Structure Framework

14

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

15

3.

Business & Operational Impacts Provide a list of all business and operational impacts for the technology infrastructure, staff and business processes affected by the project. Describe the anticipated 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

8.0 Project Schedule & Resource Requirements

[Include a project schedule within this section. At this point, the schedule will be high-level, but should be detailed enough so that management understands the entire scope of the project, the required resource types and the estimated project timeline. This section should include: High-level project schedule, deliverables and estimated durations (not calendar dates) for completion. The project schedule should include the major project phases and milestones and it must map 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 may use 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 will not be fully known. However, to the greatest extent possible, enough detail should be provided so that your management can make an informed decision to move forward with the project or not. For cases where there are too many unknowns, you may be directed to break the business case into multiple phases, initially focusing on an analysis or discovery phase where
17

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

18

Sample Resourced Project Schedule Phase/Deliverable/Mileston e

Phase 1 Planning Develop SOW/project plan/resourced schedule Phase 2 Needs Analysis Document business needs Generate functional requirements Phase 3 Design

Estimated Duration
3 weeks 7 weeks 3 weeks 10 weeks

Anticipated Resource Requirement & Type

Project Manager (1) Project Manager (1) Business Analyst (1.5) Project Manager (1) Business Analyst (1) Programmer/Analyst(1) Project Manager (1) Business Analyst (1) Programmer/Analyst(1) Systems Architect (1) Project Manager (1) Programmer/Analyst(2) Systems Architect (1) Project Manager (1) Programmer/Analyst(2) Systems Architect (1) QA testers (2) Project Manager Programmer/Analyst(1.5) Systems Architect (1.0) Project Manager (1.0) Business Analyst (0.5)

Resource Skill Level

Intermediate Intermediate Senior Intermediate Senior Intermediate Intermediate Senior Intermediate Intermediate Intermediate Intermediate/Senior Intermediate Intermediate Intermediate/Senior Intermediate Junior/Intermediate Intermediate Intermediate/Senior Intermediate Intermediate Junior

Phase 4 - Development Phase 5 Testing

15 weeks 4 weeks

Phase 6 - Implementation Phase 7 - Project Closeout

4 weeks 3 weeks

19

9.0 Cost-Benefit Analysis

[The Cost-Benefit Analysis (CBA) includes an evaluation of the costs versus the benefits associated with the proposed project. This allows the reader to easily understand and compare the initial and on-going project costs to the expected financial and non-financial benefits for the project. 1. Identify all expected costs for the proposed solution. These include initial project costs to implement the solution, as well as ongoing operational and maintenance costs over a five-year time frame. If a time frame other than five years is used, justify the reason for using either a shorter or longer time frame and modify the associated CBA Calculation forms accordingly. Consider initial, direct, indirect and ongoing costs. Include those costs associated with: Project team, with consideration to number of resources, type and amount of effort hours the resource will 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 life of 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 of tangible benefits include: 1) Reduction in maintenance contract costs of $200,000 per year 2) Reduction in costs to process permit of $25,000 per year. An intangible benefit is not readily measurable in monetary terms and generally relates to broader organizational, social, technical, political or functional issues. Identify and discuss all intangible benefits.

20

Some examples of various types of project benefits are:

21

FUNCTIONA L AREA Agency/Offic e

DIRECT AND INTUITIVE BENEFITS Faster business transactions Increased access to information Increased data integration across applications More effectively integrated systems Ease of support Reduce manual effort Reduce data entry Reduce paper process Avoid hiring more staff Reduce discrepancies Reduce claims and adjustments Reduce data entry Reduce manual effort Reduce data entry errors Reduce paper process

Information Services Customer Service

INDIRECT AND STRATEGIC BENEFITS Stronger relationship with customer/citizens Enhanced responsiveness Better service Enhanced agency reputation Increased system availability More satisfied end-users Faster, more effective customer support Lower burden on mailroom Reduced process steps facilitate faster processing of information Process improvements in reconciliation of invoice, purchase order and remittance Reduced phone time/ improved efficiency Reduce redundancy Streamlined time to process information Accomplish more without additional hires

Finance

Administrativ e

Ultimately, the decision to proceed with a project may hinge on demonstrable evidence that the benefits of the project will outweigh the costs. Therefore, focus your attention on tangible benefits as opposed to intangible benefits. Consider the following: 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 a Benefits Realization Table:

Benefits Realization Table

Descriptio n of Tangible or Who receive How is the How will benefit realization be When will the

22

Benefit

Intangible ?

s the benefit ?

benefit realized ?

assessed/measure d?

benefit be realized ? (MM/YY )

1 2 3 4 5

23

a. Briefly describe each benefit that is expected from implementing the proposed project. Indicate whether the expected benefit is tangible or intangible. A tangible benefit results in a business change with quantifiable financial value, such as: i. New or increased revenues ii. New or increased reimbursements (grants, federal financial participation) iii. Cost reductions iv. Personnel cost reductions b. Intangible benefits are positive business outcomes that do not have a clear financial measure. Some examples of intangible benefits include: i. Strategic fit between the projects technology and the agencys technology standards ii. Increased data availability enabling more informed decision-making iii. Increased flexibility by allowing several people to perform a task rather than one person iv. Reductions in backlogs or workloads that will not result in program staffing or cost changes v. Complying with statute or rule (may be tangible or intangible) vi. Improving current or enabling new customer services c. Identify the recipient(s) of the benefit. d. Briefly describe any actions or processes that are necessary for the recipient to receive the benefit (e.g., a short statement of how the benefit will be realized). e. Briefly describe how the program will assess or measure when and how benefits are realized within the intended program(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 be identified on multiple lines by year in the Benefits Realization Table or with multiple dates in the benefits realization date column.

24

The identified Tangible Benefits are used in the subsequent CostBenefit Analysis to show the proposed projects return on investment 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 CostBenefit Analysis Toolkit (Excel Workbook) for detailed instructions on how to complete these forms. 5. Address the costs or impacts to the program area if the project is not done. If needed, you may use the full Schedule IV B CostBenefit Analysis workbook provided by the Florida Technology Review Work Group at http://trw.state.fl.us.]

25

10.0 Risk Assessment

[The Risk Assessment section provides management with an understanding of how typical IT project risks will contribute to the overall project risk. The Risk Assessment section does not include a list of the risks you anticipate for this specific proposed project. Instead, the Risk Assessment Tool (Excel workbook) helps to identify and quantify how typical risks will contribute to the overall project risk. The tool will highlight risk areas that may need to be addressed before the project is approved to proceed or during the project planning phase.]

26

11.0 Review and Approval

[The Review and Approval Section includes the signatures of those within the divisions/offices management hierarchy who have reviewed and approved the final business case. At a minimum, the IT Coordinator, the project sponsor and the division/office director must be included in the review/signature list. Additional management levels (program administrator, bureau chief, etc.) may be included as appropriate. Use the following as a review/approval signature page template, adding additional reviewers as needed. Do not remove any of the reviewers specified on this template. Once approved and signed by the business areas management, submit the business case to the DEP Chief Information Officer (CIO) for review and 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: For OTIS Use Only: Date:

OTIS Project Coordinator

Comments:

27