Baseline the System

Figure 1. Baseline the System

A baseline serves as the starting point for measuring progress in the quality or quantity of work or performance related to either a product or a service. The baseline indicates a state at a certain point in time; the result of work or performance from that point onward shows whether things are improving, staying even, or getting worse.

Figure 1. Baseline the System

To construct a baseline collect the data, or begin assembling data for new systems, needed to assess and analyze support decisions, including inputs from Supportability Analysis. This data includes such things as Failure Modes Effects & Criticality Analysis (FMECA), Failure Reporting and Corrective Action System (FRACAS), Level of Repair Analysis (LORA), Maintenance Task Analysis (MTA), Reliability Centered Maintenance (RCM) analysis, and other key maintenance planning tasks, as well as Reliability, Availability and Maintainability (RAM) and Life-Cycle Cost (LCC) analyses.

Defining and documenting the system baseline provided the inputs needed to answer four key questions:

1. What is the scope of your support requirement?
2. Who are the key stakeholders?
3. What are your cost and performance objectives?
4. For fielded systems, what are the historic readiness rates and Operations and Support (O&S) costs relative to the upgraded or new system?

The PM/PSM needs to identify the difference between existing and desired performance requirements to develop an effective support strategy. Accordingly, the PM/PSM identifies and documents the current performance and cost baseline. The life cycle stage of a program determines the scope of a baselining effort. For new programs with no existing product support infrastructure, the baseline should include an examination of the cost to support the replaced systems. If there is no replaced system, Life Cycle Cost (LCC) estimates should be used. For new systems, the business model for supporting the product demonstrates its risks and benefits as part of the systems engineering process. This proof of concept for the support solution is part of the EMD phase. For existing systems, the baseline assessments form the basis for BCA of product support approaches being considered. Determination of the sustainment and readiness performance history and associated operations and support cost is essential. Therefore, actual data should be used for fielded systems.

Generally, there is more than one type of baseline associated with a weapon system. For example, the following may apply:

• Concept of Operations Baseline - The intention is to clearly establish the basic requirements that the system will fulfill.
• System Baseline - This may be considered to be the functional requirements developed for the system. It should be carefully controlled through the configuration management program. By establishing and maintaining formal system baselines, team members will not be able to add/delete requirements without fully considering the ramifications. Listed below are components of the system baseline:
  • Performance Requirements
  • Operational Mission
  • Range of Customers
  • Scope of Sub-Systems
  • Available Funding Resources
  • Subsystem Baseline - This baseline occurs after the requirements are completed and preliminary design work has established a mapping of high-level functions to system components.
  • Development Baseline - This baseline should be completed before system development begins. Once system development begins, there will be pressure to change system design for many reasons (desired new functionality, changes in technology, impediments to development, etc.). It is essential to carefully control these changes to design to maintain the integrity of the system and to control costs.
  • Product Baseline - This baseline essentially documents the "as-built" design that reflects the completed system. The product baseline is the result of the series of changes that have been made to the original developmental baseline during the system development process. Ideally, if the developmental baseline is under configuration control, the product baseline will simply be the evolution of the developmental baseline.
  • Operational Baseline - Given the pressure for change, weapon systems are "living" systems. In other words, the product baseline will change with time to adapt to the necessary changes. During system operations, it is essential to maintain the operational baseline to reflect changes that have been approved through the configuration management process and implemented.
  • Support Baseline -The support baseline represents the range of resources, functional components, scope of responsibilities, support metrics, and the support strategy process (i.e., performance-based vs. transactional-based or blend of both) by which the weapon system is supported to achieve optimum operational availability and reliability. Under Total Life Cycle System Management, it is the responsibility of the Program Manager to develop and document the Support Baseline. Like other baselines, it can, and most likely will, be modified over time to accommodate changes in weapon system funding, utilization, life cycle phase, performance requirements, and DoD and Service policy and guidance. Listed below are the constraints and enablers of a support baseline:
    • CORE
    • 50/50
    • Existing Infrastructure
    • Service Policy
    • Service Guidance
    • Life Cycle Phase
    • Enablers
    • Sources of Support
    • Commerciality
    • Interoperability
    • Common Standards

Baselines are not necessarily set only once at the beginning of a program. They should be reset as the program evolves so that you can document where you are at various waypoints over the life cycle. By collaborating with stakeholders such as weapon system operators, organic and commercial support providers, and other customers of the acquisition, technology, and logistics community, you can use the baselines to establish reasonable performance targets and develop methods for tracking actual performance covering areas such as technical operations, cost, or schedule. An example of a formal baseline in managing a weapon system program is the acquisition program baseline (APB). The APB is a document that contains the most important cost, schedule, and performance targets (both thresholds and objectives) for the program.

The process of developing the system baseline is to identify all of the information known about the system to include performance, support, reliability, maintainability, and cost data. A robust Integrated Data Environment (IDE) should be initiated (or accessed) as a fundamental component in the support strategy development or revision process. This stage of the process also provides an essential linkage to a variety of systems engineering and life cycle logistics efforts to ensure a system is designed with supportability in mind, including key inputs from Supportability Analysis activities outlined in the Affordable System Operational Effectiveness model. These include IPS element activities such as Failure Modes Effects & Criticality Analysis (FMECA), Failure Reporting and Corrective Action System (FRACAS), Fault Tree Analysis (FTA), Level of Repair Analysis (LORA), Maintenance Task Analysis (MTA), Reliability Centered Maintenance (RCM) analysis, and other related maintenance planning tasks, as well as Reliability, Availability and Maintainability (RAM) and Life Cycle Cost (LCC) analyses. Throughout the maintenance planning process; however, it is important to remember that "the PM shall design the maintenance program to minimize total life cycle cost while achieving readiness and sustainability objectives. Maintenance planning and management shall begin at program initiation."

Implementation of a disciplined design for support approach, including these systems engineering analysis tools are directly linked to a system's Reliability, Availability, and Maintainability (RAM) attributes and life cycle costs, and will play a key role in not only establishing top-level product support metrics, but in ultimately meeting Warfighter performance outcome requirements. Close collaboration between systems engineers and life cycle logisticians is critically important during system design and development and throughout the life cycle. These tasks are further refined during the subsequent Business Case Analysis to determine a cost effective, sustainable product support solution to meet user needs in an operational environment.

Return to top