12.2. Investment Management (IM) Phase
12.2.1. Purpose, Outputs, and Outcomes
The purpose of the Investment Management (IM) Phase is to conduct an Analysis of Alternatives (AoA), recommend a preferred Doctrine, Organization, Training, Materiel, Leadership and education, Personnel, Facilities, and Policy (DOTMLPF-P) solution and deliver a plan (i.e., Business Case) to satisfy the business need in the approved Problem Statement. It is an iterative process that will result in a strategy and plan that can be executed to field useful capability.
The outputs and outcome of IM Phase activity are:
- A completed AoA that enables the Functional Sponsor and program manager (PM) to recommend a preferred solution for solving the business need;
- A well-defined business and technical management approach that describes how the effort will achieve its objectives using the preferred solution-set. The Business Case is the summary level document for those functional plans and strategies.
- A Program Charter defining roles and responsibilities for the potential program; and,
- Certification of funds to proceed through the next BCL phase;
12.2.2. IM Phase Process
Figure 12.2.2.F1 - IM Phase High Level Process Flow
At the Materiel Development Decision (MDD) the Milestone Decision Authority (MDA), in most cases, will approve entry into the Investment Management (IM) Phase. However, it is possible that the MDA may specify a different entry point (phase) into BCL if the technology supporting the materiel solution has been demonstrated and is well-understood, and the potential program is defined well enough to begin in a later phase. If this is the case, the program shall proceed to the designated entry point and perform the appropriate activities as specified in that phase and the MDD Acquisition Decision Memorandum (ADM).
During the IM Phase a Program Manager (PM) is typically assigned early on and will work with the Functional Sponsor to begin managing the materiel portion of IM Phase activities.
The IM Phase begins with an analysis to describe the requirements for the materiel solution and an Analysis of Alternatives (AoA) to select a preferred solution. Based on the preferred solution, the Functional Sponsor and PM will conduct activities necessary to define a program and develop a well-documented plan to deliver the outcomes defined in the IRB Chair approved Problem Statement. Planning documents are developed as appropriate (e.g., systems engineering, test & evaluation) for the program and are expected to evolve as the program matures; prior to Milestone (MS) A, some plans are merely strategies to be refined into plans when more facts are known.
The results of IM Phase activities are summarized in a Business Case that provides decision makers with on overview of the proposed solution including the acquisition and contracting approach. The Program Charter, that outlines the managerial methods and standards for governing the program, is also developed during this phase.
Also, prior to the end of IM Phase, the PM must schedule an independent risk assessment (Enterprise Risk Assessment Methodology (ERAM) is required for MAIS) approximately 120 days prior to MS A review. An ERAM is required for all MAIS DBS prior to a MS A or B review. The program manager will collaborate with the risk assessment team to incorporate findings and recommendations into the program's risk mitigation plan. No additional documentation is created by the program for a risk assessment, as it is based on existing program documentation. Detailed risk assessment findings will be provided to the Functional Sponsor, PM, Investment Review Board (IRB) Chair, and MDA. Summary ERAM findings are presented at the IRB.
The IM Phase ends when the phase activities are complete and summarized in the Business case, and the PM compiles and submits the MS A acquisition decision package to the IRB for review and the IRB Chair forwards a MS A recommendation to the MDA .
12.2.3. IM Phase Activities
The Investment Management (IM) Phase involves numerous activities beginning by conducting a detailed materiel solution analysis and subsequently developing a program plan based on the results of this analysis. These activities are depicted in more detail in Figure 12.2.3.F1. The goal of IM Phase activities is to develop an efficient and effective plan to fulfill the business need documented in the Problem Statement. The results of IM Phase analysis and activities are summarized in a Business Case and a Program Charter, the two key documents used by decision-makers throughout the Business Capability Lifecycle (BCL). The Business Case Template and Program Charter Template are available on the Office of the Deputy Chief Management Officer (DCMO)'s BCL webpage.
Figure 12.2.3.F1 - Decomposition of IM Phase Activities
12.2.3.1. Conduct Materiel Solution Analysis
Conducting a Materiel Solution Analysis enables the Functional Sponsor to describe the needed requirements to achieve the high-level outcomes (HLOs) and business outcomes defined in the Problem Statement. Activities completed during the Material Solution Analysis include: conducting an analysis on each of the selected alternatives per the Analysis of Alternatives (AoA) Study Guidance along with their associated Doctrine, Organization, Training, Leadership and education, Personnel, Facilities, and Policy (DOT_LPF-P) impacts and risks; comparing each alternative against how well it will address the HLOs, business outcomes and their corresponding measures to solve the business need; selecting a preferred solution based on criteria outlined in the AoA Study Guidance and Plan; and, developing and defining program outcomes. These activities are depicted in further detail in Figure 12.2.3.1.F1.
Figure 12.2.3.1.F1 - Decomposition of Materiel Solution Analysis
Conduct Analysis of Alternatives (AoA).
The AoA is an analytical study that is intended to compare the business capability, performance potential, operational effectiveness, cost, and risks of a number of potential alternative solutions to address the problem identified in the Problem Statement. Detailed information about conducting an AoA - including how to develop an AoA Study Plan - can be found in DAG Chapter 3, Section 3.3, "Analysis of Alternatives".
Figure 12.2.3.1.F2 - Conduct AoA Context
Whereas JCIDS uses the Initial Capabilities Document (ICD) to guide the AoA, the AoA conducted during the IM Phase utilizes information from the Problem Statement and is directed by the AoA Study Guidance and Plan. It is critical that the results of the DOTMLPF-P Impact Assessment conducted during the BCD Phase are leveraged during the AoA.
During the AoA, the Functional Sponsor will leverage a team to assess each defined alternative and determine which will best solve the problem. Each alternative must be evaluated in terms of how well it addresses the HLOs, business outcomes, and measures in the Problem Statement and how well it fits into the "To-Be" state as defined by the initial Business Process Re-engineering (BPR). Any potential solution must also have the ability to become Business Enterprise Architecture (BEA)-compliant. A cost analysis (total life-cycle or total ownership, as appropriate) and cost effectiveness analysis on each alternative is conducted in addition to market research. The summary of these results is provided in the Business Case. The summary must include, at a minimum:
- A high-level explanation of the AoA process / methodology used;
- The type of market research conducted;
- The preferred alternative selection resulting from the AoA;
- Benefits and risks from the preferred alternative selection; and
- Any other information the Functional Sponsor deems appropriate for decision makers.
|
TIP: The HLOs and associated measures developed during the BCD phase should have been written to be independent of a particular solution (i.e., solution agnostic).
Something to avoid is the following scenario found during a GAO audit: DoD and service officials responsible for conducting AoAs indicated that often proposed capability requirements are so specific that they effectively eliminate all but the service sponsor's preferred concepts instead of considering other alternatives (GAO-09-655, September 2009).
|
The following is a summary of the Conduct AoA activity:
- Inputs. AoA Study Plan (based on the approved Problem Statement and AoA Study Guidance), initial BPR results, HLOs and business outcomes, and corresponding measures.
- Process. The Functional Sponsor coordinates an AoA study team/working group and assesses each alternative using the approved AoA Study Guidance and AoA Study Plan. Together, the Functional Sponsor and team will, at a minimum, conduct market research, perform cost analysis and provide a summary of the alternatives (and the preferred solution) in the Business Case.
- Outputs. Solution options (AoA results), AoA summary documented in the Business Case.
Select Preferred Solution.
Once all alternatives have been analyzed according to the AoA Study Plan, the Functional Sponsor selects the best-value solution in terms of cost, best fit for providing the desired business capability, performance, support and other factors, for solving the problem as defined in the Problem Statement. The selection process takes into consideration impacts of potential tradeoffs, and the principles of Better Buying Power.
Figure 12.2.3.1.F3 - Preferred Solution Selection Context
|
TIP: The "best value" alternative does not always mean the least expensive. According to DoD ESI Best Value Toolkit, "best value" is defined as "the expected outcome of an acquisition that, in the Government's estimation, provides the greatest overall benefit in response to the requirement". Thus, selecting a preferred solution should take into account other factors than just cost, such as performance or time, and most fundamentally, meeting the needs of the user.
|
The following is a summary of the Select Preferred Solution activity along with an example:
- Inputs. AoA results, AoA Summary.
- Process. Guided by the AoA Study Plan, the Functional Sponsor and the technical team, including appropriate subject matter experts (SMEs), analyze potential solutions by conducting a best-value determination (including consideration of Better Buying Power principles, tradeoffs, etc). The resulting analysis will yield the preferred solution. The overall analysis is then summarized in the Business Case.
- Outputs. Preferred solution.
Preferred Solution Selection Example. An example of the preferred solution selection process comes from a general commercial off-the-shelf (COTS) software selection.
- The Functional Sponsor and technical team review the following AoA results presented in a table format:
Solution Option 1: COTS (i.e., Oracle Financial Management (FM) software)
Solution Option 2: Hybrid solution (i.e., Oracle FM software and custom development)
Table 12.2.3.1.T1 - Example AoA Results
|
Alternative
|
Benefits
|
Risks
|
Type of Cost Analysis
|
Cost Estimate
|
|
Oracle Financial Management
e-business suite
|
Widely used commercially/ in DoD
|
High number of system interfaces
|
Life Cycle Cost (LCC)
|
$96M
|
|
Oracle FM+ custom development
|
Greatest chance of achieving HLOs
|
Complex software development
|
LCC
|
$110M
|
- As part of the best-value determination, the Functional Sponsor and technical team perform tradeoff analysis. The purpose is to re-evaluate and update the unconstrained "To-Be" BPR conducted during the Business Capability Definition (BCD) Phase by analyzing it against the alternatives. The objective is to minimize software customization and to identify tradeoffs between the re-engineered "To-Be" state and the alternatives. Tradeoffs are those aspects of the re-engineered "To-Be" state that will need to be modified based on the selected alternative such as interfaces to other systems, business rules, and reports. Statute mandates that the commercial business process should be adopted to minimize customization of COTS products as opposed to customizing COTS software to match legacy practices. As a result of the analysis, the team develops the following conclusions about the two alternatives:
Alternative 1: Oracle Financials requires extensive tradeoffs in desired business capability, i.e., it does not allow for the type of feeder systems mandated by DoD Policy, and commercial business processes are different than the original "To-Be" process.
Alternative 2: Oracle Financials + custom development requires minimal tradeoffs; this will cost more and take more time. Also, the final software application will no longer be COTS.
- After careful consideration using best-value determination, the team selects the COTS alternative (Oracle Financials software) as their preferred solution. The team determined that it is feasible that the policy can be changed (added risk), and adopting the commercial business processes will help deliver the desired outcomes but will require additional training.
Define Program Outcomes.
After a solution has been selected as a result of the AoA, the Functional Sponsor along with the Program Manager performs solution-specific BPR. This activity includes updating the "To-Be" process based on the business process inherent to the solution in addition to defining and prioritizing program outcomes based on the decomposition of HLOs and business outcomes first defined during the BCD Phase. The connected top-down framework of outcomes from a strategic to a more detailed level ensures continuity between the HLOs and program outcomes, and provides the basis for developing more specific system-level requirements to be tested against during Execution.
Figure 12.2.3.1.F4 - Define Program Outcomes Context
Program outcomes defined during the IM Phase should be specific enough to allow the association of functional requirements and non-functional requirements (i.e., DOT_LPF-P) during and beyond the Prototyping Phase. For example, if a program outcome identified during IM is: "Administration capability for role-based authorization", then an associated functional requirement may be: "The system shall enable a user with the role of System Administrator to assign one or more roles to a user of the system".
|
TIP: Detailed system-level requirements do not typically belong in the Business Case and should be kept at the program-level with other detailed program-level operational or execution-level documentation.
|
The following is a summary of the Define Program Outcomes activity along with an example:
- Inputs. Preferred solution, initial BPR results, HLOs and business outcomes and their corresponding measures, benefits, risks, assumptions, constraints, and dependencies.
- Process. The Functional Sponsor decomposes the HLOs and business outcomes into more specific program outcomes (e.g., what specific functions the potential program will perform) based on the initial BPR results, the preferred solution, and any previous requirements tradeoffs. Up to now, the business outcomes/Capabilities have been driven by the BEA-defined end-to-end (E2E) business flows, business processes, and capabilities. Now that a preferred solution has been selected the "To-Be" business process may have to be revised to accommodate the preferred solution and any tradeoffs made during the analysis. If the updated business process ("To-Be) causes gaps between it and the BEA a determination will have to be made regarding issuing a waiver or filling the gap in the BEA for its next release. Program outcomes must also have associated measures, benefits, risks, assumptions, constraints, and dependencies. A summary of this information is then documented in the Business Case as appropriate.
- Outputs. Program outcomes and their measures, benefits, risks, assumptions, constraints, and dependencies; and, the updated business process.
Program Outcome Definition Example. An example of defining program outcomes comes from the Defense Agencies Initiative (DAI):
- The Functional Sponsor determined the program outcome that aligns to the HLOs and business outcome(s):
HLO: Accurate, useful, reliable and timely financial data and management information
Business Outcome: Consistency with financial and Information Assurance standards
Program Outcome: Financial controls/internal controls
Program Outcome Definition: Ensure financial controls and internal controls are embedded in the financial solution to prevent material weaknesses, and ensure budgetary integrity by establishing financial control over funds, obligations, assets, and liabilities.
- The Functional Sponsor conducts additional BPR refinement, if necessary. In this example, the Functional Sponsor has determined the initial BPR was silent on audit trails so an additional program outcome was added to the business outcome as follows:
HLO: Accurate, useful, reliable and timely financial data and management information
Business Outcome: Consistency with financial and Information Assurance standards
Program Outcome: Audit Trail
Program Outcome Definition: A record of transactions is referenced on-demand to: trace activities to original documents and verify account balances.
- The Functional Sponsor specified characteristics of the program outcome including: measurements, benefits, risks, assumptions, constraints, and dependencies:
Program Outcome: Implement Financial / internal controls
Measurement: Compliance with the financial / internal controls requirements as defined in OMB Circular A-123.
Current Baseline Value: 0%
Targeted Threshold Value: 75%
Targeted Objective Value: 100%
Benefits: Integrity of financial information
Risks: Ability to achieve component consensus on information requirements; quality of legacy data
Assumptions: Financial information will be entered correctly into the system
Constraints: The information must be reported to Congress annually
Dependencies: The solution requires multiple interfaces
DAG Tutorial 
