-----------------------------------------------------------------------
  **Module Title**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ---------------------
  ![](media/image1.wmf){width="3.9506944444444443in"   Slide \# 8-1
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ---------------------

**Module 8: LCL Management, Product Support**

**Module Outline**

  ------------------------------------------------- ----------- ---------------------
  Topic                                                         Time Frame

  Introduction/Objectives                           5 minutes   

  Logistic Support Practices                        50 minutes  

  Modular Open System Approach                      30minutes   

  Logistic Risk Mitigation Analyses                 90 minutes  

  Material Management Actions                       25 minutes  

  Review                                            10 minutes  

  **Estimated/Approximate Time for Module           **3 hours   
  Completion**                                      and 30      
                                                    minutes**   
  ------------------------------------------------- ----------- ---------------------

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image2.wmf){width="3.9506944444444443in"   Slide \# 8-2
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This module will describe how to understand and manage a system's     |
| life cycle. It includes overseeing a modular open systems approach    |
| (MOSA) where interoperability is a key life cycle logistics (LCL)     |
| facilitator.                                                          |
|                                                                       |
| The module will discuss overseeing logistic risk and overseeing       |
| material management actions involving the coordination of production, |
| inventory, location, and transportation of programs items of material |
| (and associated information and financial transactions) among the     |
| participants in a supply chain to achieve optimum readiness among     |
| departments/agencies employing a system.                              |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives (continued)**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image4.wmf){width="3.9506944444444443in"   Slide \# 8-3
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Briefly review the module agenda by introducing the topics that will  |
| be covered. Topics include:                                           |
|                                                                       |
| -   Topic 2: Logistic Support Practices                               |
|                                                                       |
| -   Topic 3: Modular Open System Approach                             |
|                                                                       |
| -   Topic 4: Logistic Risk Mitigation Analyses                        |
|                                                                       |
| -   Topic 5: Material Management Actions                              |
|                                                                       |
| -   Topic 6: Review                                                   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives (continued)**
  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image6.wmf){width="3.9506944444444443in"   Slide \# 8-4
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6916666666666667in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| [Objectives]{.underline}                                              |
|                                                                       |
| At the end of this module, you will be able to:                       |
|                                                                       |
| -   Explain how a Modular Open Systems Approach (MOSA) is used to     |
|     manage a system's life cycle.                                     |
|                                                                       |
| -   Describe the process of analyzing logistic risk mitigation early  |
|     in the system development process.                                |
|                                                                       |
|     (Continued on next page)                                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives (continued)**
  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image7.wmf){width="3.9506944444444443in"   Slide \# 8-5
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6916666666666667in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| [Objectives (continued)]{.underline}                                  |
|                                                                       |
| At the end of this module, you will be able to:                       |
|                                                                       |
| -   Explain the process of establishing logistic support program      |
|     goals over the program life cycle.                                |
|                                                                       |
| -   Distinguish logistic support practices for the public sector vs.  |
|     the commercial sector.                                            |
|                                                                       |
|     (Continued on next page)                                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives (continued)**
  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image8.wmf){width="3.9506944444444443in"   Slide \# 8-6
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6916666666666667in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| [Objectives (continued)]{.underline}                                  |
|                                                                       |
| At the end of this module, you will be able to:                       |
|                                                                       |
| -   Identify technology solutions used in logistic support practices. |
|                                                                       |
| -   Discuss the material management actions in a supply chain         |
|     necessary to achieve optimum readiness among departments/agencies |
|     employing a system.                                               |
|                                                                       |
| -   Develop a fielding/sustainment strategy for life cycle product    |
|     support in a supply chain context.                                |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives (continued)**
  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| Tell participants that Life-Cycle Logistics is very Department of     |
| Defense (DoD) focused, and it will be important for the participants  |
| to identify the concepts to apply to their own agency program         |
| management practices.                                                 |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on the introduction and objectives. After    |
| addressing any questions the participants may have, inform them that  |
| we will be moving on to the next topic: Logistics Support Practices.  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image9.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  the introduction and objectives?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image10.wmf){width="3.9506944444444443in"   Slide \# 8-7
  height="2.9680555555555554in"}                        

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The program manager is the life cycle manager. Program managers       |
| examine and implement appropriate, innovative, alternative logistics  |
| support practices, including best public sector and commercial        |
| practices and technology solutions.                                   |
|                                                                       |
| Regardless of the chosen support strategy, program managers, in       |
| collaboration with other key stakeholders establish logistics support |
| program goals for cost, customer support, and performance parameters  |
| over the program life cycle.                                          |
|                                                                       |
| Decisions are made to satisfy formal criteria, resulting in systems   |
| that are interoperable and meet the acquisition's program needs.      |
|                                                                       |
| (continued on the next page)                                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points: (continued)**                                           |
|                                                                       |
| Life cycle logistics (LCL) is a critical component in two of the      |
| program manager's key program management deliverables:                |
|                                                                       |
| -   Acquisition Strategy, which includes the product support strategy |
|                                                                       |
| -   Acquisition Program Baseline, which identifies program metrics    |
|                                                                       |
| The program manager develops and documents a Product Support Strategy |
| for life-cycle sustainment and continuous improvement of product      |
| affordability, reliability, and supportability. This effort ensures   |
| that system support and life-cycle affordability considerations are   |
| addressed and documented as an integral part of the program's overall |
| acquisition strategy.                                                 |
|                                                                       |
| The product support strategy defines the supportability planning,     |
| analyses, and trade-offs conducted to determine the optimum support   |
| concept for a materiel system and strategies for continuous           |
| affordability improvement throughout the product life cycle.          |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| Ask the following question to develop a discussion around the         |
| elements that should be addressed as part of the Product Support      |
| Strategy. Participant responses will likely be determined based on    |
| the particular acquisition they are considering when responding.      |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image9.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What are some elements that should be |
| included as part of the program manager's product support strategy?** |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| The support strategy should address all applicable support            |
| requirements to include, but not be limited to, the following         |
| elements:                                                             |
|                                                                       |
| -   Product Support (including software)                              |
|                                                                       |
| -   Interoperability                                                  |
|                                                                       |
| -   Data Management (DM)                                              |
|                                                                       |
| -   Integrated Supply Chain Management                                |
|                                                                       |
| -   Life-Cycle Cost Optimization                                      |
|                                                                       |
| -   Logistics Footprint Minimization                                  |
|                                                                       |
| -   Life-Cycle Assessment                                             |
|                                                                       |
| -   Assimilation to the appropriate business line                     |
|                                                                       |
| -   Configuration Management                                          |
|                                                                       |
| -   Environment, Safety, and Occupational Health (ESOH)               |
|                                                                       |
| -   Human Systems Integration (HSI)                                   |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| We'll discuss some of the more generic product support strategy       |
| elements that relate to logistics in more detail.                     |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| **Product support** is a package of logistics support functions       |
| necessary to maintain the readiness, sustainment, and operational     |
| capability of the program.                                            |
|                                                                       |
| The overall product support strategy, documented in the acquisition   |
| strategy, should include life-cycle support planning and address      |
| actions to assure sustainment and continually improve product         |
| affordability for programs in initial procurement, re-procurement,    |
| and post-production support.                                          |
|                                                                       |
| Support concepts satisfy user specified requirements for sustaining   |
| support performance at the lowest possible life cycle cost for each   |
| evolutionary increment of capability to be delivered to the user,     |
| including:                                                            |
|                                                                       |
| -   Availability of support to meet specified levels of performance   |
|                                                                       |
| -   Logistics support that sustains both short and long-term          |
|     readiness                                                         |
|                                                                       |
| -   Minimal total LCL cost                                            |
|                                                                       |
| -   Maintenance concepts that draw upon both organic and industry     |
|     sources                                                           |
|                                                                       |
| -   Data management and configuration management that facilitates     |
|     cost-effective product support throughout the system life cycle   |
|                                                                       |
| -   Diminishing Manufacturing Sources and Material Shortages          |
|     Management process that ensures effective, affordable, and        |
|     operationally reliable systems in increasing availability and     |
|     sustainment                                                       |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| **Interoperability** is a key LCL facilitator, which allows the       |
| program manager to take advantage of joint capabilities in designing  |
| and implementing a product support strategy. A Modular Open Systems   |
| Approach (MOSA) allows the application of risk mitigation analyses    |
| earlier in the system development process to reduce the required      |
| resources and overall life-cycle costs.                               |
|                                                                       |
| The program management team applies MOSA as an element of Systems     |
| Engineering to provide interoperability, maintainability, and         |
| compatibility when developing the support strategy and follow-on      |
| logistics planning for sustainment. (MOSA will be discussed further   |
| later in this module.)                                                |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The program manager is responsible for **data management** for the    |
| program throughout its life cycle. Data management is an important    |
| part of LCL, and consists of the disciplined processes and systems    |
| that plan for, acquire and/or access, manage, and use data throughout |
| the total system life cycle.                                          |
|                                                                       |
| Data Management is defined as:                                        |
|                                                                       |
| -   The process of applying policies, systems and procedures for      |
|     identification and control of data required                       |
|                                                                       |
| -   The timely and economical acquisition of such data                |
|                                                                       |
| -   Assuring the adequacy of data; for the access, distribution or    |
|     communication of the data to the point of use                     |
|                                                                       |
| -   Analysis of data use                                              |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| Ask the following question to discuss the definition of data as it    |
| relates to the program manager's product support strategy.            |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image9.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**How would you define the term         |
| "data?"**                                                             |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Data is defined as recorded information regardless of the form or     |
| method of recording, and includes both government and contractor      |
| created data.                                                         |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The program manager should develop a long-term strategy that          |
| integrates data requirements across all functional disciplines to     |
| include logistics. A performance-based approach should be used to     |
| identify the minimal data required to cost-effectively operate,       |
| maintain and improve the fielded system and to foster source of       |
| support competition throughout the system life cycle.                 |
|                                                                       |
| Data should be available in a format that is compatible with the      |
| intended user\'s environment and a quality assurance program should   |
| be implemented to guarantee the accuracy and completeness of the      |
| data.                                                                 |
|                                                                       |
| Industry standards organizations such as Global Electronics and       |
| Information Association (GEIA), International Organization for        |
| Standardization (ISO), and American National Standards Institute      |
| (ANSI) provide high level principles to guide integrated data         |
| management planning, and implementation.                              |
|                                                                       |
| **Note:** *GEIA Standard, GEIA-859, Data Management is a guide that   |
| may be helpful for program managers and data managers. This standard  |
| and the emerging Handbook outline principles and processes for the    |
| management of data including data interoperability and longevity,     |
| best practices, and long term electronic storage, use, and recovery   |
| of data.*                                                             |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Successful acquisitions depend on an integrated, synchronized,        |
| total-system, LCL value **integrated supply chain** to meet user      |
| requirements for information and materiel. The objective is to        |
| promote user confidence in the logistics process by building a        |
| responsive, cost-effective capacity to ensure that the buyers get the |
| products and services that they need, when they need them, with       |
| complete status information. This is accomplished by a consistent     |
| focus on the outcomes (net effectiveness) delivered by the LCL value  |
| chain from the deliverable's perspective, rather than focusing on any |
| segment of the value chain in isolation.                              |
|                                                                       |
| Under the LCL approach, the program manager is ultimately responsible |
| for satisfying the user\'s request, regardless of who is executing    |
| the integrated logistics and supply chain action.                     |
|                                                                       |
| The program manager ensures that user support is based on             |
| collaborative planning, resulting in realistic performance            |
| expectations established through Performance-Based Agreements (PBAs). |
| These agreements should be negotiated in conjunction with the product |
| support integrator, support providers, and the service providers,     |
| e.g. distribution centers and transportation providers.               |
|                                                                       |
| Although it is important in all aspects of LCL, integrated supply     |
| chain management places a premium on user collaboration. Integrated   |
| supply chain management collaboration requires data collection and    |
| data-sharing, both within the supply chain and Government. There      |
| should be a process to collect such data throughout the manufacturing |
| and utilization process so the data may be mined for product          |
| deviation and trend analysis.                                         |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The program manager's overriding program objective is to **maximize   |
| program effectiveness** from the perspective of the deliverable. To   |
| reach that maximum achievable goal within resource constraints,       |
| trade-offs are continually conducted to balance performance,          |
| availability, process efficiency, and cost.                           |
|                                                                       |
| The program manager should think in both the short- and long-terms.   |
| Short-term pressures to achieve system performance and schedule       |
| imperatives are very real, and cannot be ignored. In any program      |
| there will always be financial constraints and unforeseen financial   |
| contingencies.                                                        |
|                                                                       |
| The focus should be taking a Total Life Cycle Systems Management      |
| (TLCSM) approach to program resources and source selection weight     |
| decisions, as applied to operational cost effectiveness. (TLCSM is    |
| discussed in Module 9 of this course.)                                |
|                                                                       |
| In addition to minimizing costs, the program manager must also strive |
| to **minimize the logistical burden ("footprint")** that a system     |
| will place on resources. The 'footprint problem' is an engineering    |
| problem that is best addressed early in the life cycle. Program       |
| managers ensure that footprint metrics appropriate to the system and  |
| its operational environment are considered throughout the life cycle. |
|                                                                       |
| Given that the program manager is the total life cycle manager, it is |
| important that program managers are aware, from the very beginning of |
| a program that they must consider and plan for the ultimate           |
| **disposal of the related acquisition systems** once they are no      |
| longer useful.                                                        |
|                                                                       |
| The program manager considers disposal during systems engineering,    |
| and carefully considers the impacts of any hazardous material         |
| component requirements in the design stage to minimize their impact   |
| on the life cycle of the end item regarding item storage, packaging,  |
| handling, transportation, and disposition.                            |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image11.png) **Activity:**                                  |
|                                                                       |
| Activity Purpose:                                                     |
|                                                                       |
| This activity provides participants with an opportunity to apply      |
| their existing knowledge of program management to develop and discuss |
| a listing of logistics support practices that they feel are relevant. |
|                                                                       |
| Activity Length: 20 minutes                                           |
|                                                                       |
| Activity Instructions:                                                |
|                                                                       |
| 1.  Give participants approximately 5 minutes to brainstorm and write |
|     down as many logistics support practices that they can come up    |
|     with -- excluding those which have been discussed as part of this |
|     topic.                                                            |
|                                                                       |
| 2.  Begin with a volunteer to start a group listing of practices. As  |
|     each is provided, ask for group thoughts about the difficulties   |
|     or successes that they have had with the practice.                |
|                                                                       |
| 3.  If necessary, elaborate on the group's findings to ensure correct |
|     information is provided for the whole group.                      |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Logistics Support Practices (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on the logistics support practices. After    |
| addressing any questions the participants may have, inform them that  |
| we will be moving on to the next topic: Modular Open Systems          |
| Approach.                                                             |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image9.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  the logistics support practices?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image12.wmf){width="3.9506944444444443in"   Slide \# 8-8
  height="2.9680555555555554in"}                        

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| In Module 2, Agency Policy and Practices, MOSA was introduced as the  |
| program design implementation approach that effectively supports      |
| interoperability.                                                     |
|                                                                       |
| -   MOSA is both a business and technical strategy for developing a   |
|     new system or modernizing an existing one.                        |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   As a business strategy, it enables program teams to build,        |
|     upgrade and support systems more quickly and affordably. These    |
|     benefits may be realized by leveraging the commercial sector      |
|     investment in new technology through the use of corresponding     |
|     commercial products available from multiple sources.              |
|                                                                       |
| -   As a technical strategy, MOSA is focused on a system design that  |
|     is modular, has well defined interfaces, is designed for change   |
|     and, to the extent possible, utilizes widely supported industry   |
|     standards for key interfaces.                                     |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   As with any other approach, MOSA implementation should be based   |
|     on upfront planning.                                              |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to help participants recall the five       |
| principles of MOSA (as learned during Module 2, Agency Policy and     |
| Practices).                                                           |
+-----------------------------------------------------------------------+

![](media/image9.png){width="0.49930555555555556in"
height="0.48819444444444443in"}What are the five key principles on which
a MOSA system design should be based?

Answer:

-   Establish an Enabling Environment

-   Employ Modular Design

-   Designate Key Interfaces

-   Use Open Standards

-   Certify Conformance

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| In order to manage the life cycle of a system with MOSA, the          |
| implementation plan should, at a minimum address the following five   |
| major tasks:                                                          |
|                                                                       |
| 1.  Identify and analyze capabilities and strategies that could most  |
|     effectively be pursued by open system design solutions.           |
|                                                                       |
| 2.  Assess the feasibility of open systems design solutions.          |
|                                                                       |
| 3.  Establish performance measures to assess MOSA implementation      |
|     progress.                                                         |
|                                                                       |
| 4.  Use MOSA principles to develop an open architecture.              |
|                                                                       |
| 5.  Identify and resolve MOSA implementation issues and report the    |
|     unresolved issues to the proper authority for resolution.         |
|                                                                       |
|     Let us discuss each of these five tasks in more detail.           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| -   Identify and Analyze MOSA Enabled Capabilities and Strategies     |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   Program Managers should identify specific operational and         |
|     performance capabilities, and strategies for technology           |
|     development, acquisition, test and evaluation, and product        |
|     support that could be most effectively be enabled by using open   |
|     systems design strategies.                                        |
|                                                                       |
| -   Modular and scalable architectures could also be the preferred    |
|     design choice if capabilities must be fielded in time-phased      |
|     increments, and when the product or service demands quick         |
|     integration, interoperability, and reconfiguration of systems and |
|     their modules.                                                    |
|                                                                       |
| There are many acquisition strategies, operational capabilities, and  |
| performance requirements that lend themselves to the use of open      |
| systems in a program.                                                 |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Use the activity on the following page to tap participant's knowledge |
| and build a listing of acquisition strategies, operational            |
| capabilities and performance requirements that might lend themselves  |
| to the use of open systems in a program.                              |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image11.png) **Activity**                                   |
|                                                                       |
| Activity Purpose:                                                     |
|                                                                       |
| This activity provides participants with an opportunity to apply      |
| their existing knowledge of program management to develop a listing   |
| of acquisition strategies, operational capabilities and performance   |
| requirements that might lend themselves to the use of open systems in |
| a program.                                                            |
|                                                                       |
| Activity Length: 15 minutes                                           |
|                                                                       |
| Activity Instructions:                                                |
|                                                                       |
| 1.  Label a blank page on three easel pads with the following titles: |
|     Acquisition Strategies, Operational Capabilities and Performance  |
|     Requirements. Make sure each easel pad has several markers        |
|     available.                                                        |
|                                                                       |
| 2.  Have participants create a three-column page on a blank piece of  |
|     paper, labeled the same as the three easel pad pages.             |
|                                                                       |
| 3.  Give participants approximately 5 minutes to brainstorm the types |
|     of strategies, capabilities and performance requirements that     |
|     they have had experience with and write them in the proper        |
|     category on their paper.                                          |
|                                                                       |
| 4.  Have the group get up and go to the three easel pads to write one |
|     (and only one, even the participant has more) contribution for    |
|     each category from their listing.                                 |
|                                                                       |
| 5.  Cap this activity at the 7 -- 10 minute mark, depending on the    |
|     level of continued activity by the participants.                  |
|                                                                       |
| 6.  Use the listing on the following page (Key Findings) to discuss   |
|     the participants' contributions. Use the easel pad lists to       |
|     discuss how/why the items listed would contribute to a MOSA for a |
|     program.                                                          |
|                                                                       |
| 7.  If necessary, elaborate on the group's findings to ensure correct |
|     information is provided for the whole group.                      |
|                                                                       |
|     **Note:** *Relevant findings for each principle are found on the  |
|     following page of this Instructor Guide.*                         |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image11.png) **Activity (continued)**                       |
|                                                                       |
| **Key Findings:**                                                     |
|                                                                       |
| The following list is a sample of some items that might be identified |
| during this activity. Participants will likely come up with others.   |
|                                                                       |
| -   Evolutionary acquisition and spiral development                   |
|                                                                       |
| -   Operational requirements specified in an incremental manner over  |
|     time                                                              |
|                                                                       |
| -   Requirements that place great emphasis on long-term sustainment   |
|     and affordability, or establish affordability as the basis for    |
|     fostering greater program stability                               |
|                                                                       |
| -   The ability to constitute and reconfigure functionally compatible |
|     systems                                                           |
|                                                                       |
| -   Overarching capabilities for a mission area that form a system of |
|     systems or family of systems                                      |
|                                                                       |
| -   Reprogramming of software modules and communication networks      |
|     where software reuse and increased flexibility is required        |
|                                                                       |
| -   Application of an integrated approach for adding and facilitating |
|     the incorporation of future capabilities and advanced             |
|     technologies with minimum impact on existing systems              |
|                                                                       |
| -   Requirements that are defined in terms that enable and encourage  |
|     offerors to supply commercial and non-developmental item          |
|     equipment and call for minimizing the risks associated with being |
|     captive to specific products or sources                           |
|                                                                       |
| -   Future growth capabilities and performance characteristics that   |
|     will be highly dependent on continuous use of emerging            |
|     technologies such as computer and communication, etc.             |
|                                                                       |
| -   Interoperable agency service solutions and development of         |
|     integrated architectures that must comply with open standards     |
|     across different platforms                                        |
|                                                                       |
| -   Modular contracting strategies                                    |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Five major tasks identified for a MOSA: (continued)                   |
|                                                                       |
| -   Assess the Feasibility of Open Systems Design Solutions           |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   Open systems solution should not be pursued blindly. The program  |
|     manager should make a business case for using open systems        |
|     solutions using a dynamic business case analysis model and        |
|     application of market research findings to evaluate the           |
|     appropriateness and feasibility of open systems.                  |
|                                                                       |
| -   The model should take into consideration the changes in           |
|     technology and threats to evaluate the total life cycle costs of  |
|     designing the system as an open rather than a closed system.      |
|                                                                       |
| -   The program manager should conduct market research to identify    |
|     technologies, standards, and compliant products needed for        |
|     fulfilling capabilities and strategies identified at the          |
|     preceding step.                                                   |
|                                                                       |
| -   The review of technologies and standards will assist the program  |
|     manager in the identification and assessment of risk areas with   |
|     substantial impact on development, operation, and sustainment of  |
|     a system over its life cycle.                                     |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   Establish Metrics to Assess MOSA Implementation Progress          |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   In order to arrive at a system that exhibits open system          |
|     characteristics, it is critical to have a set of measures or      |
|     attributes indicating that these characteristics will be present  |
|     as the system is being developed and when the system is complete. |
|                                                                       |
| -   Establishing MOSA specific performance measures or at a minimum   |
|     incorporation of MOSA principles in the program's performance     |
|     measures is essential for realization of MOSA benefits.           |
|                                                                       |
| -   Program managers should use specific performance measures to      |
|     gauge the progress on implementing MOSA, and ensure timely,       |
|     efficient, and effective MOSA implementation.                     |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Five major tasks identified for a MOSA: (continued)                   |
|                                                                       |
| -   Use MOSA Principles to Develop an Open Architecture               |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   Effective MOSA implementation is contingent upon proactive        |
|     adherence to the five major MOSA principles reviewed earlier in   |
|     this topic.                                                       |
|                                                                       |
| -   These principles are essential parts of MOSA implementation plans |
|     and are fundamental to the design and implementation of open      |
|     architectures.                                                    |
|                                                                       |
| -   These guiding principles of MOSA are based on the experiences of  |
|     programs that have implemented MOSA.                              |
|                                                                       |
| -   Together, they are considered to be the minimum set of best       |
|     business practices required for an effective application of MOSA. |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   Identify and Resolve MOSA Implementation Issues and Report the    |
|     Unresolved Issues to Agency Authority                             |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   MOSA is characterized by an enabling environment, employment of   |
|     modular design, designation of key interfaces, use of open        |
|     interface standards and certification of conformance.             |
|                                                                       |
| -   In order to arrive at a system that exhibits these open system    |
|     characteristics, it is critical to establish a procedure to       |
|     assess MOSA implementation progress, identify the implementation  |
|     issues, and satisfactorily resolve such issues.                   |
|                                                                       |
| -   The procedure should be based on a set of measures or attributes  |
|     indicating that the characteristics associated with each MOSA     |
|     principle will be present as the system is being developed and    |
|     when the system is complete.                                      |
|                                                                       |
| -   These measures or attributes are intended for consideration and   |
|     use by acquisition executives, program managers and integrated    |
|     product teams (IPTs) responsible for implementing MOSA to assure  |
|     the achievement of MOSA benefits.                                 |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Modular Open Systems Approach (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| There are numerous benefits to an open system design for a program.   |
| However, there are also some inherent risks to such a design,         |
| including:                                                            |
|                                                                       |
| -   The agency becomes a consumer instead of the designer and         |
|     therefore has less control over outcomes.                         |
|                                                                       |
| -   Open systems may not provide the optimum design for modules,      |
|     components, subsystems and short-term solutions.                  |
|                                                                       |
| -   Building open systems takes time for Market Analysis, Prototyping |
|     and Standards Selection.                                          |
|                                                                       |
| -   The standards selection process has risks.                        |
|                                                                       |
| -   Open interface extensions may cause problems later in the program |
|     life cycle.                                                       |
|                                                                       |
|     The next topic discusses risk mitigation analyses as they relate  |
|     to an open system.                                                |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on the the Modular Open Systems Approach.    |
| After addressing any questions the participants may have, inform them |
| that we will be moving on to the next topic: Logistics Risk           |
| Mitigation Analyses.                                                  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image9.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  the Modular Open Systems Approach?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The risks of a MOSA include:                                          |
|                                                                       |
| -   Giving up control of the products' development                    |
|                                                                       |
| -   User acceptance of a solution that will meet but not exceed their |
|     expectations                                                      |
|                                                                       |
| -   A significant up front investment of time, money and effort to    |
|     ensure the right product is selected and supported.               |
|                                                                       |
| It will also require the development of new skills in the area of     |
| open systems management and require an understanding that a MOSA is   |
| not a "silver bullet", but a process that will defer - not eliminate  |
| -support problems later in the program life cycle.                    |
|                                                                       |
| To address these major risk areas, risk mitigation analyses are       |
| utilized by the program manager as part of the acquisition strategy   |
| and program design.                                                   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image13.wmf){width="3.9506944444444443in"   Slide \# 8-9
  height="2.9680555555555554in"}                        

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| **Test and evaluation (T&E)** is a risk mitigation analysis process   |
| used as part of the open system design. Data acquired during the T&E  |
| process yield facts that provide insight into program risk and risk   |
| mitigation, and provide empirical information that the developer can  |
| use to validate models and simulations. T&E is the only reliable way  |
| the agency can assess whether systems are operationally effective,    |
| interoperable, suitable, and survivable in their intended use         |
| environment.                                                          |
|                                                                       |
| -   **Test** is a process that exercises and stresses a system, or    |
|     components within a system, in a controlled environment.          |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   Testing provides the raw data used to: assess the system's        |
|     technical or operational performance; measure progress towards    |
|     accomplishing development objectives; and evaluate performance    |
|     and the operational capability of systems, subsystems,            |
|     components, and equipment items.                                  |
|                                                                       |
| -   **Evaluation** is an independent process that uses the raw data   |
|     acquired during testing to perform a critical assessment against  |
|     stated issues and concerns.                                       |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Evaluation is also the way the worth of a system is determined and    |
| supported during the decision making process at program milestones.   |
| Evaluators do this by gathering information not only from direct      |
| system testing but also through various studies, simulations,         |
| contractor information, other service or foreign tests, and any other |
| relevant analyses. Testing provides the raw data and evaluation       |
| reduces the data into usable information that supports the research   |
| and development and decision making processes.                        |
|                                                                       |
| Test and Evaluation should be integrated throughout the acquisition   |
| process. The combined outcome should be the generation of information |
| to decision makers, determination of the attainment of technical      |
| performance parameters, as well as the determination of operational   |
| ability, suitability, survivability and safety.                       |
|                                                                       |
| Test and Evaluation should also be integrated with modeling and       |
| simulation, should and facilitate learning, provide an assessment of  |
| technology maturation and interoperability and ensure a successful    |
| integration of the system into the agency structure.                  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Systems engineering is the technical process that uses T&E.           |
|                                                                       |
| -   T&E is an engineering tool that identifies technical risk and     |
|     validates development progress throughout the agency system       |
|     acquisition cycle.                                                |
|                                                                       |
| -   Systems engineering has a verification phase in the synthesis     |
|     process.                                                          |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| -   The verification phase confirms that design synthesis has         |
|     resulted in a physical architecture that satisfies the system     |
|     requirements.                                                     |
|                                                                       |
| -   Verification represents the intersection of systems engineering   |
|     and T&E.                                                          |
|                                                                       |
| -   Developers verify system design with a mix of analyses,           |
|     inspections, demonstrations, and test activities. The purpose is  |
|     to ensure that all design solutions meet their respective         |
|     requirements.                                                     |
|                                                                       |
| T&E is the most rigorous, and therefore most credible, verification   |
| method used to ensure proof of concept at the system, subsystem, and  |
| component levels.                                                     |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| **Risk management** is a continuous process for identifying and       |
| measuring risk; and for selecting, developing, and implementing       |
| options for the handling of risk.                                     |
|                                                                       |
| -   Risk planning entails developing an organized, comprehensive      |
|     approach for managing risk.                                       |
|                                                                       |
| -   The initial planning includes establishing a strategy;            |
|     establishing goals and objectives; planning assessment, handling, |
|     and monitoring activities; identifying resources, tasks, and      |
|     responsibilities; organizing and training risk management IPT     |
|     members; establishing a method to track risk items; and           |
|     establishing a method to document and disseminate information on  |
|     a continuous basis.                                               |
|                                                                       |
| -   T&E complements risk management by identifying unknown risks,     |
|     isolating the cause of risk, helping determine the full impact of |
|     risk, and tracking how well risk management measures mitigate     |
|     risk.                                                             |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| In order to further illustrate the principles of logistics risk       |
| mitigation, we will specifically consider the common risks and        |
| mitigation actions for a commercial off the shelf (COTS) software     |
| product.                                                              |
|                                                                       |
| The program manager must recognize the risks that are specific to the |
| use of COTS products, especially the integration of multiple products |
| into a system, and take actions to mitigate and control those risks.  |
| Careful planning must consider the entire life cycle when addressing  |
| risks.                                                                |
|                                                                       |
| The following tables identify some of the potential risks and suggest |
| mitigation actions for each. There are three areas of risk shown in   |
| the tables:                                                           |
|                                                                       |
| -   **Operational requirements** - those risks associated with the    |
|     functionality and performance of the system as perceived by its   |
|     operators                                                         |
|                                                                       |
| -   **Technical approach** - those risks associated with the          |
|     technical characteristics of the COTS products and the impact on  |
|     integrating them into a system                                    |
|                                                                       |
| -   **Business strategy** - those risks associated with the vendor of |
|     the COTS products and the impact on the continued availability of |
|     support for the products over time.                               |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| The tables on the following pages assume that:                        |
|                                                                       |
| -   \"Contractor\" will be the one to develop the system or act as    |
|     integrator of the COTS components.                                |
|                                                                       |
| -   \"Vendor\" is either the developer or the seller of a COTS        |
|     product who can provide maintenance services.                     |
|                                                                       |
| -   \"User\" is either the operator of the system or the customer who |
|     has determined the requirements for the system.                   |
|                                                                       |
| Clarify that the tables relate to a COTS software product however the |
| risks and mitigation actions will be related to the VCF business case |
| as part of a final activity for the topic.                            |
|                                                                       |
| Tables are displayed in the Participant Guide.                        |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Operational Requirements:      |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Availability: Availability of  | -   Conduct market research    |   |
| | COTS products that meet        |                                |   |
| | functional requirements before | -   Solicit industry inputs    |   |
| | beginning development are      |     (e.g., Request for         |   |
| | unknown; estimated development |     Information, industry day, |   |
| | cost and schedule are highly   |     demonstrations).           |   |
| | uncertain                      |                                |   |
| |                                | -   Encourage vendors to       |   |
| |                                |     change product             |   |
| |                                |     capabilities and           |   |
| |                                |     performance to meet        |   |
| |                                |     requirements *only* if the |   |
| |                                |     change will be             |   |
| |                                |     incorporated into the      |   |
| |                                |     commercial product.        |   |
| +--------------------------------+--------------------------------+   |
| | Functionality and Performance: | -   Ask vendors to conduct     |   |
| | Actual functionality and       |     demonstrations.            |   |
| | performance of a COTS product  |                                |   |
| | are not as advertised; system  | -   Evaluate through           |   |
| | may not meet its requirements. |     prototyping.               |   |
| |                                |                                |   |
| |                                | -   Consult other users with   |   |
| |                                |     similar requirements to    |   |
| |                                |     see what their experiences |   |
| |                                |     have been with the         |   |
| |                                |     product.                   |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Operational Requirements       |
| (continued):                                                          |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Requirements Gap: COTS product | -   Re-evaluate user           |   |
| | does not match current         |     requirements by keeping    |   |
| | operational requirements or    |     the user involved in       |   |
| | procedures and these can not   |     trade-offs between COTS    |   |
| | be changed; COTS product can   |     functionality,             |   |
| | not be used.                   |     requirements, and cost and |   |
| |                                |     schedule.                  |   |
| |                                |                                |   |
| |                                | -   Encourage user to consider |   |
| |                                |     changing operational       |   |
| |                                |     processes to match those   |   |
| |                                |     embedded in COTS products. |   |
| |                                |                                |   |
| |                                | -   Maintain an up-to-date     |   |
| |                                |     Operational Requirements   |   |
| |                                |     document, especially to    |   |
| |                                |     avoid failing operational  |   |
| |                                |     testing.                   |   |
| |                                |                                |   |
| |                                | -   Document requirement and   |   |
| |                                |     operational procedure      |   |
| |                                |     deviations.                |   |
| |                                |                                |   |
| |                                | -   Consider using a non-COTS  |   |
| |                                |     solution rather than       |   |
| |                                |     modify the COTS product so |   |
| |                                |     it deviates from the       |   |
| |                                |     commercial product         |   |
| +--------------------------------+--------------------------------+   |
| | Security and Safety Issues: If | -   Analyze the vulnerability  |   |
| | there are stringent security   |     of the system due to       |   |
| | requirements, it may not be    |     untrusted COTS components  |   |
| | possible to certify that the   |     and determine if the       |   |
| | product meets requirements     |     system can be designed to  |   |
| | because the COTS product must  |     reduce the vulnerability   |   |
| | be tested as a black box       |     to an acceptable level or  |   |
| | without its implementation.    |     else use custom software   |   |
| |                                |     at the key points of       |   |
| |                                |     vulnerability              |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Technical Approach             |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Conformance to Program         | -   Make every effort to find  |   |
| | Standards: Conformance to      |     candidate COTS products    |   |
| | technical standards is not     |     that comply with current,  |   |
| | supported by the COTS product; |     relevant standards.        |   |
| | funding may be jeopardized or  |                                |   |
| | the COTS product may not be    | -   Investigate ways to obtain |   |
| | acceptable.                    |     waivers or to add the      |   |
| |                                |     product to accepted        |   |
| |                                |     standards.                 |   |
| +--------------------------------+--------------------------------+   |
| | Conformance to Commercial      | -   Choose COTS products that  |   |
| | Standards: Candidate COTS      |     have interfaces that       |   |
| | products do not conform to     |     conform to well-known,     |   |
| | commercial standards;          |     well-defined standards     |   |
| | interoperability with other    |     that are widely used.      |   |
| | selected COTS products may be  |                                |   |
| | difficult, costly, and time    | -   Establish and maintain an  |   |
| | consuming or impossible.       |     integration facility to    |   |
| |                                |     verify conformance.        |   |
| |                                |                                |   |
| |                                | -   Determine if results are   |   |
| |                                |     available from other       |   |
| |                                |     verification or            |   |
| |                                |     operational activities.    |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Technical Approach (continued) |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Integration Contractor\'s      | -   Specify contractor         |   |
| | Capability: Contractor does    |     selection criteria to      |   |
| | not have the technical         |     include demonstrating      |   |
| | experience to deliver a        |     experience with selecting, |   |
| | COTS-based system; system may  |     integrating, and testing   |   |
| | not meet requirements, cost,   |     COTS products.             |   |
| | and schedule.                  |                                |   |
| |                                | -   Ensure contractors are     |   |
| |                                |     familiar with the specific |   |
| |                                |     COTS products they         |   |
| |                                |     proposed.                  |   |
| |                                |                                |   |
| |                                | -   Determine the contractor's |   |
| |                                |     ability to perform         |   |
| |                                |     COTS-based system          |   |
| |                                |     engineering (e.g., past    |   |
| |                                |     performance).              |   |
| |                                |                                |   |
| |                                | -   Ensure that the            |   |
| |                                |     contract\'s configuration  |   |
| |                                |     management capability can  |   |
| |                                |     track versions of COTS     |   |
| |                                |     products.                  |   |
| +--------------------------------+--------------------------------+   |
| | Quality Requirements:          | -   Use market research to     |   |
| | Candidate COTS product does    |     determine size and         |   |
| | not meet quality requirements  |     satisfaction of customer   |   |
| | (e.g., reliability,            |     base.                      |   |
| | performance, usability); cost, |                                |   |
| | schedule, and operational      | -   Conduct demonstrations,    |   |
| | capability may be impacted.    |     prototyping before final   |   |
| |                                |     selection.                 |   |
| |                                |                                |   |
| |                                | -   Consult other users with   |   |
| |                                |     similar requirements.      |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Technical Approach (continued) |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Adaptability: Candidate COTS   | -   Assess ability of COTS     |   |
| | products do not fully support  |     products to be adapted,    |   |
| | initial and evolving           |     tailored, extended, and    |   |
| | requirements and do not have   |     integrated.                |   |
| | built-in flexibility; custom   |                                |   |
| | code may be needed or the      | -   Determine how \"open\" the |   |
| | product may be difficult to    |     application programmer     |   |
| | integrate with other products  |     interface (API) is for     |   |
| | and may become unsuitable as   |     adding capability and      |   |
| | the system changes.            |     integrating with other     |   |
| |                                |     products.                  |   |
| |                                |                                |   |
| |                                | -   Evaluate tools available   |   |
| |                                |     to tailor a COTS product.  |   |
| |                                |                                |   |
| |                                | -   Do not modify code of COTS |   |
| |                                |     products.                  |   |
| |                                |                                |   |
| |                                | -   Do continuous market       |   |
| |                                |     research for alternatives  |   |
| |                                |     and market trends          |   |
| |                                |     throughout the system's    |   |
| |                                |     life cycle.                |   |
| |                                |                                |   |
| |                                | -   Take a pro-active role in  |   |
| |                                |     influencing commercial     |   |
| |                                |     standards so that          |   |
| |                                |     commercial products will   |   |
| |                                |     better integrate into      |   |
| |                                |     program systems.           |   |
| +--------------------------------+--------------------------------+   |
| | Portability: Candidate COTS    | -   Select portable COTS       |   |
| | package is not supportable     |     products that can run on a |   |
| | across a variety of hardware   |     broad-spectrum of          |   |
| | and operating system           |     platforms or can be easily |   |
| | platforms; hardware platform   |     implemented for new        |   |
| | choices over a program         |     platforms                  |   |
| | lifecycle may be limited.      |                                |   |
| |                                | -   Check the vendor\'s record |   |
| |                                |     for moving to new          |   |
| |                                |     platforms and operating    |   |
| |                                |     systems.                   |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Technical Approach (continued) |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Sustainment: Market research   | -   Use market research to     |   |
| | is not conducted and new COTS  |     track technology trends,   |   |
| | products and technology are    |     anticipate future products |   |
| | not considered; there may be   |     releases, vendors\' plans. |   |
| | missed opportunities to        |                                |   |
| | introduce new technology.      | -   Participate in beta tests  |   |
| |                                |     of new products and        |   |
| |                                |     versions in the            |   |
| |                                |     integration lab.           |   |
| |                                |                                |   |
| |                                | -   Perform cost/benefit       |   |
| |                                |     analysis for replacement,  |   |
| |                                |     e.g., impact on licensing, |   |
| |                                |     other system software      |   |
| |                                |     affected, operator         |   |
| |                                |     interfaces and procedures, |   |
| |                                |     training, performance,     |   |
| |                                |     other sustainment costs.   |   |
| |                                |                                |   |
| |                                | -   Involve users if           |   |
| |                                |     operational capabilities,  |   |
| |                                |     operator interfaces,       |   |
| |                                |     interoperability affected. |   |
| |                                |                                |   |
| |                                | -   Plan for security          |   |
| |                                |     recertification.           |   |
| |                                |                                |   |
| |                                | -   Plan capability delivery   |   |
| |                                |     schedule to coincide with  |   |
| |                                |     emerging product releases  |   |
| |                                |     to the extent possible.    |   |
| |                                |                                |   |
| |                                | -   Plan for replacement,      |   |
| |                                |     upgrades at regular        |   |
| |                                |     intervals.                 |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Technical Approach (continued) |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Evolution: New hardware        | -   Coordinate plans for       |   |
| | upgrades or replacements are   |     hardware upgrades with     |   |
| | not compatible with current    |     software upgrades.         |   |
| | COTS software products; COTS   |                                |   |
| | software products may have to  | -   Evaluate hardware and      |   |
| | be replaced at the same time.  |     software upgrades together |   |
| |                                |     in the integration lab.    |   |
| |                                |                                |   |
| |                                | -   Determine vendor plans for |   |
| |                                |     COTS product compatibility |   |
| |                                |     with hardware.             |   |
| |                                |                                |   |
| |                                | -   Do not count on vendor     |   |
| |                                |     delivery schedules for     |   |
| |                                |     achieving hardware         |   |
| |                                |     compatibilities.           |   |
| |                                |                                |   |
| |                                | -   Accept shorter lifespans   |   |
| |                                |     for COTS. Sometimes,       |   |
| |                                |     throwaway is a realistic   |   |
| |                                |     part of evolution.         |   |
| +--------------------------------+--------------------------------+   |
| | Source Code: There is no       | -   Plan to have COTS vendors  |   |
| | access to source code; it may  |     provide product and        |   |
| | be difficult to trace          |     debugging support.         |   |
| | integration and testing        |                                |   |
| | problems to COTS products.     | -   Develop alternative        |   |
| |                                |     methods and tools for      |   |
| |                                |     system fault diagnosis.    |   |
| +--------------------------------+--------------------------------+   |
| | Upgrades: Upgrades to COTS     | -   Plan for large size growth |   |
| | software increase the size of  |     in COTS software upgrades. |   |
| | the programs or the files they |     Buy large amounts of spare |   |
| | produce; size of the hardware  |     memory initially.          |   |
| | memory in the system may be    |                                |   |
| | insufficient and may have to   | -   Make sure hardware and     |   |
| | be replaced or upgraded.       |     system architecture have a |   |
| |                                |     growth path.               |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Technical Approach (continued) |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Security: Security             | -   Select certified products  |   |
| | requirements are levied;       |     in accordance with the     |   |
| | integration of COTS products   |     system requirements if     |   |
| | may introduce security         |     such products are          |   |
| | vulnerabilities.               |     available.                 |   |
| |                                |                                |   |
| |                                | -   Design the system to       |   |
| |                                |     encapsulate the non-secure |   |
| |                                |     products and limit the     |   |
| |                                |     vulnerabilities they       |   |
| |                                |     create.                    |   |
| |                                |                                |   |
| |                                | -   Plan for the certification |   |
| |                                |     of the integrated          |   |
| |                                |     products.                  |   |
| |                                |                                |   |
| |                                | -   Use custom software or     |   |
| |                                |     hardware components when   |   |
| |                                |     the security of COTS       |   |
| |                                |     products cannot be assured |   |
| |                                |     and will make the system   |   |
| |                                |     unacceptable.              |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Business Strategy              |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Acquisition Alternatives:      | -   Evaluate alternatives for  |   |
| | Alternative methods of         |     licensing such as third    |   |
| | acquiring COTS products are    |     party vendors.             |   |
| | not evaluated; cost may be     |                                |   |
| | unnecessarily high.            | -   Seek licensing terms that  |   |
| |                                |     give the most favorable    |   |
| |                                |     conditions based on        |   |
| |                                |     requirements and           |   |
| |                                |     utilization, e.g., number  |   |
| |                                |     of users, number of CPUs.  |   |
| |                                |                                |   |
| |                                | -   Choose the appropriate     |   |
| |                                |     time to buy COTS products  |   |
| |                                |     in volume to assure latest |   |
| |                                |     technology at              |   |
| |                                |     installation.              |   |
| +--------------------------------+--------------------------------+   |
| | Vendor Reliability: Vendor of  | -   Assess vendor's market     |   |
| | a candidate COTS product is    |     share and financial        |   |
| | financially weak or unstable;  |     status.                    |   |
| | product may have poor support  |                                |   |
| | or become unsupported,         | -   Evaluate vendor's history  |   |
| | potentially leading to         |     of product support.        |   |
| | unexpected or unplanned cost   |                                |   |
| | and schedule slips.            |                                |   |
| +--------------------------------+--------------------------------+   |
| | Cost and Schedule              | -   Consider market research   |   |
| | Completeness: Cost and         |     results when developing    |   |
| | schedule estimates do not      |     estimates for initial      |   |
| | consider all the ongoing costs |     cost.                      |   |
| | of acquiring a COTS-based      |                                |   |
| | system; system may not be      | -   Include cost of            |   |
| | adequately funded.             |     integration lab, license   |   |
| |                                |     renewals, continuing       |   |
| |                                |     market research, version   |   |
| |                                |     upgrades, etc. in annual   |   |
| |                                |     budgets for development as |   |
| |                                |     well as support.           |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Business Strategy (continued)  |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Business Skills: Vendor        | -   Assess ability of          |   |
| | relationship and business      |     contractor to establish    |   |
| | skills of the contractor are   |     business relationships     |   |
| | weak; system component costs   |     with vendors, including    |   |
| | and licensing may be more      |     product services and       |   |
| | costly than necessary.         |     licensing.                 |   |
| |                                |                                |   |
| |                                | -   Consider contractor\'s     |   |
| |                                |     preferred vendor list.     |   |
| +--------------------------------+--------------------------------+   |
| | Vendor Support: Vendor stops   | -   Use continuous market      |   |
| | supporting the maintenance or  |     research to identify       |   |
| | further distribution of a      |     alternatives and           |   |
| | product or a version of that   |     anticipate vendor          |   |
| | product, or the vendor goes    |     termination.               |   |
| | out of business; lifecycle     |                                |   |
| | costs may increase and         | -   Determine if another       |   |
| | continued sustainment may not  |     organization has assumed   |   |
| | be possible.                   |     maintenance responsibility |   |
| |                                |     for the product.           |   |
| |                                |                                |   |
| |                                | -   Consider upgrade to the    |   |
| |                                |     latest product the vendor  |   |
| |                                |     supports to avoid loss of  |   |
| |                                |     vendor maintenance         |   |
| |                                |     support.                   |   |
| |                                |                                |   |
| |                                | -   Negotiate level of vendor  |   |
| |                                |     support based on system    |   |
| |                                |     availability requirements  |   |
| |                                |     and geographic             |   |
| |                                |     distribution of            |   |
| |                                |     installations.             |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Risks and Mitigation Actions Involving Business Strategy (continued)  |
|                                                                       |
| +--------------------------------+--------------------------------+   |
| | **For this potential risk...** | **Consider these mitigation    |   |
| |                                | actions...**                   |   |
| +--------------------------------+--------------------------------+   |
| | Statement of Work: Tasks in    | -   Task statements should     |   |
| | the contractor\'s Statement of |     specify:                   |   |
| | Work are not supportive of     |                                |   |
| | acquiring a COTS-based system; |     -   Do early and frequent  |   |
| | appropriate risk mitigation    |         prototyping            |   |
| | strategies may not be applied, |                                |   |
| | potentially leading to cost    |     -   Do continuous market   |   |
| | and schedule slips.            |         research               |   |
| |                                |                                |   |
| |                                |     -   Maintain integration   |   |
| |                                |         lab                    |   |
| |                                |                                |   |
| |                                |     -   Perform system         |   |
| |                                |         engineering when       |   |
| |                                |         selecting, adapting,   |   |
| |                                |         and integrating COTS   |   |
| |                                |         products with each     |   |
| |                                |         other and system       |   |
| |                                |         hardware.              |   |
| +--------------------------------+--------------------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image11.png) **Activity**                                   |
|                                                                       |
| Activity Purpose:                                                     |
|                                                                       |
| This activity provides participants with an opportunity to identify   |
| and develop risk mitigation actions for VCF Acquisition Program       |
| Business Case Study.                                                  |
|                                                                       |
| *This module activity continues the business case that will be used   |
| throughout this course to apply various concepts and reinforce        |
| learning through the use of critical thinking and application         |
| skills.*                                                              |
|                                                                       |
| Activity Length: 45 minutes                                           |
|                                                                       |
| Activity Instructions:                                                |
|                                                                       |
| 1.  Tell participants they will be given 40 minutes to review the VCF |
|     Acquisition Program Business Case Study found in their            |
|     Participant Guide and on the following pages of this Instructor   |
|     Guide. Have the participants work independently to identify the   |
|     specific risks and risk mitigation actions as they relate to this |
|     business case.                                                    |
|                                                                       |
| 2.  Instruct participants to divide a sheet of paper into three       |
|     categories for the exercise: Business Strategy, Technical         |
|     Approach and Operational Requirements.                            |
|                                                                       |
| 3.  Divide participants into three groups, and assign each group one  |
|     of the three risk mitigation categories: Business Strategy,       |
|     Technical Approach or Operational Requirements. Allow groups 20   |
|     minutes to discuss their categories' findings, and identify which |
|     five they agree are most relevant for the case study.             |
|                                                                       |
| 4.  Have each group present their top five findings for risk          |
|     mitigation in their assigned category. Use the findings to        |
|     facilitate a whole group discussion for each category of other    |
|     actions, etc., participants want to contribute.                   |
|                                                                       |
|     **Note:** *Key Findings are found on the following pages of this  |
|     Instructor Guide.*                                                |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[Introduction: FBI Shares the Blame]{.underline}

The VCF was supposed to automate the FBI\'s paper-based work
environment, allow agents and intelligence analysts to share vital
investigative information, and replace the obsolete Automated Case
Support (ACS) system. Instead, the FBI claims, the VCF\'s contractor,
Science Applications International Corp. (SAIC), delivered 700 000 lines
of code so bug-ridden and functionally off target that the bureau had to
scrap the \$170 million project, including \$105 million worth of
unusable code. However, various government and independent reports show
that the FBI shares the blame for the project\'s failure.

[The Bureau Environment: Lots of Paper]{.underline}

The bureau\'s 12,400 agents work out of 56 field offices and 400
satellite - or resident agency - offices, as well as 51 Legal Attaché
offices scattered across the globe in U.S. embassies and consulates.
Field agents interview witnesses, develop informants, conduct
surveillance, hunt for clues, and collaborate with local law enforcement
to find and arrest criminals. Agents document every step and
methodically build case files. They spend a tremendous amount of time
processing paperwork, faxing and FedEx-ing standardized memo and
requisition forms through the approval chain. Once the appropriate
supervisors sign off on the form, it goes back to the agent, who gives
it to a clerk to enter into the ACS system. From there, the paper form
is filed as part of the official record of the case. This system of
forms and approvals stretches back to the 1920s.

[July 2000: Trying to Bring Order to Chaos]{.underline}

According to the DOJ\'s Office of the Inspector General, the FBI had
13,000 computers that could not run modern software. Most of the 400
resident agency offices were connected to the FBI intranet with links
about the speed of a 56-kilobit-per-second modem. Many of the bureau\'s
network components were no longer manufactured or supported. And agents
couldn\'t e-mail U.S. Attorney offices, federal agencies, local law
enforcement, or each other; instead, they typically faxed case-related
information.

\[1\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[July 2000: Trying to Bring Order to Chaos (continued)]{.underline}

In 2000 the bureau finally began to deal with its outdated IT systems.
At the time, under the direction of Louis J. Freeh, the bureau had
neither a CIO nor documentation detailing its IT systems, much less a
plan for revamping them. The task of creating such a plan fell to former
IBM executive Bob E. Dies, who became assistant director in charge of
the FBI Information Resources Division on 17 July 2000. He was the first
of five officials who, over the next four years, would struggle to lead
the FBI\'s sprawling and antiquated information systems and get the VCF
project under way.

In September 2000, Congress approved \$379.8 million over three years
for what was then called the FBI Information Technology Upgrade Project.
Eventually divided into three parts, the program became known as
Trilogy. The Information Presentation Component would provide all 56 FBI
field offices, some 22,000 agents and support staff, with new Dell
Pentium PCs running Microsoft Office, as well as new scanners, printers,
and servers. The Transportation Network Component would provide secure
local area and wide area networks, allowing agents to share information
with their supervisors and each other.

But the User Applications Component, which would ultimately become the
VCF, staked out the most ambitious goals. First, it was to make the five
most heavily used investigative applications---the Automated Case
Support system, IntelPlus, the Criminal Law Enforcement Application, the
Integrated Intelligence Information Application, and the Telephone
Application---accessible via a point-and-click Web interface. Next, it
would rebuild the FBI\'s intranet. Finally, it was supposed to identify
a way to replace the FBI\'s 40-odd investigative software applications,
including ACS.

[Spring 2001: Trilogy Contracts Awarded]{.underline}

In May and June 2001, the bureau awarded Trilogy contracts to two major
U.S. government contractors: DynCorp, of Reston, Va., for the hardware
and network projects, and to SAIC for software. All three Trilogy
components were to be delivered by the middle of 2004. The FBI used
cost-plus-award fee contracts for the hardware, networks, and software.

\[2\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[September 2001: Inadequate System Exposed; the Virtual Case File is
Born]{.underline}

On 4 September 2001, Robert S. Mueller III became the tenth director in
FBI history. One week later, terrorists pulverized New York City\'s
World Trade Center and a piece of the Pentagon. The inability of FBI
agents to share the most basic information about Al Qaeda\'s U.S.
activities blew up into a front-page scandal. Within days, the FBI\'s
pathetic technology infrastructure went from being so much arcane trivia
to a subject of daily fulmination by politicians and newspaper
columnists. In the face of intense public and congressional pressure,
Mueller shifted Trilogy into high gear.

Recognizing the limitations of the new web interface feature of Trilogy
and ACS, Robert J. Chiaradio the FBI\'s executive assistant director for
administration decided that the Bureau needed an entirely new database,
graphical user interface, and applications, which would let agents
search across various investigations to find relationships to their own
cases. The new case management system would host millions of records
containing information on everything from witnesses, suspects, and
informants to evidence such as documents, photos, and audio recordings.
To address concerns being raised by intelligence experts and lawmakers
in the wake of 9/11, these records would be accessible to both the
FBI\'s agents and its intelligence analysts. The new system was dubbed
the Virtual Case File.

With no detailed description of the FBI\'s processes and IT
infrastructure to go by (i.e., an enterprise architecture), a team of
FBI agents led by Larry Depew began to characterize investigative
processes such as witness interviews and surveillance operations and map
them to the FBI\'s software and databases. Depew, a veteran Special
Agent from the Trenton, New Jersey office, was a self taught database
programmer. Over a six-week period in the fall of 2001, the group
defined how agents worked, how they gathered information, and how that
information was fed into ACS. Working with engineers from SAIC, they
drew up diagrams and flowcharts of how the case management system
operated then and how they wanted the new case management system, the
VCF, to operate in the future.

\[3\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[December 2001: Contract Changes and an Accelerated
Schedule]{.underline}

In December 2001, the FBI asked SAIC to stop building a Web front end
for the old programs. Instead, SAIC was asked to devise a new
application, database, and graphical user interface to completely
replace ACS.

To formally define what users needed the VCF to do for them, SAIC
embarked on a series of Joint Application Development (JAD) sessions. In
these meetings, the FBI's team of agents and experts got together with a
group of SAIC engineers to hash out what functions the VCF would
perform. Ideas captured in these sessions formed the basis of the
requirements document that guided SAIC\'s application designers and
programmers.

In January 2002, the FBI requested an additional \$70 million to
accelerate Trilogy; Congress went further, approving \$78 million.
DynCorp committed to delivering its two components by July 2002. SAIC
agreed to deliver the initial version of the VCF in December 2003
instead of June 2004.

SAIC and the FBI were now committed to creating an entirely new case
management system in 22 months. While the Trilogy contracts were changed
to reflect the aggressive new deadlines, neither the original software
contract nor the modified one specified any formal criteria for the FBI
to use to accept or reject the finished VCF software. Furthermore, those
contracts specified no formal project schedules at all, let alone
milestones that SAIC and DynCorp were contractually obligated to meet on
the way to final delivery.

In reaction to the new deadline, SAIC broke its VCF development group
into eight teams, working in parallel on different functional pieces of
the program. The eight threads would later prove difficult for SAIC to
combine into a single system. Nevertheless, Rick Reynolds, vice
president and operations manager for SAIC, defended the decision to
change tactics. \"People forget the urgency that we were under and our
customer was under. And we were right beside them,\" he declared. \"We
were in the foxhole together.\"

[March 2002: Defining Requirements]{.underline}

Over a six-month period, the JAD team met in two-week sessions. After a
two-week JAD session finished, a two-week feedback cycle would begin.
SAIC provided Depew\'s team with information gleaned from the session,
including needs statements, flow charts, and meeting minutes. Depew\'s
team reviewed these materials and gave SAIC feedback while
simultaneously preparing subject matter experts for the next round of
JAD sessions, which immediately followed the feedback cycle. There were
no breaks.

\[4\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

Mueller, Dies, and Chiaradio recruited C.Z. (\"Sherry\") Higgins, a
seasoned IT program manager with experience at Lucent and AT&T, to be
the FBI's new project management executive for the Office of the
Director. The new Office of Program Management would centralize IT
management and oversee, develop, and deploy the bureau\'s most
expensive, complex, and risky projects. But her most important
assignment was to manage Trilogy. Her first move when she came on board
in March 2002 was to appoint Depew, who had no IT project management
experience, the VCF project manager.

[April 2002: Schedules Start to Slip]{.underline}

In mid-April 2002, Higgins, demanded a detailed schedule from DynCorp.
After she got it, she pulled the project teams from the FBI and DynCorp
into a meeting and went through the document. Shortly after that,
Higgins broke the news to the director: the computers and networks would
not be delivered in July of that year as had been scheduled. She told
Mueller that DynCorp didn\'t stand a chance of hitting the delivery
target, because it didn\'t have a detailed schedule that mapped out how
it would deploy, integrate, and test the new computers and networks.

[July 2002: VCF Looked Good on Paper]{.underline}

The JAD sessions had produced an exhaustively detailed requirements
document. This plan for a case-management system would combine the ACS
with two other systems: the Telephone Application, the bureau\'s central
repository of telephone records related to investigations, and parts of
the Criminal Law Enforcement Application, a repository for investigative
data about people, organizations, locations, vehicles, and
communications.

The VCF system would accept scanned documents, photographs, and other
electronic media---to simplify evidence tracking. People with the proper
credentials would be able to access that evidence from any FBI office.
The way work flowed through the bureau would change dramatically, too.
Instead of filling out a form either by hand or in a word-processing
program and then faxing or FedEx-ing the paper form to a supervisor, an
agent would fill out a form online and, with a click of the mouse, route
it to the supervisor. The document would pop up in a supervisor\'s
in-box, and the agent could track it to see if it had been approved. And
perhaps most important, information collected within a case file would
eventually be available to software applications that would compare data
among cases to search for correlations---to connect the proverbial dots.

\[5\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[Summer 2002: Detailed Requirements]{.underline}

By August 2002 SAIC had around 200 programmers on the job. Matthew
Patton joined the SAIC team as a security engineer. Patton, who was
later removed from the project after criticizing its management in an
Internet posting, was unimpressed by the 800-plus pages of requirements.
\"In a requirements document, you want to dictate the whats, not the
hows,\" Patton said. \"We need an e-mail system that can do x, and
there\'s 12 bullets. Instead, we had things like \'there will be a page
with a button that says e-mail on it.\' We want our button here on the
page or we want it that color. We want a logo on the front page that
looks like x. We want certain things on the left-hand side of the page.
They were trying to design the system layout and then the whole
application logic before they had actually even figured out what they
wanted the system to do.\"

The overly specific nature of the requirements focused developers on
their tiny piece of the puzzle. They were writing code, Patton said,
with no idea of how their piece fit with the others. This presaged the
integration problems that would later plague the project.

Patton also claimed that SAIC was determined to write much of the VCF
from scratch. This included an e-mail-like system that at least one
team, to his knowledge, was writing, even though the FBI was already
using an off-the-shelf software package, Novell\'s GroupWise, for
e-mail.

[December 2002: The March of the Change Requests]{.underline}

In December 2002, Higgins asked lawmakers to invest an additional
\$137.9 million in Trilogy. Congress approved another \$123.2 million
for a project whose total cost had now ballooned to \$581 million.

After the FBI and SAIC agreed to the baseline set of requirements, SAIC
programmers began cranking out code. The company had settled on a spiral
development methodology, an iterative approach to writing software.
Basically, SAIC programmers would write and compile a block of code that
performed a particular function, then run it to show Depew\'s agents
what it would do. The agents gave the programmers feedback, and the
programmers tried to incorporate the suggested changes. Sometimes
Depew\'s team had only two days to review a batch of code. Agents would
pull all-nighters to get the evaluation finished, \"and in the next
iteration their comments wouldn\'t be taken into account,\" Higgins
said. Sometimes, she acknowledged, these evaluations would include
changes to the requirements---functions that the agents had decided that
they needed once they saw what they were going to get. Other times the
FBI team would find bugs that needed to be fixed.

\[6\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

If there was a dispute as to whether the change could or should be made,
the agents sent an official request to the change control board,
composed of SAIC engineers and FBI personnel, for review. It wasn\'t
long before the change requests started rolling in---roughly 400 from
December 2002 to December 2003, according to SAIC.

\"Once they saw the product of the code we wrote, then they would say,
\'Oh, we\'ve got to change this. That isn\'t what I meant,\'\" said
SAIC\'s Reynolds. \"And that\'s when we started logging change request
after change request after change request.\" Reynolds added that SAIC\'s
bid on the original contract, and each subsequently revised cost
estimate, was based on there being \"minimal, minor changes\" to the
program once a baseline set of requirements had been agreed on.

Some of the changes were cosmetic---move a button from one part of the
screen to another, for instance. Others required the programmers to add
a new function to a part of the program, such as the graphical user
interface, common to all eight development threads.

[March 2003: The Network is Delayed]{.underline}

In March 2003, Computer Sciences Corp., which had acquired DynCorp that
month, told Higgins that the final deployment of the computers and
networks would be delayed until October. In August, October became
December. And in October, December became April 2004. The problem
wasn\'t the PCs, which had been trickling in since 2001, but changing
the e-mail system from Novell\'s GroupWise to Microsoft Outlook and,
obtaining the components needed to connect the field offices to the wide
area network. Higgins added that the delays were compounded by the
FBI\'s own sloppy inventories of existing networks and its
underestimation of how taxing the network traffic would be once all
22,000 users came online using their new PCs.

While the FBI and SAIC waited for the networks to go live so they could
test the VCF on a real system, changes and fixes continued. Many of the
changes had to be to be made by all eight of SAIC\'s development teams.
Arnold Punaro, SAIC executive vice president and general manager,
admitted in a posting on the company\'s Web site that in the rush to get
the program finished by December, SAIC didn\'t ensure that all of its
programmers were making the changes the same way. That inconsistency
occasionally meant that different modules of the VCF handled data in
different ways. Consequently, when one module needed to communicate with
another, errors sometimes occurred.

\"This, however, did not compromise the system,\" according to Punaro.
The real killers, he said, were \"significant management turbulence\" at
the FBI, \"the ever-shifting nature of the requirements,\" and the
agents\' \"trial-and-error, \'We will know it when we see it\' approach
to development.\"

\[7\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[September 2003: Testing Begins]{.underline}

SAIC began testing the program in the fall of 2003, and problems started
cropping up, some of which the agents had warned SAIC about over the
previous summer. SAIC officials complained to Higgins that Computer
Sciences Corp. didn\'t have its hardware and network in place, so SAIC
couldn\'t adequately test the VCF, crucial for a successful flash
cutover. They informed her that they would deliver a version of the VCF
to be in technical compliance with the terms of the contract and that
the FBI should feel free to make changes to it afterward.

[December 2003: VCF Delivery and Failure]{.underline}

On 13 December 2003, SAIC delivered the VCF to the FBI. Under the
direction of the FBI's new interim CIO, Zalmai Azmi, the FBI rejected
SAIC\'s delivery. The bureau found 17 \"functional deficiencies\" it
wanted SAIC to fix before the system was deployed. SAIC argued that at
least some of these deficiencies were changes in requirements. An
arbitrator was called in. The arbitrator found fault with both SAIC and
the FBI. Of the 59 issues and subissues derived from the original 17
deficiencies, the arbitrator found that 19 were requirements
changes---the FBI\'s fault; the other 40 were SAIC\'s errors.

While SAIC fixed bugs, Azmi, with the help of Depew\'s team, created
investigation scenarios that would take different cases from opening to
closing and tested them on the VCF. Those tests revealed an additional
400 deficiencies. \"We have requirements that are not in the final
product, yet we have capabilities in the final product that we don\'t
have requirements for,\" said Azmi.

At the same time Computer Sciences Corp was delivering the final pieces
of equipment to the FBI. By April, 22,251 computer workstations, 3408
printers, 1463 scanners, 475 servers, and new local and wide area
networks would all be up and running, 22 months later than the
accelerated schedule called for.

Azmi and SAIC had yet to agree on the VCF\'s ultimate fate, much less
when it would be deployed. Azmi rejected SAIC's proposal to take one
more year to make all the changes the FBI wanted at the cost of an
additional \$56 million.

[June 2003: Trying to Salvage Something from VCF:]{.underline}

Azmi asked SAIC to take the electronic workflow portion of the VCF, code
that was in relatively good shape, and turn that into what was
eventually called the Initial Operating Capability (IOC), at an
additional fixed price to the FBI of \$16.4 million. SAIC and the FBI
project team had six months to deliver a software package that would be
deployed to between 250 and 500 field personnel in Louisiana and at the
Hoover Building.

\[8\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

The objectives for the new project were clear: test-drive the VCF\'s
electronic workflow; see how people reacted to the graphical user
interface; create a way to translate the output from the VCF forms, into
the ACS system; check out network performance; and develop a training
program. The IOC would use Azmi\'s rigorous approach to software
development and project management, which he called the Life Cycle
Management Directive.

[June 2004: SAIC Begins the IOC Project]{.underline}

With new management in place, about 120 SAIC engineers began work on the
IOC project. The FBI and SAIC agreed to keep to a strict development
schedule, define acceptance criteria, and institute a series of control
gates. Azmi\'s project manager worked closely with his SAIC counterpart
to adhere to the baseline requirements SAIC and the FBI had agreed on
for the IOC in July, thus avoiding a death spiral of change requests. In
January, the IOC was rolled out as a pilot right on schedule.

[March 2005: IOC Pilot Fails]{.underline}

The IOC pilot ended in March. The verdict: \"Although the IOC
application was an aid to task management, its use did not improve the
productivity of most users,\" according to an internal FBI assessment.
FBI employees, particularly agents, found that the IOC actually
increased their workload. Agents filled out forms electronically and
routed them to superiors for approval, after which the electronic form
was uploaded to the ACS, still in use, to be shared with the rest of the
FBI. But to comply with the FBI\'s paper-based records management
system, the form had to be printed out, routed, signed, and filed.

[May 2005: Sentinel Rises from the Ashes of VCF]{.underline}

In May 2005 Mueller announced Sentinel, a four-phase, four-year project
intended to do the VCF\'s job and provide the bureau with a Web-based
case- and records-management system that incorporates commercial
off-the-shelf software.

[March 2006: Sentinel goes to Contract]{.underline}

The FBI awarded a \$305M contract to Lockheed Martin for Sentinel. Total
program cost is estimated to be \$425M.

[June 2007: Sentinel's First Deployment]{.underline}

The FBI and Lockheed Martin rolled out Phase 1 Sentinel capabilities to
the FBI workforce. According to a press release from the FBI phase 1
includes a "Personal Workbox, which summarizes a user's cases and
leads....and user-friendly search capabilities." Azmi announces his
intent to use agile development to deliver new capability to the desktop
every six to nine months.

\[9\]

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image11.png) **Activity:(continued)**                       |
|                                                                       |
| **Key Findings:**                                                     |
|                                                                       |
| The key findings are summarized for each category below.              |
|                                                                       |
| +---------------------+---------------------+---------------------+   |
| | **Business          | **Technical         | **Operational       |   |
| | Strategy**          | Approach**          | Requirements**      |   |
| +---------------------+---------------------+---------------------+   |
| | Cost/Schedule       | Conformance to      | Avaibility          |   |
| | Completeness Risk:  | Program Standards   | Risk:Spring 2001    |   |
| | July 2000 13,000    | Risk: March 2003    | COTS avaibility     |   |
| | computers           | email system does   | unknown when        |   |
| | re                  | not meet            | awarding Trilogy    |   |
| | placements/upgrades | requirements.       | contracts.          |   |
| | not accurately      |                     |                     |   |
| | costed.             | *Re-evaluate        | *Conduct market     |   |
| |                     | requirements to see | research.*          |   |
| | *Develop pilot in   | if they can be      |                     |   |
| | lab and use         | adjusted to allow   |                     |   |
| | parametric          | COTS (instead of    |                     |   |
| | estimating*         | writing custom      |                     |   |
| |                     | software).*         |                     |   |
| +---------------------+---------------------+---------------------+   |
| | Business Skills     | Conformance to      | Performance Risk:   |   |
| | Risk: April 2002    | Commercial          | Summer 2002 email   |   |
| | contractor          | Standards Risk:     | system performance  |   |
| | schedules in error. | Sept 2003           | may not meeti       |   |
| |                     | integration testing | requirements.       |   |
| | *Assess             | impeeded by lack of |                     |   |
| | contractor's        | representative      | *Prototype and      |   |
| | abilities and       | network.            | contact other users |   |
| | consider alternate  |                     | to be sure.*        |   |
| | sources.*           | *Establish and      |                     |   |
| |                     | maintain            |                     |   |
| |                     | integration         |                     |   |
| |                     | facility.*          |                     |   |
| +---------------------+---------------------+---------------------+   |
| | SOW Risk: June 2003 | Integration Risk:   | Requirements Gap    |   |
| | significant scope   | March 2003          | Risk: March 2003    |   |
| | change to salvage   | system-wide tests   | email system does   |   |
| | IOC from VCF.       | impeeded by         | not meet            |   |
| |                     | dissimilar          | requirements.       |   |
| | *Perform            | sub-system level    |                     |   |
| | s                   | changes.            | *Re-evaluate        |   |
| | ystems/architecture |                     | requirements to see |   |
| | engineering to      | *Maintain tight     | if they can be      |   |
| | insure that         | control over        | adjusted to allow   |   |
| | approach will meet  | interfaces.*        | COTS (instead of    |   |
| | requirements.*      |                     | writing custom      |   |
| |                     |                     | software).*         |   |
| +---------------------+---------------------+---------------------+   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Logistics Risk Mitigation Analyses (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on the logistics risk mitigation analyses.   |
| After addressing any questions the participants may have, inform them |
| that we will be moving on to the next topic: Material Management      |
| Actions.                                                              |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image9.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  the logistics risk mitigation analyses?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 5: Material Management Actions**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image14.wmf){width="3.9506944444444443in"   Slide \# 8-10
  height="2.9680555555555554in"}                        

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Material management, referred to also as "supply chain management" is |
| an important element of the program manager's focus with regard to    |
| LCL management, product support and interoperability.                 |
|                                                                       |
| Supply chain management (SCM) is defined by Wikipedia as "the process |
| of planning, implementing and controlling the operations of the       |
| supply chain as efficiently as possible. SCM spans all movement and   |
| storage of raw materials, work-in-process inventory, and finished     |
| goods from point-of-origin to point-of-consumption."                  |
|                                                                       |
| Some experts distinguish SCM and logistics, while others consider the |
| terms to be interchangeable.                                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 5: Material Management Actions (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Generally speaking, supply chain management must address the          |
| following problems:                                                   |
|                                                                       |
| -   Distribution Network Configuration: Number, location and network  |
|     missions of suppliers, production facilities, distribution        |
|     centers, warehouses, cross-docks and customers.                   |
|                                                                       |
| -   Distribution Strategy: Including questions of operating control   |
|     (centralized, decentralized or shared); delivery scheme (e.g.,    |
|     direct shipment, pool point shipping, Cross docking, mode of      |
|     transportation (e.g., motor carrier, including truckload, LTL,    |
|     parcel; railroad; intermodal; ocean freight; airfreight);         |
|     replenishment strategy (e.g., pull, push or hybrid); and          |
|     transportation control (e.g., owner-operated, private carrier,    |
|     common carrier, contract carrier).                                |
|                                                                       |
| -   Information: Integration of and other processes through the       |
|     supply chain to share valuable information, including demand      |
|     signals, forecasts, inventory, transportation, and potential      |
|     collaboration etc.                                                |
|                                                                       |
| -   Inventory Management: Quantity and location of inventory          |
|     including raw materials, work-in-process and finished goods.      |
|                                                                       |
| -   Cash-Flow: Arranging the payment terms and the methodologies for  |
|     exchanging funds across entities within the supply chain.         |
|                                                                       |
| -   Supply chain execution is managing and coordinating the movement  |
|     of materials, information and funds across the supply chain. The  |
|     flow is bi-directional.                                           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 5: Material Management Actions (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to initiate a group discussion about       |
| material management actions (SCM). Have participants provide examples |
| and experiences with SCM that relate to prior or current-day projects |
| and programs.                                                         |
+-----------------------------------------------------------------------+

![](media/image9.png){width="0.49930555555555556in"
height="0.48819444444444443in"}Think about your most recent (or current)
acquisition.

What sorts of supply chain management strategies did you incorporate as
part of the overall Acquisition Strategy?

What are some of the issues and challenges you've been faced with
relative to material management actions?

What impact did they have on the program or project?

How did you overcome them?

Answer:

Use participant answers to develop a lengthy discussion around supply
chain management issues and solutions that the participants have used to
resolve them.

  -----------------------------------------------------------------------
  **Topic 5: Material Management Actions (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on the material management actions. After    |
| addressing any questions the participants may have, inform them that  |
| we will be moving on to the next topic: Module Review.                |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image9.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  the Material Management Actions?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 6: Review**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image15.wmf){width="3.9506944444444443in"   Slide \# 8-11
  height="2.9680555555555554in"}                        

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Let's review the learning objectives for this module on Life Cycle    |
| Logistics Product Support.                                            |
|                                                                       |
| -   Explain how a Modular Open Systems Approach (MOSA) is used to     |
|     manage a system's life cycle.                                     |
|                                                                       |
| -   Describe the process of analyzing logistic risk mitigation early  |
|     in the system development process.                                |
|                                                                       |
|     (Continued on the next page)                                      |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 6: Review (continued)**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image15.wmf){width="3.9506944444444443in"   Slide \# 8-11
  height="2.9680555555555554in"}                        (continued)

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| (continued)                                                           |
|                                                                       |
| -   Explain the process of establishing logistic support program      |
|     goals over the program life cycle.                                |
|                                                                       |
| -   Distinguish logistic support practices for the public sector vs.  |
|     the commercial sector.                                            |
|                                                                       |
|     (Continued on the next page)                                      |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 6: Review (continued)**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image15.wmf){width="3.9506944444444443in"   Slide \# 8-11
  height="2.9680555555555554in"}                        (continued)

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| (Continued)                                                           |
|                                                                       |
| -   Identify technology solutions used in logistic support practices. |
|                                                                       |
| -   Discuss the material management actions in a supply chain         |
|     necessary to achieve optimum readiness among departments/agencies |
|     employing a system.                                               |
|                                                                       |
| -   Develop a fielding/sustainment strategy for life cycle product    |
|     support in a supply chain context.                                |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 6: Review (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes Module 8 -- Life Cycle Logistics Management Product    |
| Support.. Address any questions the participants may have before      |
| moving on to Module 9 -- Business Financial Planning.                 |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image9.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have about Module
  8 -- Life Cycle Logistics Management Product Support?**

  -----------------------------------------------------------------------