12.5. Tools and Methods
12.5.1. Business Case
The Business Case is a summarization of the Doctrine, Organization, Training, Materiel, Leadership and education, Personnel, Facilities, and Policy (DOTMLPF-P) solution performed for a point in time. It is a brief, high-level document, with input from the Functional Sponsor and program manager, which outlines the program/increment and typically does not provide the detail data that the program office produces.
The principal purposes of the Business Case are to:
- Facilitate a way of thinking that causes Components to consider a business capability's value, risk and relative priority as fundamental elements of submission;
- Require those proposing a solution to justify its value and to self-eliminate any proposals that are not of demonstrable value;
- Enable DoD leadership to rapidly determine if a concept or proposed solution is of value to the enterprise and is achievable compared to the relative merits of alternative proposals; and
- Enable DoD leadership to objectively measure the subsequent achievement of the capability's benefits.
The Business Case provides a compelling, defendable and credible justification for the DOTMLPF-P solution to the defined problem, with corresponding outcomes and performance measures for use throughout the capability's lifecycle. It is an evolving document, with the intent of providing an overview of the current program status in a condensed format. It is structured to best support the program and does not have a mandatory format, but it must cover all of the statutory and regulatory information requirements.
Supporting the Business Case is program documentation. This documentation is what the Component feels is necessary to successfully implement the capability. Each Component has approval processes for documentation and normally does not require Office of the Secretary of Defense (OSD) approval (the DoDI 5000.02 directs the Heads of the DoD Components to keep the issuance of any additional guidance necessary to implement the mandatory procedures to a minimum). Programs still need to make this documentation available to oversight bodies: It just does not require their approval. In select cases, the applicable office with statutory authority (e.g., DASD(DT), DOT&E, etc...) sign-off on the appropriate section of the Business Case to agree that the program plans are adequately addressed.
The Business Case provides a template to ensure that a problem, its root cause and DOTMLPF-P issues are thoroughly analyzed; that all options have been considered; that risks are identified; risk mitigation plans are sufficient; and that there is a high degree of confidence the expenditure of resources and funds are justified and value-added. It provides leadership with sufficient information to make informed investment decisions within the context of enterprise priorities and available resources. Components are responsible for the development and maintenance of the Business Case.
12.5.1.1. Content Updates
In coordination with the Functional Sponsor, the Component Acquisition Executive (CAE), and the Investment Review Board (IRB), the program manager (PM) must review and, when necessary, update the Business Case to incorporate any changes driven by an increment to ensure that:
- The problem to be solved remains valid;
- The selected solution is still appropriate to achieve the desired outcomes;
- The materiel solution can continue to be executed within the established cost, schedule and performance parameters; and
- The expected benefits will be realized.
Additionally, the PM must update and/or revise the Business Case if changes occur to the problem scope, context or the requirements for additional modernization funding.
For follow-on increments, it is recommended that an "addendum" be added to the existing Business Case to preserve all program-level information, to reduce rewrites, and to show history and continuity of the program.
If the Business Case is deemed no longer valid, but the capability is still needed, the Functional Sponsor, along with the CAE, must notify the IRB and the MDA immediately to determine how to proceed. If the Business Case is deemed no longer valid and the capability no longer needed, the Functional Sponsor, along with the CAE, must immediately notify the IRB and the Milestone Decision Authority (MDA) of their intention to discontinue the program.
12.5.1.2. General Guidance
- The Business Case is not a technical proposal, though it will contain technical information.
- Utilize tables to summarize information as much as logically possible.
- Up front, explain the decision or action being sought (i.e., seeking a MS A decision in order to do X, Y, and Z.).
- Do not write the Executive Summary until the rest of the content is finished. The Executive Summary should be updated each time a decision is being sought (note: after the first Executive Summary is written, it may only require cursory updates in the future).
- The Executive Summary should be concise and focused on the issue at hand. Do not discuss "general knowledge" data or information (such as, the history of ERPs in the Department, the largesse of the DoD, the challenges of the DoD IT environment, easily "Google-able" information, etc.).
- Clarify between usage of increments or releases, what operational business capability will be delivered in a specific increment or release, and how each works toward achieving the overall outcome from a measures perspective (is it 25% of the overall capability?)
- Measures should not focus on compliance - rather, what compliance will a Law, Regulation, Policy enable (i.e., compliance with SFIS requirements will enable ______.) or conversely, if required compliance with an L, R, or P introduces risk or additional requirements.
- As a general guideline, the complete Problem Statement analysis section for a (projected) MAIS solution should be less than 7 pages in total length and, depending on the number of alternatives considered, the total Business Case may vary from 15 to 40 pages.
- A Problem Statement should never be more than 3-4 sentences in length.
- The Business Case will always be judged on the quality of information it contains, not on the length of the content.
12.5.1.3. Evaluation
A Business Case will be evaluated to ensure:
- The investment has value to the enterprise and aligns with enterprise priorities;
- A materiel solution has not been selected too early in the process, and evidence that robust analysis has been conducted;
- Proper management and support of senior officials for the proposed solution;
- Definition of the scope for the proposed solution and measurable desired outcomes;
- Clear evidence that BPR has been done or is being completed;
- Ability of the Component to deliver the benefits; and
- Dedicated resources are working on the highest value opportunities.
12.5.2. DOTMLPF-P Analysis
Doctrine, Organization, Training, Materiel, Leadership and education, Personnel, Facilities, and Policy (DOTMLPF-P) is an analytical approach and method for defining the operational context of a perceived problem. There are many options for how to approach a DOTMLPF-P analysis; however, it may be valuable to establish an internal or DoD Component standard. A valuable reference are the JCIDS materials.
Doctrine.
- Is there existing doctrine that addresses or relates to the business need? Is it Joint? Service? Agency?
- Are there operating procedures in place that are NOT being followed which contribute to the identified need?
- If no doctrine is in place which pertains to the defined need, does new doctrine need to be developed and implemented that will provide a total or partial solution to the need?
Organization.
- Where is the problem occurring? What organizations is the problem occurring in?
- What are the primary and secondary mission / management focus of those organizations?
- What are the organizational values and priorities?
- Is the organization properly staffed and funded to deal with the issue?
- Are commanding officers / senior management aware of the issues?
- Is the issue already in some type of organizational issue list?
- If so, why isn't the issue being resolved?
- Who exactly is aware of / being impacted by the issue?
Training.
- Is the issue caused, at least in part, by a complete lack of or inadequate training?
- Does training exist which addresses the issue?
- Is the training being delivered effectively?
- How are training results being measured and monitored?
- Is the issue caused by a lack of competency or proficiency on existing systems and equipment?
- Was the issue discovered in an exercise or during training?
- Do personnel affected by the issue have access to training?
- Is the training effort supported by leadership?
- Is training properly staffed and funded?
Materiel.
- Is the issue caused, at least in part, by inadequate systems or equipment?
- What legacy systems exist where the problem is occurring?
- What functionality would a new system provide that currently does not exist?
- What increases in operational performance are needed to resolve the issue?
- Is the issue caused by a lack of competency or proficiency on existing systems and equipment?
- Can increases in performance be achieved without development of a new system?
- Who would be the primary and secondary users of the proposed systems or equipment?
- Is interoperability either a driver or barrier in issue resolution?
Leadership and education.
- Is the issue caused, at least in part, by inability or decreased ability to cooperate/coordinate / communicate with external organizations?
- Does leadership understand the scope of the problem?
- Does leadership have resources at its disposal to correct the issue?
- Has leadership been trained on effective change management principles?
- Has leadership properly assessed the level of criticality, threat, urgency, risk, etc. of the operational impact(s) of the issue?
- Is leadership aware of the drivers and barriers to resolving the issue within her / his own organization?
- Has leadership identified inter-service / agency cultural drivers and barriers which hinder issue resolution?
Personnel.
- Is the issue caused, at least in part, by inability or decreased ability to place qualified and trained personnel in the correct occupational specialties?
- If issue resolution is likely to involve new materiel, systems, or equipment, are different occupational specialty codes needed to properly staff new systems?
- Do new personnel have support to onboard to their jobs?
- Are the right personnel in the right positions (skill set match)?
Facilities.
- Is the problem caused, at least in part, by inadequate infrastructure?
- Is physical distance of equipment, etc. leading to other problems?
- Are there proper environmental controls?
- Is there a lack of operations and maintenance?
Policy.
- Is there existing policy that addresses or relates to the business need? Is it Joint? Service? Agency?
- If no policy exists which pertains to the defined need, does new policy need be developed and implemented that will provide a total or partial solution to the need?
- Can policy be developed and signed at the Component level? Will policy require OSD-level sponsorship, coordination and / or signature?
12.5.3. Outcomes and Measures Development
Outcomes and measures development begins during the Business Capability Definition Phase (BCD), helping to scope the effort and identify outcomes that will be used at a future point for testing. During subsequent Business Capability Lifecycle (BCL) activities, outcomes and measures are refined and the Functional Sponsor works closely with the acquisition and testing communities in order to ensure the information is appropriate and relevant to the program at applicable lifecycle points.
The outcome should explicitly state the business value of the resources to be invested and to allow management to prioritize and weigh investments. The outcome provides strategic alignment and clear criterion against which to evaluate potential approaches. It always starts with the desired functional result and is used to focus behaviors and results by answering the "what's in it for me?" question. Corresponding measures must be specific, actionable, measureable, relevant, and timely operational capabilities that can be achieved against their corresponding outcomes.
Figure 12.5.3.F1 depicts a logical manner of thought in which a process can be decomposed into goals, and finally into metrics and / or measures:
Figure 12.5.3.F1 - Developing Measures and Metrics
Correspondingly, Figure 12.5.3.F2 portrays an example hierarchy of outcomes and metrics / measures in BCL. They decompose from a strategic level to an execution (operational) level of specificity.
Figure 12.5.3.F2 - Outcome Hierarchy
High-Level Outcomes (HLOs). HLOs are developed during BCD as part of the "To-Be" Analysis, support one or more Strategic Management Plan (SMP) goals/objectives, and constrain business outcomes. They address the strategic alignment principle - programs must enable effective portfolio management by aligning individual investments to SMP goals and objectives - that is central to BCL.
HLO measures are developed at the same strategic level as HLOs. They define measurements for strategic purpose and priority and address how the investment will meet enterprise-level expectations in finite terms.
Business Outcomes. Business outcomes are developed during BCD when the "To-Be" Analysis is refined as a result of BPR. Business outcomes should align to specific end-to-end (E2E) business processes defined in the Business Enterprise Architecture (BEA) and describe the functional user's intended result of fulfilling an identified business capability gap. They are the HLOs decomposed into observable and measureable business results or changes in business performance.
Business outcome measures, like HLO measures, should address how the investment will meet enterprise-level expectations. They should also add increasing level of detail to determine how the investment will meet the business results outlined in the business outcomes.
Program Outcomes. Program outcomes support business outcomes and are developed during IM based on the preferred solution. Program outcomes are scoped to the preferred solution and should include specific business rules that explicitly define the "To-Be" state and should address expectations of how the preferred solution will address business outcomes and HLOs.
Program outcome measures must demonstrate the value of the preferred solution to the Department and should provide cost and period of performance expectations for each business capability to be delivered as part of the preferred solution, taking into account the Better Buying Power affordability target.
System Requirements. System requirements fulfill program outcomes and are developed throughout Execution as the chosen solution is built and realized against the HLOs and capability levels are added; they represent the capability delivery aspects of a chosen solution.
|
TIP: System-level requirements are generally NOT included in the Business Case; but are critical for the operation of the program.
|
System requirements measures, like their outcomes counterparts, gain increasing level of detail as a chosen solution matures through building, testing, and deployment.
- During Prototyping, system requirements address solution design and program plan tracking and are tied to a work breakdown structure and schedule.
- During Engineering Development, system requirements address developing the solution by executing the plan, include development testing results, and should join the cost, schedule, and performance measures of program realization to support a MS C decision.
- During Limited Fielding, system requirements should include technical quality criteria and cost, schedule, and performance measures. They should focus on displaying added detail to support end-user testing and the results of initial operational test and evaluation (IOT&E) to support initial operating capability (IOC) and a Full Deployment Decision (FDD).
- During Full Deployment, system requirements should reflect program execution details and sustainment activities (help desk, operations) to coincide with transitioning from execution to O&S.
DAG Tutorial 
