12.1. Business Capability Definition (BCD) Phase
12.1.1. Purpose, Outputs, and Outcomes
The purpose of the Business Capability Definition (BCD) Phase is, upon the identification of a problem, need or gap, to analyze it, understand it, and scope it.
The outputs and outcomes of the BCD Phase are:
- The outcome is a thorough understanding of the problem, need or gap at a root cause level and the successful identification of the desired outcome (or, "what good looks like" when the problem is eventually solved);
- Completion of a clearly-defined and scoped Problem Statement; and
- Informed decision-makers at the Component and Office of the Secretary of Defense (OSD) levels.
12.1.2. BCD Phase Process
Figure 12.1.2.F1 - BCD Phase High Level Process Flow
The Business Capability Definition Phase (BCD) Phase begins with identification of a business need (note: it can also be considered a problem, symptom, gap, opportunity or myriad other things, but in the Business Capability Lifecycle (BCL) and throughout this Chapter it is referred to as a "problem" or "business need"). Multiple activities occur in this phase, including clearly defining the problem and its root cause(s); conducting an "As-Is" and "To-Be" Doctrine, Organization, Training, Materiel, Leadership and education, Personnel, Facilities and Policy (DOTMLPF-P) Analysis; conducting high-level Business Process Re-engineering (BPR) through the Functional Sponsor's assessment of the desired outcomes; proposing a solution mix (either solely non-materiel, or a mix of materiel and non-materiel); and defining / validating High-Level Outcomes (HLOs) and measures that scope it. These activities result in a Problem Statement, the main output of the BCD Phase.
Once the Component has approved the Problem Statement, the Functional Sponsor will forward it to the Investment Review Board (IRB) for review and IRB Chair approval. If approved, the IRB Chair will subsequently direct the development of Analysis of Alternatives (AoA) Study Guidance to allow the Component to develop an AoA Study Plan for approved Problem Statements that contain a materiel component.
|
TIP: It is critical that functional users, who not only have an understanding of the problem but are also invested in its outcome, are involved in BCD Phase analysis to ensure the problem is well-understood and outcomes are developed correctly from the outset.
|
12.1.3. BCD Phase Activities
In the Business Capability Lifecycle (BCL), the Business Capability Definition Phase (BCD) Phase consists of rigorous analysis activities, the output of which is the Problem Statement (sections 1-3 of the Business Case Template, available on the Office of the Deputy Chief Management Officer (DCMO)'s BCL webpage). The final Problem Statement can be developed either step-by-step as BCD Phase analysis activities are completed or after all analysis has been completed. The activities involved in developing the Problem Statement are depicted in Figure 12.1.3.F1.
Figure 12.1.3.F1 - Decomposition of "Develop Problem Statement" Process Step
|
TIP: When conducting the BCD Phase analysis, consider the following questions:
- What is the problem?
- Who is affected by the problem?
- When does the problem occur, and how often?
- What is the root cause(s) of the problem?
- What is the business value of solving the problem?
- How will we know when the problem has been solved?
|
12.1.3.1. "As-Is" Analysis
During Business Capability Definition (BCD) Phase "As-Is" Analysis, users / functional experts take the problem that has been identified, put it into appropriate context (organizational, environmental, etc.) and conduct both a Root Cause and Doctrine, Organization, Training, Materiel, Leadership and education, Personnel, Facilities and Policy (DOTMLPF-P) Analysis (or, a DOTMLPF-P Constraints Assessment).
Determine Problem to be Solved. The purpose of this activity is to analyze a business need (whether an actual need, or a perceived need) that has been identified by a user in an organization.
The business need is analyzed by users and functional subject matter experts (SME) who understand the business processes and environment in which the business need exists. This analysis results in a concise definition of the problem.
Figure 12.1.3.1.F1 - Determine Problem to be Solved Context
The analysis must take into consideration the functional scope and organizational span of the problem - who is affected by it and where (i.e., Component-only or Enterprise-wide). It also includes describing the problem in further detail and providing context and boundaries (i.e., functional scope and organizational span), which expresses the problem in a manner that is specific, testable, and quantitative in nature.
It is important to bound this analysis to ensure it does not reach into the territory of specific, potential solutions ("a system will fix this" or "an Oracle ERP is the answer") and focuses simply on defining the problem.
The following is a summary of the Determine Problem to be Solved activity along with an example:
- Inputs. Symptom, capability gap, opportunity, etc. (problem / business need).
- Process. User(s) in DoD identify a problem or business need and refer it to the decision-maker (i.e., the Functional Sponsor) whose responsibility it is to investigate the business need and determine if development of a Problem Statement is warranted. The Functional Sponsor then engages participants to analyze the business need and identify the underlying problem to be solved. They determine other characteristics of the problem including a problem description, the context of the problem, and the boundaries of the problem.
- Outputs. The Problem; problem description, context, and boundaries.
Example. Security clearances.
- Someone in the DoD identifies what they believe to be a problem or business need and informs a leader within their organization.
User-identified problem. It takes too long to get a security clearance, which is adversely impacting an organization's ability to effectively operate. The Problem is reported up the chain, possibly by an HR Supervisor or the Security Manager of organization, to the Functional Sponsor.
- The Functional Sponsor directs a team to analyze the problem that was identified.
Analyze and Validate. The Problem: It takes too long to get a security clearance. Problem is decomposed and validated with anecdotes such as: The end-to-end processing of an initial top secret clearance took 311 days; GAO has reported concerns of the quality of investigative and adjudicative work in processing clearances; it is impossible for facility security officers to get clearance information in a timely manner.
- Team provides information to Functional Sponsor, including a more in-depth description, organizational / environmental context, and boundaries.
Problem Description, Context, and Boundaries. All Federal agencies requiring cleared staff are adversely impacted by the inability to deploy/redeploy staff in an efficient and timely manner. Clearance approvals are provided by multiple organizations utilizing various standards and procedures through use of cumbersome and disparate legacy data systems.
This information, which is intended to provide a better understanding of the problem, will feed Root Cause Analysis.
Root Cause Analysis. One of the issues the Department faces with successfully fielding information technology (IT) business capabilities is making the leap from problem to solution too quickly, resulting in a solution that doesn't meet the fundamental business need but rather provides temporary "band-aids" for its symptoms. The tendency to "do something now!" must be appropriately balanced with a process that mitigates the risk of fixing a symptom vs. its root cause(s). Within BCL, the expectation is that functional SMEs will analyze the problem to ensure complete understanding of its true or root causes.
Root Cause Analysis is a structured approach to determining a problem's causal factors and identifying what behaviors, actions, inactions, or conditions need to be changed in order to eliminate the problem.
Figure 12.1.3.1.F2 - Root Cause Analysis Context
|
TIP: There are many definitions of a "root cause". The United States Air Force Air War College defines a "root cause" as "the fundamental breakdown or failure of a process which, when resolved, prevents a recurrence of the problem".
(To view the following link, copy and paste it into your browser) http://www.au.af.mil/au/awc/awcgate/nasa/root_cause_analysis.pdf
|
There is no single methodology for performing Root Cause Analysis and various approaches (such as brainstorming, "5-Whys" analysis, and Cause and Effect [Fishbone] diagrams) can yield satisfactory results. A good option is to consult your Component's Lean Six Sigma point-of-contact for guidance.
For example, the "5-Whys" analysis starts by asking "why did the problem occur?" and then takes the answer and asks that same question of the answer. This question and answer cycle is repeated until you reach the fundamental process element that failed. Regardless of the methodology used, it is imperative that the Root Cause Analysis is thorough to ensure that resources are focused on the right item.
The following is a summary of the Root Cause Analysis activity along with an example:
- Inputs. The Problem; problem description, context, and boundaries.
- Process. Using SMEs, the Functional Sponsor will engage in decomposing the problem to drill down to its root causes, differentiate symptoms from the problem, and update the Problem Statement, if appropriate, based on findings.
- Outputs. A restated Problem (if appropriate), and a list of Root Causes.
Root Cause Analysis Example. Security clearances.
- If a team has not yet been formed, the Functional Sponsor at this point should establish a team to conduct Root Cause Analysis. SMEs may be involved at multiple levels of the security clearance process.
- The team examines the problem, context, and discovers what may be symptoms or root causes:
Results. Lack of reciprocity of clearances, delays in fulfilling agencies' missions and completing national security-related contracts, and increased costs of government.
- Based on expert judgment, the team analyzes the information to derive root causes apart from symptoms. Some of the root causes on security clearances were:
Root Causes. Data and processes are not standardized across agencies; there are difficulties obtaining information from some national, state and local record providers; and, not enough resources are available to handle the number of security clearance requests.
DOTMLPF-P Constraints Assessment, "As-Is" Analysis. This analysis presents functional SME insight into how existing process(es) work. Too often the Department has seen a problem jump to a materiel solution without a thorough assessment of whether or not the problem can be solved by modifying or eliminating a DOT_LPF-P constraint. The "As-Is" DOTMLPF-P Analysis may prevent this from happening by highlighting DOTMLPF-P constraints on the "As-Is" state.
Figure 12.1.3.1.F3 - DOTMLPF-P Constraints Assessment Context
These causal factors are referred to as "DOTMLPF-P constraints" and help determine whether the problem can be solved by eliminating DOT_LPF-P constraints. For example, "changing the Component-level policy will achieve the desired outcomes". It is important to understand the impacts and consequences of implementing non-materiel changes just as much as materiel changes - revising policy or enhancing training programs, for example, can have obvious benefits but may also add cost and risk that must be mitigated. It is highly likely that DOT_LPF-P factors or underlying business processes are contributing to the problem, and will in fact contribute to the solution.
Similar to Root Cause Analysis, there is no single methodology for conducting DOTMLPF-P analyses. However, methods for DOTMLPF-P are available in the DAG, JCIDS documents, as well as other DoD policy issuances, directives, instructions, regulations, and laws. Further direction on conducting a DOTMLPF-P analysis in the context of BCL is included in section 12.5.2, DOTMLPF-P Analysis.
|
TIP: It is possible that the solution can be entirely DOT_LPF-P, consisting of, for example, a combination of policy, Component-level guidance, BPR, and re-training solutions. Completing this analysis thoroughly may help determine that a materiel solution is not needed at all - or that the problem has many more factors that need to be solved (i.e., is more complex) than originally thought.
|
The following is a summary of the DOTMLPF-P Constraints Assessment, "As-Is" Analysis Activity along with an example:
- Inputs. The Problem (restated, if necessary) and list of root cause(s).
- Process. The Functional Sponsor / functional SME team assesses the "As-Is" state, considering each DOTMLPF-P element and analyzing the existing constraints that inhibit the ability to solve the problem or the business need. The team determines the DOTMLPF-P constraints and summarizes their assessment in the Business Case.
- Outputs. Identification of DOTMLPF-P Constraints in the "As-Is" state.
DOTMLPF-P Constraints Assessment Example. Following is an example summary output of a "As-Is" DOTMLPF-P Analysis (note: more detailed information does not need to appear in the Business Case, and may be kept as "working / program-level papers"):
Table 12.1.3.1.T1 - Example of High-Level Constraints from "As-Is" DOTMLPF-P Analysis
|
DOTMLPF Element
|
Constraint
|
|
Doctrine:
|
Operating procedures are not in-place. Creates disorganization, noncompliance, and non-standardization.
|
|
Organization:
|
Organization is not properly staffed to meet the agreed service level commitments. Adds time to process.
|
|
Training:
|
Personnel do not have access to training, and training programs differ between organizations.
|
|
Materiel:
|
The system does not collect the information required. Cannot share information properly between systems, creating stovepipes and rework.
|
|
Leadership and Education:
|
The command does not have the resources at its disposal to correct the identified issues.
|
|
Personnel:
|
Qualified and trained personnel are not readily available for the occupational specialties.
|
|
Facilities:
|
The call center is operating at capacity and cannot expand to accommodate the new services that are planned.
|
|
Policy:
|
No joint policy exists between organizations.
|
12.1.3.2. "To-Be" Analysis
The "To-Be" Analysis consists of the identification of High-Level Outcomes (HLOs) and measures, Business Process Re-engineering (BPR), and a "To-Be" Doctrine, Organization, Training, Materiel, Leadership and education, Personnel, Facilities, and Policy (DOTMLPF-P) Analysis.
Identify High-Level Outcomes (HLOs) and Measures. The Functional Sponsor (who represents the needs of the user[s] that originally identified the problem) is ultimately responsible for declaring whether the needed capability has been delivered. Therefore, measurable High-Level Outcomes (HLOs) must be identified up-front so all stakeholders know what constitutes success. Too often programs begin without a clear understanding of what the end-state should be and subsequently development (and corresponding costs) becomes endless.
Figure 12.1.3.2.F1 - Identify HLOs and Measures Context
HLOs and corresponding measures must be established to chart progress toward success and are an integral part of driving the "To-Be" process. HLOs also help scope the effort and align it with Department and Component goals and objectives. Their corresponding measures should be developed by taking into account benefits, risks, assumptions, and constraints. Later in the BCL process, different and more specific levels of measures will be used for outcome-based testing and determining whether the criteria for Initial Operating Capability (IOC) and Full Deployment have been met.
More information on the outcome development process that begins in the BCD Phase and extends throughout BCL can be found in section 12.5.3, Outcomes and Measures Development.
|
TIP: Major updates to a Business Case once it has been approved require review and re-approval by appropriate authorities, which may ultimately cause a delay in capability delivery. Therefore, it is imperative that the analysis of "what good looks like" is performed as thoroughly as possible, and HLOs and their associated measures provide a definitive baseline for testing during the Execution Phase. The Problem Statement, once approved, should not change.
|
The following is a summary of the Identify HLOs and Measures activity along with an example:
- Inputs. "As-Is" Analysis (the Problem; problem description, context, and boundaries; root causes; and DOTMLPF-P Constraints).
- Process. The Functional Sponsor will work with the functional team to capture the overall outcome ("what will be different when we're done?" or "what does good look like when we're done?"). Next, considering strategy, goals, and objectives (Department and Component), the Functional Sponsor will determine HLOs and corresponding measures, as well as associated benefits, risks, assumptions, constraints, and dependencies for each HLO.
- Outputs. HLOs (including associated measures, benefits, risks, assumptions, constraints, and dependencies).
Risk identification started during this activity begins a continuous process of risk management throughout the lifecycle of the program. This is a good point to establish a formal process of identifying, documenting, managing, and mitigating risks. An example of risk documentation is shown in section 12.2.3.2, Define Risks and Risk Mitigation, Table 12.2.3.2.T2.
HLOs and Measures Identification Example. Security clearances.
- The Functional Sponsor engages functional / SME team in determining what good would look like to them when the problem is solved, that is, what a HLO would be for the problem "The security clearance process takes too long":
HLO: Obtain security clearances in less time than it currently takes.
- The Functional Sponsor then identifies what strategic (Strategic Management Plan (SMP), Department, and / or Component) goal or objective that HLO supports:
Strategic linkage: Enhance the DoD Civilian Workforce (DoD SMP Business Goal #4).
- Based on the determined HLO, the Functional Sponsor works with the team to determine a quantitative metric for the success of the HLO:
- (metric) Days from application to clearance granted.
- (measure) Current: 444 days; Target: 60 days.
HLO's corresponding metric and measure:
Business Process Re-engineering (BPR). Driven by the HLOs, the Functional Sponsor leads BPR and analyzes existing business workflows and processes to determine what, from a process perspective, needs to change in order to achieve these outcomes. Items may include eliminating non-value added process steps, consolidating separate functional tasks into end-to-end cross-functional processes, and integrating business functions as much as possible to improve business operations and to achieve the desired outcome(s). BPR is a continuous process and requires a rethinking of why the "As-Is" process came to be and how it can be improved to achieve efficiencies.
Figure 12.1.3.2.F2 - BPR Context
BPR is initially conducted during the BCD Phase as a complement to DOTMLPF-P analysis and to prepare for conducting an AoA.
There must be an understanding of the "As-Is" processes for BPR to be effective so that defects and issues can be identified and eliminated in the eventual "To-Be" state. The ideal business process is defined during the initial BPR and specific, actionable business outcomes will be developed based on the HLOs and potential courses of action will emerge (more information on the outcome development process is located in section 12.5.3, Outcomes and Measures Development).
More information on BPR, see the Office of the Deputy Chief Management Officer (DCMO)'s BPR webpage.
|
TIP: Content in the Business Case's Problem Statement should not be replicated in a BPR Assessment Form. Refer to the original content through reference or hyperlink.
|
End-to-End (E2E) Process Alignment. For BCL, a primary input to conducting BPR is aligning HLOs to the Department's End-to-end (E2E) Business Process Flows, which are mapped to the Business Enterprise Architecture (BEA). Business outcomes and activities developed during initial BPR should align to an E2E Business Process and corresponding E2E Flows to show which E2Es will be affected if the "To-Be" state is realized.
The DoD has currently identified15 E2E Business Flows which represent a combination of mature, industry best practices and DoD-specific business functions. Each E2E Business Flow is a value chain that represents a set of integrated business functions that fulfill a need identified by the organization. E2Es are cross-functional, cutting across organizational boundaries. By streamlining business processes using an end-to-end approach, organizations can create consistent data models, eliminate data redundancies, eliminate the need for duplicate data entry, eliminate the need for manual reconciliations between DBS and reduce the total life-cycle costs of the organization's DBS.
The Functional Sponsor will identify which E2E(s) will be affected by matching HLOs and business outcomes to the E2E Flows. More information on the E2Es, including instructions on how to allocate Business Processes to Business Flows and document them in the Business Case can be found in section 12.5.4, BEA and BCL. Additional information and reference material are available on the DCMO's BEA webpage.
The following is a summary of the BPR activity along with an example:
- Inputs. "As-Is" Analysis (including: the Problem; problem description, context, and boundaries; root causes; and DOTMLPF-P Constraints); and HLOs (including measures, benefits, risks, assumptions, constraints, and dependencies).
- Process. The Functional Sponsor involves SMEs in business process analysis and BPR. The team proceeds to define the "To-Be" state by identifying new and modified business processes to address the Problem and achieve the "vision" defined by the HLOs. They consider both evolutionary (e.g., enhancements) and revolutionary (e.g., re-engineering) opportunities to define the future state. The team may elect use of modeling techniques to create a rigorous view of the "As-Is" state and "To-Be" state. An important asset at the disposal of the re-engineering team is the BEA, which includes a suite of business models derived out of E2E business flows. Leveraging the BEA through the E2Es, the team aligns, maps, and decomposes processes. Refer to section 12.5.4, BEA and BCL and the DCMO's BEA webpage.
The results of the BPR and the E2E alignment are summarized in the Business Case by showing the decomposition of the HLOs into subordinate business outcomes. The important characteristics of each business outcome are also defined - specifically measures, benefits, risks, assumptions, dependencies and constraints.
- Outputs. Re-engineered business process, BEA E2E alignment, and business outcomes (including measures, benefits, risks, assumptions, constraints, and dependencies).
BPR/E2E Alignment Example. Security clearances:
- Determine the business outcome(s) that support achieving each HLO applicable to the security clearances problem:
HLO: Streamline clearance process
Business Outcome: Establish a "Determinations Store"
Business Outcome Definition: Will provide Security Officers with a listing of security clearance determinations, eliminating the unnecessary processing of clearance applications for applicants with prior clearance investigations or adjudicative determinations
- Align the business outcomes to the BEA's E2E Business Process Flows and then drill-down to underlying Business Processes and Business Capabilities applicable to the security clearances problem:
Business Outcome: Establish a "Determinations Store"
BEA E2E Business Flow: Hire to Retire (H2R)
Business Process: Manage Human Resources Access Control Programs
Business Capability: Manage Personnel Security
DOTMLPF-P Impact Assessment, "To-Be" Analysis. Based on all previous activities and analyses, a DOTMLPF-P Impact Assessment is conducted in conjunction with BPR to determine the impact of a transition to the "To-Be" state. This helps to ensure that all elements of DOTMLPF-P are considered in order to avoid hidden impacts as much as possible, and to realize that it may take multiple DOTMLPF-P elements to solve the problem and achieve the HLOs.
Figure 12.1.3.2.F3 - DOTMLPF-P Impact Assessment Context
The "To-Be" state is unconstrained by tradeoffs or limitations of alternative solutions, since no specific alternatives have been analyzed (note: the Analysis of Alternatives (AoA) is conducted in the IM Phase, after a Materiel Development Decision (MDD) is granted). The results of "To-Be" Analysis are outcome-based and are critical in determining which DOTMLPF-P elements must be addressed to achieve the HLOs and business outcomes.
The following is a summary of the DOTMLPF-P Impact Assessment, "To-Be" Analysis activity along with an example:
- Inputs. Initial re-engineered business process, HLOs and business outcomes (including measures, benefits, risks, assumptions, constraints and dependencies), and BEA E2E Alignment.
- Process. The Functional Sponsor and the SME team consider the DOTMLPF-P elements that will be impacted in the transition to the "To-Be" state. A summary of the analysis is documented in the Problem Statement section of the Business Case, and includes a list of each DOTMLPF-P Impact (i.e., the actions or changes to realize the "To-Be" state).
- Outputs. Identification of DOTMLPF-P Impacts (and potentially, a new or modified business process).
DOTMLPF-P Impact Assessment Example.Table 12.1.3.2.T1 is an example summary output of a "To-Be" DOTMLPF-P analysis (note: more detailed information does not appear in the Business Case and is kept as "working papers"):
Table 12.1.3.2.T1 - Example of High-Level impacts from "To-Be" DOTMLPF-P Impact Assessment Analysis
|
DOTMLPF Element
|
Impact
|
|
Doctrine:
|
Development of new and revised operating procedures is required.
|
|
Organization:
|
Organization changes are required in order to achieve the agreed service level commitments.
|
|
Training:
|
A new training course is required and Personnel need ongoing access to the training.
|
|
Materiel:
|
The existing system must be enhanced or replaced in order to collect the information required by the new policy.
|
|
Leadership and Education:
|
No impact identified.
|
|
Personnel:
|
All Personnel in the call center will be trained for the revised Roles defined for the enhanced or new system.
|
|
Facilities:
|
As a result of BPR, operational improvements will increase the capacity of the existing call center and accommodate the new services that are planned.
|
|
Policy:
|
No impact identified.
|
12.1.3.3. Remaining BCD Phase Activities
Determine Recommended Course of Action. Based on completed analyses, the Functional Sponsor must decide whether a materiel solution is required to solve the problem. Assuming the Functional Sponsor's recommended course of action consists of a materiel solution he or she determines what areas to analyze during the Investment Management (IM) Phase and offers recommendations as to the appropriate solution mix (materiel and non-materiel) that will achieve the defined outcomes.
Figure 12.1.3.3.F1 - Determine Recommended Course of Action Context
No specific solutions are recommended at this point, but based on the analysis conducted, sufficient information is available to inform decision makers that a Materiel Development Decision (MDD) may be required to move forward in the process and, if so, enable an Analysis of Alternatives (AoA) to explore specific materiel solution options.
The Functional Sponsor's recommendation(s) is one of the factors that the Investment Review Board (IRB) Chair will consider when reviewing and determining whether to approve the Problem Statement. The Functional Sponsor's recommendation should also include any DOTMLPF-P impacts.
The following is a summary of the Determine Recommended Course of Action activity:
- Inputs. "As-Is" Analysis, "To-Be" Analysis.
- Process. The Functional Sponsor will review the "As-Is" Analysis and "To-Be" Analysis and select a course of action for further analysis in the IM Phase, if a material component is required. This information will be summarized in the Problem Statement and reviewed by the IRB Chair for approval.
- Outputs. Recommended course of action.
Prepare ROM Cost Estimate. Based on the Functional Sponsor's recommendation(s), a Rough Order of Magnitude (ROM) cost estimate is developed. The ROM provides a general picture of the level of effort required to solve the problem and the relative size (MAIS or non-MAIS) of what the effort might cost. According to GAO-09-3SP, March 2009, "Best Practices for Developing and Managing Capital Program Costs",a ROM is "developed when a quick estimate is needed and few details are available. Usually based on historical ratio information, it is typically developed to support what-if analyses and can be developed for a particular phase or portion of an estimate to the entire cost estimate...."
Figure 12.1.3.3.F2 - Prepare ROM Cost Estimate Context
It is important to provide a best guess for the ROM as it will be an indicator of the level of oversight required after Problem Statement approval.
The following is a summary of the Prepare ROM Cost Estimate Activity:
- Inputs. "As-Is" Analysis, "To-Be" Analysis.
- Process. The Functional Sponsor will use appropriate SMEs in developing a ROM; it is essentially the gross estimate to bridge the gap between the "As-Is" state and "To-Be" state. At this point in the process there is limited information available to yield a detailed estimate but only a gross estimate is needed to help determine the level of oversight for a potential program. One estimating technique to consider is Analogy (see DAU's Teaching Note on Cost Estimating Methodologies, February 2011 for more information).
- Outputs. ROM Cost Estimate.
Summarize Results of Analysis in Problem Statement. Results of (BCD) Phase activities are summarized in the Problem Statement by the Functional Sponsor. This summarization should provide decision makers with the essential information about the business need to make an informed decision supporting the IRB Problem Statement Review. Considerations for this activity are outlined in Figure 12.1.3.3.F4.
Figure 12.1.3.3.F3 - Summarize Results of Analysis in Problem Statement Context
Figure 12.1.3.3.F4 - Considerations Prior to IRB Submission
|
When compiling the Problem Statement, and before presentation to the IRB, the Functional Sponsor should determine whether the following questions have been adequately answered / addressed:
- Does the Problem Statement concisely and convincingly demonstrate that the business need exists and merits solving?
- Have comprehensive Root Cause and DOTMLPF-P analyses been performed?
- Has this business need / problem already been solved in the Department, as discovered through initial research?
- Have specific and measurable success factors been defined and agreed upon among the functional and stakeholder community?
- Do initial BPR efforts result in enough streamlining and efficiencies to warrant further analysis and continued investment?
- Is it clear what the Functional Sponsor is seeking from the decision maker, and what steps / activities will take place after the decision?
|
The following is a summary of the Summarize Results of Analysis in Problem Statement activity:
- Inputs. Results of BCD Phase activities (Business Process Re-engineering BPR) results (driven by HLOs) "As-Is" Analysis outputs, "To-Be" Analysis outputs, recommendation(s) (COA), ROM cost estimate).
- Process. The Functional Sponsor summarizes the output of the BCD Phase in the appropriate sections of the Problem Statement (Business Case Section 3), either as phase activities are completed or at the end of the BCD Phase (prior to IRB submission). The Functional Sponsor will also complete the Executive Summary and Introduction sections (Business Case Sections 1 and 2) in preparation for the IRB Problem Statement review.
- Outputs. Business Case Sections 1-3.
12.1.3.4. IRB Preparation
Once the Functional Sponsor determines that the Problem Statement is ready for Investment Review Board (IRB) review, it is submitted to the IRB Support Staff. Procedures for IRB submittal can be located in the "Defense Business Systems Investment Management Process Guidance", June 2012. The package must include Sections 1-3 of the Business Case signed by the Functional Sponsor and a summary slide containing a short description of the problem, the desired outcome or "what good looks like", the ROM Cost Estimate, and the proposed business value to the Department / end-user.
At the IRB, a review is conducted that will generally address items #1-6 of Figure 12.1.3.3.F4, in addition to the Enterprise and portfolio implications of the need and the Functional Sponsor's recommendation(s) for the way ahead. The IRB Chair will approve or disapprove the Problem Statement or may send it back to the Component for additional work. For an IRB Chair-approved Problem Statement, one of the following occurs:
- If the recommended course of action contains no materiel elements, BCL is exited and the Component will complete / implement non-materiel activities (i.e., policy / process changes, training development, etc.) and report back to the IRB on progress of implementation as directed by the IRB Chair, as appropriate;
- If the recommended course of action contains a materiel element but the cost is expected to fall under the MAIS threshold, subsequent BCL Phases will be executed at the Component level while investment certification activities will utilize the IRB process; or
- If the recommended course of action contains a materiel element and the cost is expected to exceed the MAIS threshold, the Component will execute BCL Phases at the OSD level and utilize the IRB process for investment certification activities.
12.1.3.5. Materiel Development Decision (MDD) Preparation
In preparation for a Materiel Development Decision (MDD), the Director, Cost Assessment and Program Evaluation (DCAPE) (for expected MAIS-level efforts) or the Component-equivalent (for those efforts that are expected to be below MAIS-level, based on the ROM) will develop Analysis of Alternative (AoA) Study Guidance and the Functional Sponsor will complete and submit an AoA Study Plan, based off the approved AoA Study Guidance.
Information on developing the AoA Study Plan and sample AoA Study Plan outlines can be found in DAG Chapter 3, Section 3.3, "Analysis of Alternatives". The AoA Study Plan should take into account the HLOs and corresponding measures developed during BCD as well as the results of the initial BPR, as these will provide valuable input to how each alternative will be evaluated.
The Study Guidance and Study Plan, along with the approved Problem Statement, will be reviewed by the MDA at the MDD. Based on the ROM:
- Functional sponsors of MAIS-level initiatives will submit the Study Plan through the IRB Chair to the MDA.
- Functional sponsors of below MAIS-level initiatives will submit the Study Plan through appropriate governance channels at the Component level.
The BCD Phase ends with approval of the Problem Statement by the IRB Chair and submission of the AoA materials to the IRB Chair (or, appropriate Component-level governance forum). If a Problem Statement is solely non-materiel, the BCD ends when the Problem Statement is approved since no AoA will be required.
DAG Tutorial 
