Attachment_2_DOD_Requirements_Validation_Instructions_and_Template.pdf

DOD REQUIREMENTS VALIDATION AND IT BUSINESS CASE ANALYSIS TEMPLATE FOR BUSINESS

SYSTEMS—MARCH 2015

Per SECDEF directive, include the cost estimate associated with preparing this BCA. See SECDEF Memo of 27 Dec 2010, Subject: Consideration of Costs in DoD Decision-Making, in Appendix H for information and instructions.

UNCLASSIFIED

D E P A R TM E N T O F D E F E N S E

DOD REQUIREMENTS VALIDATION AND ENTERPRISE IT BUSINESS CASE ANALYSIS TEMPLATE

<<Template Forward/Instructions>>

<<Delete this page when tailoring. All template guidance within<< >> should be deleted prior to submission>>

<<Tailor per project appropriately given project scope, size, state/documentation availability/time/other constraints for PS-BCA preparation>>

<<Instructions regarding PS-BCA Classification Marking:>>

<<UNCLASSIFIED: If the final BCA does not contain sensitive or classified information, mark the front and back covers “UNCLASSIFIED” (as shown on this BCA template).>>

<<FOUO: A “For Official Use Only” (FOUO) designation applies to unclassified information sensitive in nature and exempt from public release under the Freedom of

Information Act. If the BCA contains such information, “FOUO” must appear on the front and back covers (where UNCLASSIFIED now appears) and on the page(s) on which the sensitive information exists.>>

<<CLASSIFIED: PS-BCAs containing any CLASSIFIED information are to be handled through separate channels, in accordance with the submitting organization’s

CLASSIFIED handling process and all applicable security policy procedures.>>

DOD REQUIREMENTS VALIDATION AND IT BUSINESS CASE ANALYSIS TEMPLATE FOR BUSINESS SYSTEMS

Requirements Validation Version History

Ver.

No, Version Date

Change Type

Change Authority

Disposition

Reference

1.0 23-10-2014 Initial Release of the BCA Template

CIO

2.0 05-11-2014 Incorporation of Problem Statement Requirements into BCA template

DCMO

3.0 01-20-2015 Inclusion of PS Working Group feedback; Updates for Clarity

DCMO

4.0 02-12-2015 Updates for clarity and improved process flows

DCMO

5.0 03-17-2015 Updates for clarity on Step1 of the process & diagram

DCMO

Table of Contents

Table of Contents

Problem Statement Instructions

Process Directions

Executive Summary

Section 1: DOTMLPF-P Capabilities

Section 2: Legal, Regulatory and Policy (LRP) Requirements

Section 3: Performance Measures/Attributes

Section 4: Enterprise Architecture Analysis

Section 5: Business Process Models to Support Business Process Re-engineering (BPR) Assertions

Section 6: DOTMLPF-P Implementation Plan, to Include Anticipated Return-on-Investment (RoI)

Section 7: Rough-Order-of-Magnitude (ROM)

Section 8: Link to Out-of-Cycle (OOC) Requests or Other Investment(s)

1.0 Business Case Analysis (BCA) Overview

2.0 Assumptions, Constraints, and Evaluation Methodologies

2.1 Costing Assumptions and Constraints

2.2 Non-Financial Assumptions and Constraints

2.3 Other Constraints

2.4 Economic Viability Assessment Methodology

2.5 Non-Financial Measure Scoring Methodologies

3.0 Alternatives Considered

3.1 Baseline and Alternatives Overview

3.2 Alternative 1 (Baseline) Overview

3.2.1 Cost and Economic Viability

3.2.2 Requirements Summary

3.2.3 Qualitative Benefits

3.2.6 Risk Summary

3.3 [Short Descriptive Name of Alternative 2] Overview

3.3.1 Cost and Economic Viability

3.3.2 Requirements Summary

3.3.3 Qualitative Benefits

3.3.6 Risk Summary

3.4 <Short Descriptive Name of Third Alternative> Overview

4.0 Comparison of Alternatives

4.1 Comparison of Alternatives’ Economic Viability Measures

4.2 Comparison of Costs and Savings

4.3 Comparison of Overall Requirements Satisfaction

4.4 Comparison of Mission and Operational Benefits/Impacts

4.5 Risk Comparisons

4.6 Sensitivity Analysis (Optional)

4.7 Other Considerations

5.0 Conclusions and Recommendations

5.1 Summary Comparison and Recommendation

5.2 Funding Needs and Sources

Appendix A: Glossary

Appendix B: Cost Element Structure

Appendix C: Requirements

Appendix D: OFF-SET Detail

Appendix E: Project Plan

Appendix F: Performance Measures

Appendix G: Economic Viability Assessment

Appendix H: Reference Documents

PROBLEM STATEMENT INSTRUCTIONS

Process Directions The following template outlines the format necessary for the review and adjudication of a Problem Statement.

All submissions need to adhere to this design to ensure the business need is clearly and fully represented. Do not omit any sections without the approval of the Office of the Deputy Chief Management Officer (ODCMO) or its designee. Requests to vary from the approved format must be submitted in writing, and approval/disapproval of the request will be issued in writing.

All Problem Statements will be initially reviewed and validated by the appropriate business area lead (e.g.

Human Resources Management (HRM), Acquisition) within the ODCMO. For coordination, all submissions will be shared with the Defense Business Council (DBC) members for their review and comment. The objective is to complete reviews within five (5) business days. Timelines may vary depending on scope and complexity of the stated requirement. All nonconcurs must be mitigated before final approval is granted.

Problem Statements must be signed by the Functional Sponsor and validated by the Precertification Authority (PCA), in writing, prior to submission. If either one or all of these validations is missing upon submission, the Problem Statement will be returned until the proper signatures are obtained.

For the purposes of this review and approval, the Functional Sponsor is defined as the senior executive responsible for activities of the requirements validation phase to include: defining the business need (problem / gap); desired outcomes; and, acceptance criteria. The Functional Sponsor remains actively engaged in the program throughout its lifecycle in order to achieve the complete Doctrine, Organization, Training, Materiel, Leadership and education, Personnel, Facilities, and Policy (DOTMLPF-P) solution, and for declaring the Initial Operating Capability (IOC) and the criteria for declaring Full Deployment (FD)1.

Approach

The Requirements Validation (i.e. Problem Statement) portion of this template will be submitted in two (2) parts. The first part consists of the Executive Summary and Sections 1-3 of the template. The second part consists of the approved content from Part 1 and the addition of Sections 3-8. The criteria needed for each section is outlined below. The purpose of Part 1 is to allow the DCMO and the Offices of the Principle Staff Assistants (PSAs) an initial review (e.g. checkpoint) of the requirement to help determine its alignment to the functional strategy, cross-functional dependencies and enterprise applicability. At the conclusion of Part 1 of the process, the DCMO will provide the Component with an initial assessment of the need, to include areas for improvement or clarity. The DCMO can also assist with a review by the Defense Business Council (DBC), at this stage, if needed. Once Part 1 is completed and reviewed, the requirement is returned to the Component to complete the remainder of the template. Upon completion of Part 2, the final requirements document will be submitted, in its entirety, for formal review, coordination and approval. When completing this package, it is important to note the following:

If a Requirements package meets any of the evaluation criteria noted in the “Thresholds” section, it will be routed to the DBC for review and comment.

1 DAU 12.4 DBS-specific Criteria: https://acc.dau.mil/CommunityBrowser.aspx?id=516884

A decision/recommendation may be made upon the completion of the Part 1 review not to proceed with the Requirement. Any recommendation not to continue will be a collaborative discussion between the submitting organization, the functional PSA and the DCMO in order to define the proper course of action to meet user requirements.

All iterations of the requirements validation process will be submitted electronically via the Problem Statement SharePoint portal: https://dcmo.osd.mil/coi/PS/SitePages/Home.aspx

Thresholds

A Requirements Validation package needs to be submitted for any development or modernization2 effort, regardless of the funding type. The guidance outlined in 10 USC §2222 is still applicable.

In support of the enhanced Requirements Validation process, there is no defined dollar threshold for submitting a requirement document/need. Submission evaluation criteria are based on the following:

Are the requirements enterprise/transformational and impacts cross-functional equities?

Are the requirements strategically aligned to the Agency Strategic Plan?

Do any LRPs affect or are affected by the DOTMLPF-P capabilities necessary to fulfill the business need/problem?

The template begins on the following page of this document. Depending on the scope of the requirement, the complete business requirement should be captured in 5-10 pages. Organizations are encouraged to consider these directions to ensure an accurate and timely review. The figures below outline the process flows and coordination points needed for the submission of Parts 1 and 2 of a Problem Statement.

Part 1Problem Statement Process

2 DoD FMR Vol 2b Ch18 (18-9)

Part 2 Problem Statement Process

Part 1 Submission Criteria

Executive Summary

Present an executive-level overview in 1-2 pages that describes:

A validated need/requirement. (Should be substantiated with statute, regulations, policy, strategic priorities, etc.)

Evidence that the need is not being met, including the magnitude and quantifiable measure(s) of the problem/gap, and which mission/functional areas are affected.

The proposed project/initiative that will address this problem and the organization/person(s) leading it; what mission outcomes, key objectives (preferably measurable) it satisfies; cost, savings, process improvements, other benefits and overall implementation timeline.

A summary of the project/initiative’s requirements.

Boundaries/scope of the project -- what is included and excluded. (If project will be executed in phases/spirals, identify how this BCA fits into a larger plan).

Summary of the comparison of alternatives. (Briefly describe alternatives considered and rationale for final selection).

High level implementation strategy and key milestones (e.g., start and delivery dates).

Key assumptions and constraints foundational to the analysis (may be referenced if difficult to summarize).

Contract vehicle(s) that could be utilized to host the proposed solution; and For cloud outsourcing/hosting situations, include a clear statement regarding any contract issues that impact this proposal (e.g., incorporating language into contract to mitigate known risks).

As appropriate, include a summary level comparison chart/graph/table of status quo and primary alternatives to presenting the recommendation.

Keep information at a summary level and focus on the most important points. Reference detailed discussion, if necessary.

The executive summary should be written last to make sure the analysis supports the recommendation rather than the other way around.

Part 1 serves as a checkpoint in the Requirements Validation process to ensure the defined requirements are not duplicative of exisiting tools or processes, are in alignment with strategic plans and/or identify exsiting interdependencies.

Section 1: DOTMLPF-P Capabilities

This section identifies specific DOTMLPF-P capabilities that are needed to solve the problem. The Subject Matter Experts (SMEs) should consider the entire DOTMLPF-P spectrum in identifying the required capabilities. The capabilities are very high level statements at this stage and will be further refined and detailed as the SMEs and the Sponsor work through the required sections. This section is designed to encourage the decomposition of warfighter needs into discrete and manageable capabilities, each of which is independently implementable and has standalone value to the warfighter. This section should outlined/address/validate a thorough review of the capabilities was conducted and note the results.

Section 2: Legal, Regulatory and Policy (LRP) Requirements

The purpose of this section is to identify LRP requirements that must be addressed by any potential solution and the specific content within the LRP sources that affect any potential solution. The nature of the LRP requirements affects the scope of the problem, placing requirements on the implementation of any solution, and can either complicate or simplify the implementation. It may be determined that LRP requirements may need to be changed or waived in order to solve the user’s need/problem. This section should outlined/address/validate a thorough review of the LRPs was conducted and note the results.

Section 3: Performance Measures/Attributes

A Performance Measure is a description of the successful delivery of capability in terms of desired outcomes.

Performance Measures are sometimes referred to as Measures of Success. Performance Attribute is a description of the components that make up the successful delivery of capability (performance measure). Performance measures and attributes must be defined and measured to determine the effectiveness of any potential implementation of the identified DOTMLPF-P capabilities. This section should outlined/address/validate a thorough review of applicable measures/attributes was conducted and note the results.

Part 2 Submission Criteria

Section 4: Enterprise Architecture Analysis

Enterprise Architecture is a management practice that aligns resources, improves business performance and assists agencies better execute their core missions. An EA describes the current and future state of the agency and lays out a plan for transitioning from the current state to the desired future state. (FEA Practice Guidance dated Nov 2007, http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_Practice_Guidan ce_Nov_2007.pdf) EA Analysis is an activity whereby the EA is referenced to inform a decision. An EA analysis can identify opportunities for reuse, inform legal, regulatory and policy constraints, identify dependent or tangential process and help to capture impacts to those processes caused by changes to a specific process.

After reviewing the defined Need/Problem Statement and capabilities, the Architecture Team will assist in determining if some capability already exists within the organization, other Services, DoD/Federal Agencies and partner nations that may solve the SME defined problem. If a solution already exists, the Sponsor will direct the SMEs to reuse the existing solution, and the requirement will terminate. If there is no duplication, the Architecture Team will review the requirements and ensure it aligns with the organization’s strategy, and that all relevant LRP requirements have been identified and will be satisfied by the capabilities requested by the SMEs. This section should outlined/address/validate a thorough review of the architecture was conducted and note the results.

Section 5: Business Process Models to Support Business Process Re-engineering (BPR) Assertions

BPR is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed3.

This section should outlined/address/validate a thorough review of BPR was conducted and note the results.

Section 6: DOTMLPF-P Implementation Plan, to Include Anticipated Return-on-Investment (RoI)

This section must include the different DOTMLPF-P solutions, characterized execution requirements, implementation work plans including schedules, resource allocations, anticipated RoI and investment auditability, and business case analysis supporting the solutions. This section will support/justify the continued review of this Problem Statement. This section should outline and validate the implementation plan and note the intended outcomes. Anticipated RoI must be quantitative monetization and support the ROM cited in Section 7 to the maximum extent possible. It may also include qualitative measures that improve mission performance as these are also important.

Section 7: Rough-Order-of-Magnitude (ROM)

A Rough Order of Magnitude Estimate (ROM estimate) is an estimation of a project’s level of effort and cost to complete. A ROM estimate takes place very early in a project’s life cycle — during the project selection and approval period and prior to project initiation in most cases. The main purpose of the ROM estimate is to provide decision-makers with the information necessary to make a decision on whether it makes sense to move forward with the project based on the estimated level of effort, in terms of completion time and cost.

The ROM, at this stage, is only applicable to the Requirements Validation stage of the process. This is the

3 DoDI 5010.43 initial assessment and any future cost of program development should be addressed in the Business Case Analysis (BCA) Cost Estimation section.

When submitting the ROM, the organization should consider and represent, as applicable, the Lifecycle Cost Estimates (LCE) as well as the projected costs over the Future Years Development Program (FYDP). The ROM estimate can be cited as <Low: $n, Expected: $n, High: $n> for LCE and the FYDP.

Section 8: Link to Out-of-Cycle (OOC) Requests or Other Investment(s)

If this requirement is aligned to an Out-of-Cycle (OOC) request, all relevant details should be outlined in this section to ensure continuity between the efforts, allowing for faster evaluation and approval timelines.

<Insert Component Name Here> <Insert Title Here>

Document Revision History

Version Date Summary of Changes

Version 1.0 <Insert date issued here> <Insert summary of changes here>

Problem Statement Signature

The undersigned concur that this requirement is valid and aligns to current strategies and mission objectives.

Functional Sponsor: Date:

<Insert name here> <Insert title here> <Insert organization here>

Precertification Authority (PCA): Date:

<Insert name here> <Insert title here> <Insert organization here>

Executive Summary < INSERT appropriate text>

Section 1: DOTMLPF-P Capabilities

Section 2: Legal, Regulatory and Policy (LRP) Requirements < INSERT appropriate text and/or tables>

Section 3: Performance Measures/Attributes

Section 4: Enterprise Architecture Analysis

Section 5: Business Process Models to Support Business Process Re-engineering (BPR) Assertions

Section 6: DOTMLPF-P Implementation Plan, to Include Anticipated Return-on-Investment (RoI)

Section 7: Rough-Order-of-Magnitude (ROM)

Section 8: Link to Out-of-Cycle (OOC) Requests or Other Investment(s)

Once a Problem Statement is approved, the contents of the Problem Statement document should be incorporated into the appropriate sections of the Enterprise Information Technology (IT) Business Case Analysis (BCA) template for IT investments. The format for the BCA is outlined in the following sections. The BCA is used once a requirement has been reviewed and approved and there is now a need for a material solution.

The BCA should leverage content from the Problem Statement, not duplicate, in order to adequately support the criteria noted in the subsequent sections.

< Organization >

<POC >

D E P A R TM E N T O F D E F E N S E

Ver.

No, Version Date

Change Type

Change Authority

Disposition

Reference

X.XX.XX DD-MM-YY [Initial approval, decision authority directed change;

governance board directed change;

minor update;

administrative change; new major version; other]

[Decision authority;

governance board;

integrated product team; project lead;

other]

<<Provide name and title>>

[Approved; approved with conditions;

disapproved; cancel;

other]

[Decision authority decision memorandum; governance board meeting minutes;

integrated product team or project lead or program manager email/ memorandum]

<<Provide link to document or document location.>>

Business Case Analysis Version History

1.0 BUSINESS CASE ANALYSIS (BCA) OVERVIEW

An approved Requirements Validation document can be submitted in support of this section of the BCA.

2.0 ASSUMPTIONS, CONSTRAINTS, AND

EVALUATION METHODOLOGIES

<<Sections 2.1-2.3 below describe assumptions and constraints (financial and non-financial) critical to the business case analysis. An assumption is an informed position about what is believed to be true for a situation in which explicit factual knowledge is unobtainable. Examples of assumptions include:

Extrapolation of facts from a limited data set (e.g., survey), Expectations of future outcomes based on historical precedence or other rationale, Information believed to be true based on credible authorities.

Constraints are factors that limit the analysis, possible solutions and/or expected outcomes. Examples of constraints include:

Availability of data and information, expertise, funding, manpower, etc.;

Requirement to satisfy legislation, regulations, and policy;

Technical capability of a solution.

Keep the assumptions and constraint descriptions at fairly high level. Add appendices as needed or refer to other documents for detailed computations. Assumptions and constraints unique to specific alternatives should be explained in Chapter 3, where each alternative is described in detail.>>

2.1 Costing Assumptions and Constraints

<<Assumptions represent a set of judgments about past, present, or future conditions postulated as true in the absence of positive proof. Describe key costing assumptions and constraints critical to the BCA.

Define the life cycle period for the analysis, which will impact the cost estimate tables used in the BCA.

Include all applicable fiscal years within the life cycle for each Alternative. Document discount rate and inflation rates used along with applicable dates/sources. Explain the confidence level in values and whether they represent low-, mid- or high-range estimates. Reference where more detailed costing information can be obtained.>>

2.2 Non-Financial Assumptions and Constraints

<<Describe non-costing related assumptions and constraints critical to the BCA. Explain why they are important and the extent to which they could affect the analysis or project results if they change.

Examples of non-financial constraints include government mandates, technological limitations and synchronization with other projects/initiatives. >>

2.3 Other Constraints

<<Document any additional constraints, such as schedule or budgetary constraints provided by senior leadership direction.>>

2.4 Economic Viability Assessment Methodology

<<Explain the economic viability measurement methodology used to compare alternative solutions.>>

<<Metrics should be generated for: net present value (NPV), break-even (BE), benefit cost ratio (BCR) and financial return on investment (ROI) using Appendix G as a guide.>>

2.5 Non-Financial Measure Scoring Methodologies

<<If the formats included in this BCA template are used, the standard language provided below may be used and/or tailored as desired. For example:

In addition to making financial comparisons between the [current state name] and each alternative, non-financial comparisons were also performed and scored as follows:

Requirements satisfaction: The degree to which each alternative satisfied mandatory requirements was scored on a scale of 1 (low) to 5 (high)). Weighting was [not used/used] for high priority requirements. [If weighting was used, explain rationale]. Specific requirements areas scored include:

[list in bullets and indicate which were weighted, as applicable].

Operational Impacts: The expected positive and negative impacts of implementing each alternative were evaluated across the following operational/business function areas: [list: e.g., mission/business function, interoperability, customer benefit, efficiency, information assurance/security, reliability/quality, sustainability, etc.] and scored on a scale of -5 (negative) to +5 (positive).

Risk: Potential areas of risk for [list risk areas] were identified. The probability of occurring (certain, probable, possible, improbable) and the impact if realized (catastrophic, high, moderate, low) were assessed for each alternative. Risk Management strategies were identified and all risks were rescored as if the risk management action had been implemented to assess effectiveness. >>

3.0 ALTERNATIVES CONSIDERED

3.1 Baseline and Alternatives Overview

<<Alternative 1, Baseline, Status Quo, and As Is are synonymous terms. State up front how many additional alternatives were considered for the BCA. For example:

The following [cite number] alternatives were considered for this BCA:

Alternative 1 – [Baseline/Status Quo/As Is] – [short description]

Alternative 2 – [short name] – [short description]

Alternative 3 – [short name] – [short description]

<<A minimum of three alternatives are recommended for BCA. >>

<<Consider criteria in formulating and evaluating possible alternatives to the problem. Criteria are based on mission need and required capability from the problem statement as well as on facts, assumptions, and the Voice of the Stakeholder or anything else that provides separation between alternatives. There are two types of criteria: screening and selection / evaluation criteria. Screening criteria are used to assess the viability of the alternatives, and can be used to constrain the number of alternatives to be evaluated. Selection / evaluation criteria are developed in order to differentiate among alternatives under consideration. Some examples of screening criteria include:>>

Screening Criteria Definition

Suitability Solves the problem and is legal and ethical. The alternative can accomplish the mission within the decision-maker's intent and guidance

Feasibility Fits within available resources

Acceptability Is worth the cost or risk

Distinguishability Differs significantly from other solutions

Completeness Contains the critical aspects of solving the problem from start to finish

<<Explain very generally why the alternatives were selected (e.g., alignment to goals, feasibility, cost, etc.) Additional detail is provided below. As appropriate, provide information on comparable projects and/or benchmark models if available.>> For example:

These alternatives were selected because [state reason(s)]. Each of these alternatives is described below in more detail and assessed across the following dimensions: cost, savings and economic viability; requirements satisfaction; operational impacts; and risk. Consistent formats and scoring methodologies were used so results can be easily compared.

3.2 Alternative 1 (Baseline) Overview

3.2.1 Cost and Economic Viability

<<Develop a life-cycle cost estimate (LCCE) by resource type (DME/O&S) and appropriation, for Alternative 1 (baseline/status quo/As-Is state) using the cost element structure in Appendix B as a guide.

Life-cycle cost estimates for each alternative will be compared with the baseline/status quo/As-Is estimate. Clearly state key cost/economic information for the alternative being discussed. For example:

The total cost (understood to be synonymous with Total Cost of Ownership) of this alternative is [state cost and timeframe]. It includes Direct, Indirect, and G&A costs for [explain materiel and non-materiel costs included]. Estimates are [explain: confidence in estimates; whether they represent high, medium, or low values; sensitivity (see definition)].>>

<<If the cost element structure in Appendix B is known, then the DME row in this table will equal the As-Is Investment row from the structure in Appendix B. In the write-up, articulate the appropriations included in the ‘Other’ rows of this table. It is acceptable to include extra rows for additional appropriations vice summing to ‘other’.>>

<<Apply discounting and economic analysis formulas per guidance in Appendix G to develop Economic Viability metrics.>>

Alternative 1 - Economic Viability

Net Present Value

(NPV) =

Break Even (Discounted) =

Benefit Cost Ratio

(BCR) =

Return on Investment

(ROI) =

3.2.2 Requirements Summary

<< Provide a summary for how Alternative 1 satisfies requirements. For example:

This alternative satisfies [all, most, some] known requirements. Its greatest strengths are in [explain what they are and why they are important]. Its greatest limitations are [explain what they are and why they are an issue]. Expectations regarding how well this alternative is expected to satisfy each requirement have been scored and provided in the table below.>>

<< Scores, weights, and justification for the assigned Weights should be developed through a collaborative process with stakeholders and documented in this section. Sum of weights should = 100%.>>

Alternative # 1: Requirements Satisfaction

Requirement Score

(0 to 5)1 Weight2 Weighted

Score3 Score Rationale

[Describe requirement]

[Describe requirement]

Total Score4

1. Score range is: 0 (does not meet requirement), 1 (minimally meets requirement) to 5 (greatly exceeds requirement).

2. Weighting factor for high priority requirements

3. Weighted score = “score” multiplied by “weight factor”

4. The unweighted and weighted scores are summed to establish the total score

Resource Type (DME/O&S)

Appropriation

DME 2 2 2 0 0 0 0 6

RDT&E

Procurement

O&M

Other

O&S 4 4 4 4 4 4 4 28

RDT&E

Procurement

O&M

Other

TOTAL $6 $6 $6 $4 $4 $4 $4 $34

To Complete

LCCE

DME = Development, Modernization, or Enhancement

O&S = Operations and Sustainment

Alternative 1 (Baseline) Life Cycle Costs (dollars in mill ions)

Prior FY15 FY16 FY17 FY18 FY19 FY20 FY21

3.2.3 Qualitative Benefits

<<Clearly state the nature of any operational impacts the alternative under discussion presents.>> For example:

This alternative had [significant, moderate, minimal, no] negative operational impacts in the areas of [list], and [significant, moderate, minimal, no] positive benefits in the areas of [list].

<<Expand on significant issues, areas of concern and/or strengths and how they are likely to affect the success of the project. The table below may be tailored to add/remove operational areas. For example:

Expectations regarding how this alternative will impact operations are scored below. This list is an example, and will not apply to all projects. The operational areas must be distinct to avoid harmful correlation.>>

Alternative 1 - Operational Benefits/Impacts

Operational Area Score1 Rationale Mission/business function Interoperability Customer/User benefit Efficiency Info Assurance/Security

Reliability/ Quality

Sustainability Other

Total Score:

NOTE 1: Scores range from -5 to +5. Negative scores of -4 or -5 are red; high positive impact scores of +4 or +5 are green.

3.2.6 Risk Summary

<<Use narrative to summarize risks. Identify risk management actions and evaluate risk before and after risk management to determine which strategies are likely to have the most impact. Identify costs associated with risk management actions. Include any risks associated with assumptions. For example:

This alternative has been evaluated to be [high, medium, low] risk. Areas of greatest risk were [list and explain]. Areas of lowest risk were [list and explain]. If actions are taken to [describe risk management actions], it is believed that risk related to [risk factor name] [could or could not] be reduced to an acceptable level because [explain]. >>

Risk Factor

Pre-Risk Mgmt Analysis Risk Management Strategy

Post- Risk Mgmt Analysis

1.

Probability

Impact

3 Areas Impacted

1.

Probability

2.

Impact

3. Areas Impacted

Insufficient Budget

Certain Catastro phic

C Divide system into mandatory and desirable features and only implement mandatory features

Possible Mod C

Requirement Change

Possible Mod C, P, T, S, R

Lock down technical requirements for spiral one on XX date

Possible Mod C,P,S,R

Dependency on XXX

Possible High S, R, C Focus on aspects of project that do not depend on system xxx

Possible Mod C, S

[Notional Risk Analysis & Management Examples]

Risk Table Legend

1. Probability 2. Impact 3. Areas of Impact

70-100% Certain Project failure Catastrophic (Cat) Business: Programmatic (P)

40-69% Probable Failure to meet major requirements, major cost increase or schedule delay

High IT System: Technical (T)

5-39% Possible Extensive adjustments needed to meet schedule Moderate (Mod) Delays & Slippages:

Schedule (S)

Near 0% Improbable Minor adjustments needed to meet goals Low Staff & Equipment: Resources (R)

Funding Shortfall: Cost (C)

3.3 [Short Descriptive Name of Alternative 2] Overview <<Identify and describe the Alternative 2. Give it a short name and summarize what it is, what it includes, and how it differs from the other alternatives. If relevant, expand upon the reasons stated above for selecting this alternative for consideration.>>

3.3.1 Cost and Economic Viability

<< Clearly state key cost/economic information for the alternative being discussed. For example:

The total cost of this alternative is [state cost and timeframe]. It includes Direct, Indirect, and G&A costs for [explain materiel and non-materiel costs included]. Estimates are [explain: confidence in estimates; whether they represent high, medium, or low values; sensitivity (see definition)].>>

[Notional Data]

<< If the cost element structure in Appendix B is known, then the DME row in this table will equal the As- Is Investment row from the structure in Appendix B. In the write-up, articulate the appropriations included in the ‘Other’ rows of this table. It is acceptable to include extra rows for additional appropriations vice summing to ‘other.>>

<<Calculate the difference between the Status Quo and the Alternative to estimate the cost delta between the two Alternatives. Negative #’s will show additional cost and positive # will show cost benefit. >>

Resource Type (DME/O&S)

Appropriation

DME 2 2 2 0 0 0 0 6

RDT&E

Procurement

O&M

Other

O&S 4 4 4 4 4 4 4 28

RDT&E

Procurement

O&M

Other

TOTAL $6 $6 $6 $4 $4 $4 $4 $34

To Complete

LCCE

DME = Development, Modernization, or Enhancement

O&S = Operations and Sustainment

Alternative 2 Life Cycle Costs (dollars in mill ions)

Prior FY15 FY16 FY17 FY18 FY19 FY20 FY21

[Notional Data]

<<Apply discounting and economic analysis formulas per guidance in Appendix G to develop Economic Viability metrics.>>

Alternative 2 - Economic Viability

Net Present Value

(NPV) =

Break Even (Discounted) =

Benefit Cost Ratio

(BCR) =

Return on Investment

(ROI) =

3.3.2 Requirements Summary

<< Provide a summary for the alternative discussed. For example:

This alternative satisfies [all, most, some] known requirements. Its greatest strengths are in [explain what they are and why they are important]. Its greatest limitations are [explain what they are and why they are an issue]. Expectations regarding how well this alternative is expected to satisfy each requirement have been scored and provided in the table below.>>

<<The table below, should include the key requirements>>

<< Scores and Weights should be developed through a collaborative process with stakeholders and documented in this section. Sum of weights should = 100%.>>

Alternative # 2: Requirements Satisfaction

Requirement Score

(0 to 5)1 Weight2 Weighted

Score3 Rationale

[Describe requirement]

[Describe requirement]

Total Score4

1. Score range is: 0 (does not meet requirement), 1 (minimally meets requirement) to 5 (greatly exceeds requirement).

2. Weighting factor for high priority requirements

3. Weighted score = “score” multiplied by “weight factor”

4. The unweighted and weighted scores are summed to establish the total score

3.3.3 Qualitative Benefits

<<Clearly state the nature of any operational impacts the alternative under discussion presents.>> For example:

This alternative had [significant, moderate, minimal, no] negative operational impacts in the areas of [list], and [significant, moderate, minimal, no] positive benefits in the areas of [list].

Resource Type (DME/O&S)

Appropriation

DME 2 2 2 0 0 0 0 6

RDT&E

Procurement

O&M

Other

O&S 4 4 4 4 4 4 4 28

RDT&E

Procurement

O&M

Other

TOTAL $6 $6 $6 $4 $4 $4 $4 $34

To Complete

LCCE

DME = Development, Modernization, or Enhancement

O&S = Operations and Sustainment

Alternative 1 (Baseline) Life Cycle Costs minus Alternative 2 Life Cycle Costs (dollars in mill ions)

Prior FY15 FY16 FY17 FY18 FY19 FY20 FY21

Table will display mathtical deltas between Alternative 1 (Baseline) and Alternative 2

<< Expand on significant issues, areas of concern and/or strengths and how they are likely to affect the success of the project. The table below may be tailored to add/remove operational areas. For example:

Expectations regarding how this alternative will impact operations are scored below. This list is an example, and will not apply to all projects. The operational areas must be distinct to avoid harmful correlation.>>

Alternative 2 - Operational Benefits/Impacts

Operational Area Score1 Rationale Mission/business function Interoperability Customer/User benefit Efficiency Info Assurance/Security

Reliability/ Quality

Sustainability Other

Total Score:

NOTE 1: Scores range from -5 to +5. Negative scores of -4 or -5 are red; high positive impact scores of +4 or +5 are green.

3.3.6 Risk Summary

<<Use narrative to summarize risks. Identify risk management actions and evaluate risk before and after risk management to determine which strategies are likely to have the most impact. Identify costs associated with risk management actions. Include any risks associated with assumptions. For example:

This alternative has been evaluated to be [high, medium, low] risk. Areas of greatest risk were [list and explain]. Areas of lowest risk were [list and explain]. If actions are taken to [describe risk management actions], it is believed that risk related to [risk factor name] [could or could not] be reduced to an acceptable level because [explain]. >>

Risk

Factor

Pre-Risk Mgmt Analysis Risk Management Strategy

Post- Risk Mgmt Analysis 1.

Probability

Impact 3 Areas Impacted

1.

Probability

2.

Impact

3. Areas Impacted

Insufficient Budget

Certain Catastro phic

C Divide system into mandatory and desirable features and only implement mandatory features

Possible Mod C

Requirement Change

Possible Mod C, P, T, S, R

Lock down technical requirements for spiral one on XX date

Possible Mod C,P, S, R

Dependency on XXX

Possible High S, R, C Focus on aspects of project that do not depend on system xxx

Possible Mod C, S

[Notional Risk Analysis & Management Examples]

Risk Table Legend

4. Probability 5. Impact 6. Areas of Impact

70-100% Certain Project failure Catastrophic (Cat) Business: Programmatic (P)

40-69% Probable Failure to meet major requirements, major cost increase or schedule delay

High IT System: Technical (T)

5-39% Possible Extensive adjustments needed to meet schedule Moderate (Mod) Delays & Slippages:

Schedule (S)

Near 0% Improbable Minor adjustments needed to meet goals Low Staff & Equipment: Resources (R)

Funding Shortfall: Cost (C)

3.4 <Short Descriptive Name of Third Alternative> Overview << For other alternatives, follow the same structure as above. >>

4.0 COMPARISON OF ALTERNATIVES

4.1 Comparison of Alternatives’ Economic Viability Measures

<<Identify the alternative(s) with the best viability. Assess overall economic viability and provide rationale, taking into consideration: (1) degree of confidence in financial assumptions and estimates, (2) sensitivity of the data, and (3) economic realities such as availability of funds. For example:

The most economically viable alternative is [alternative number and short name]. Its overall economic viability is assessed as [strong, moderate, weak, not viable] based on [explain].

<<If only one alternative is being considered, there will only be one set of economic viability measures..>>

Alternative Economic Viability Comparison Most

Viable

Alternative 2 NPV = Discounted Payback Pd = BCR = ROI =

Alternative 3 NPV = Discounted Payback Pd = BCR = ROI =

4.2 Comparison of Costs and Savings

<<Identify the alternative that requires the lowest overall life cycle costs (investment & O&S). For example:

Of the [number of] alternatives considered, Alternative [number and short name] requires the lowest overall life cycle costs. >>

<<Provide the amounts listed in the ‘Total’ line for each alternative (Sections 3.2.1, 3.3.1, etc.)>>

<<Explain the relationship between lifecycle costs and net cost increase or savings. For example:

Taking into consideration the overall lifecycle costs required and the net cost increases/savings of each alternative, Alternative [number] is most feasible from a funding availability standpoint and provides a [strong, moderate, or weak] financial benefit and return. If this option is implemented, status quo costs can be reduced by [explain assumptions, amounts, and timeframes] and realigned to help fund the alternative. Additionally, other savings not directly related to the cost of this alternative from [explain other savings if applicable] can be applied to help offset the total cost. >>

Red=budget/cost increase; black = budget decrease (savings)

4.3 Comparison of Overall Requirements Satisfaction

<< Compare how each alternative satisfies each requirement. Identify the alternative that best meets overall requirements. Document all methodologies used to make the determinations. For example:

Prior FY15 FY16 FY17 FY18 FY19 FY20 FY21 To

Complete

LCCE

Lowest

LCC$

Alternative 1 $_ $_ $_ $_ $_ $_ $_ $_

Alternative 2

Alternative 3

Life Cycle Cost Comparison (dollars in mill ions)

In millions Prior FY15 FY16 FY17 FY18 FY19 FY20 FY21 To

Complete

LCCE

Greatest Savings

Alternative 2 $/$ $/$ $/$ $/$ $/$ $/$ $/$ $/$ $/$ $/$

Alternative 3 $/$ $/$ $/$ $/$ $/$ $/$ $/$ $/$ $/$ $/$

Net Cost Increase or Savings (dollars in millions)

The [alternative number and name] most fully satisfies the statutory, functional, and technical requirements specified for this project. Comparative results are provided below.>>

Requirements Comparison

Requirement As Is/Alt 1 Alt 2 Alt 3 Alt 4

[Describe requirement]

[Describe requirement]

Total Score

Best

4.4 Comparison of Mission and Operational Benefits/Impacts

<<Identify the alternative that has the highest weighted operational score. For example:

[Alternative number and name] has the highest weighted operational score, particularly in the areas of [list areas]. Comparative results are provided below.>>

Operational Benefits/Impacts If Implemented (or not Implemented)

Operational Area Unweighted Scores Weighted Scores

As Is/Alt 1 Alt. 2 Alt. 3 Alt.4 As Is/Alt

Alt.2 Alt. 3 Alt. 4

Mission/business function

Interoperability

Customer/User benefit

Efficiency

Info Assurance/Security

Reliability/ Quality

Sustainability

Other

Total Scores

Best

4.5 Risk Comparisons

<<Identify which alternative offers the lowest risk and which offers the highest risk, and whether risks identified are considered acceptable or not acceptable after risk management efforts. For example:

Post-risk management, [Alternative number and name] appears to have the lowest risk and [Alternative number and name] appears to have the highest risk. Considering the types of risks, their possible impacts and probability of occurring, the risks for [Alternate with lowest risk] after risk management actions are considered [acceptable or not acceptable]. Considering the types of risks, their possible impacts and probability of occurring, the risks for [Alternate with highest risk] after risk management actions are considered [acceptable or not acceptable]. The risk cubes below summarize the risk profiles for each alternative after risk management actions.>>

<< The following risk cubes should be used, and tailored as appropriate.>>

Alternative 1 Alternative 2 Alternative 3

(Cat = catastrophic) [Examples here are notional.]

Risk Cube Legend

Probability Impact Areas of Impact

70-100% Certain Project failure Catastrophic (Cat) Business Programmatic (P)

40-69% Probable Failure to meet major requirements, major cost increase or schedule delay

High IT system Technical (T)

5-39% Possible Extensive adjustments needed to meet schedule

Moderate (Mod) Delays & Slippages

Schedule (S)

Near 0% Improbable Minor adjustments needed to meet goals

Low Staff & Equipment

Resources (R)

Funding shortfall

Cost (C)

Contract Issues

Business & Secuirty (V)

4.6 Sensitivity Analysis (Optional)

<<The primary objective of Sensitivity Analysis is to determine whether the cost ranking of the alternatives change as a result of varying certain factors. Its value lies in the additional information and understanding it brings to bear on the decision. For decision makers facing an investment decision, sensitivity analysis is a tool for determining how changes in costs or benefits affect the recommendation. Sensitivity Analysis reveals how the cost estimate is affected by a change in a single assumption. It examines the effect of changing one assumption or cost driver at a time while holding all other variables constant. By doing so, it is easier to understand which variable most affects the cost estimate. Consult references in Appendix H for assistance with conducting sensitivity analysis.>>

4.7 Other Considerations

<< Optional. Explain any other information not previously addressed that should be considered when making a selection recommendation.>>

Alt 1 Probability Improb‐ able

Possible Probable Certain

Im p ac t

C at

H ig

C, S, P, T

C

M e C

Lo w

Alt 2 Probability Improb‐ able

Possible Probable Certain

Im p ac t

C at

H ig C, R C

M e P S

S, T

Alt 3 Probability Improb‐ able

Possible Probable Certain

Im p ac t

C at S C

H ig R C R

M e S

5.0 CONCLUSIONS AND RECOMMENDATIONS

5.1 Summary Comparison and Recommendation

<<Identify the alternative found to be the best option, discuss merits of each alternative and rational for recommended alternative, with summary rationale data. For example:

After performing an analysis of the financial and non-financial benefits and risks of various alternatives, [alternative number and name] is assessed to be the most viable option. It generates the greatest savings [note amount and timeframe], fully satisfies all requirements, provides the greatest operational benefits/impacts, and involves risks that, once managed, are considered acceptable.

The following example table summarizes and compares the alternatives across financial and non-financial dimensions.>>

5.2 Funding Needs and Sources

<<Identify the total funding required for the recommended alternative. For example:

The table below identifies the total funding required for the recommended alternative as presented in the alternatives “Cost” section. It includes costs for materiel [list] and non-materiel [list] requirements.

<<If deltas exist between the ‘Total Requirement’ and amounts currently programmed/budgeted, identify all off-sets required to fully fund the alternative. Provide additional off-set details in Appendix D.>>

<<If additional funding is required, explain logical funding sources based on expected cost savings/avoidance. As necessary, provide additional detail re: reprogramming actions in Appendix D. For example:

This project is expected to generate cost avoidance in the amount of [amount and timeframe] from [describe the efficiency that creates the cost avoidance]. To cover the remaining unfunded costs, funding equal to the cost avoidance could be recouped through budget marks against [state logical source (provide APPN, BA, PE, BLI, and UII)]. If this is done, the final net unfunded amount for this initiative would be [state amount].>>

Alternative 1 (As-Is)

N/A N/A N/A N/A N/A N/A

Alternative 2

Alternative 3

Best Option

Non-Financial

NPV

Cost

(FY15-21)

$M

Overall Comparison of

Alternatives BCR ROI Unfunded

(FY15-21)

$M

Savings

(FY15-21)

$M

Requirements (Exceeds, Meets, Not Acceptable)

Break Even

Operational Benefits

(Significant, Moderate, Low, None)

Managed Risk (Low, Med, High, Financial

NOTE: Investment (Invest.)” reflects all one-time/non-recurring costs, regardless of appropriation expected to be incurred to implement the preferred alternative. Consists of sustainment costs incurred from the initial system deployment through the end of system operations. Includes all costs of operating, maintaining, and supporting a fielded system. Specifically, this consists of the costs (organic and contractor) of personnel, equipment, supplies, software, and services associated with operating, modifying, maintaining, supplying, and otherwise supporting a system in the DoD inventory.

Prior FY15 FY16 FY17 FY18 FY19 FY20 FY21 To

Complete

LCC

Total Required

RDT&E

Procurement

O&M

Other

Currently Programmed/Budgeted

RDT&E

Procurement

O&M

Other

Unfunded Requirements (UFR)

RDT&E

Procurement

O&M

Other

Off-sets from Reprogramming

RDT&E

Procurement

O&M

Other

Off-sets from POM/PBR

RDT&E

Procurement

O&M

Other

Off-sets from Cost Savings/Avoidance

RDT&E

Procurement

O&M

Other

Final NET Unfunded

RDT&E

Procurement

O&M

Other

Funding Required/Available (dollars in millions)

PBR ‐ DoD Program and Budget Review

POM ‐ Component Program Objectives Memorandum

Net Unfundedwill display mathtical deltas between 'Total Requirement' and 'Currently Programmed/Budgeted'

Final NET Unfundedwill display mathtical deltas between 'NET Unfunded' and 'Off‐sets'

Off‐Sets from Reprogrammingcan only correct execution year UFRs.

APPENDIX A: GLOSSARY

<<These definitions may be augmented/changed as needed to support a particular BCA.>>

Term Description

Analysis of Alternatives

Evaluation of different choices available for achieving an objective, usually requiring a cost benefit analysis, life cycle costing and sensitivity analysis.

Assumption An assumption is an informed position about what is believed to be true for a situation where explicit factual knowledge is unobtainable.

Baseline A description of the beginning condition in measureable terms and a start date from which progress can be measured. Synonymous with As Is and Status Quo.

Benefit-Cost Ratio

(BCR)

BCR is the index resulting from dividing discounted benefits (savings/cost avoidances) by discounted investment. Therefore, an initiative must have a BCR > 1.0 to be considered financially viable.

Break Even (B-E) The fiscal year in which the initiative “breaks-even” based on discounted cash flows, i.e., the point at which the Net Present Value (NPV) becomes positive.

Business Case A comparative analysis that presents facts and supporting details among competing alternatives.