Life Cycle Costing

Clearly, a critical part of selecting among alternative architectures is the cost of each architecture and the systems that they imply. We adopt the perspective that costs must be considered on a life-cycle basis. Thus, the three main categories of cost are:

1. Research, development, test, and evaluation (RDT&E)

2. Acquisition or procurement

3. Operations and maintenance (O&M)

The above three cost categories may be further broken down into subordinate cost elements, as shown in Exhibit 7.2.

Exhibit 7.2: Breakdown of Major Cost Categories into Cost Elements

1. Research, Development, Test, and Evaluation

1.1. Research and development Preliminary studies Design engineering Hardware

Software

Other personnel costs

1.2. Test and evaluation Test planning

Test hardware Test software Test operations Test evaluation Other personnel costs

2. Procurement

2.1. Installations New construction Modification and renovation

2.2. Equipment (hardware and software) Primary mission

Mission support Other specialized

2.3. Stocks

Initial stock—primary mission Initial stock—support mission Spares—primary and support

2.4. Initial training

Training and support personnel Training materials and equipment Training facilities

2.5. Other procurement (e.g., transportation) costs 3. Operations and Maintenance (O&M)

3.1. Equipment replacement (hardware and software) Primary mission

Mission support Other specialized

3.2. Maintenance Primary mission Mission support Other specialized

3.3. Training

Training and support personnel Training materials and equipment Training facilities

3.4. Salaries (operators) System operators

Other operational support

3.5. Material Expendables

Other support material

3.6. Other operations and maintenance (e.g., transportation)

3.7. Disposal of system Dismanteling of system Disposal of parts

Using the above information, we may then construct the three dimensions of a Life-Cycle Cost Model (LCCM). The first dimension is the list of all the cost elements, as delineated in Exhibit 7.2. These may be visualized as the rows of a spreadsheet. Since the model applies to a system's life cycle, the next dimension is time, measured in years from the beginning of work on the system. This dimension is constructed as the columns of the spreadsheet. With these two dimensions, we can readily appreciate how data intensive the LCCM will be. For example, with about three dozen cost elements and perhaps a twenty-year life for the system, we have a total of (36)(20) = 720 cells that make up the spreadsheet. Each one needs to be estimated with as much fidelity as possible. If we then sum across any row, we are able to see the overall life-cycle cost of one of the elements, for example, the total

RDT&E costs. If we sum down one of the columns, we can easily calculate the cost in any particular year. This is a necessary step in most budgeting processes. Finally, we recognize that systems are ultimately broken down into major subsystems. Thus, we may expand the two dimensions of the LCCM into a third dimension, namely, the subsystems of the overall system. Various ''sheets'' of the LCCM spreadsheet represent the subsystem costs, and then these are added into a summary ''sheet'' that represents the final LCCM for the system. To summarize, the three dimensions of an LCCM, constructed in the manner herein described, become:

1. The cost elements of the system

2. The years of useful life for the system

3. The subsystems of the overall system

During the early days of design, the subsystems may be thought of as the functions that are to be implemented in the system.

During architecture assessment, we usually only have a first-order estimate of these costs. However, they generally suffice to discriminate between the defined alternatives. As we move on to subsystem design, we develop costs more precisely, leading to more complete and, we hope, accurate cost estimates. Often, we also utilize various cost-estimating relationships (CERs) to develop the necessary cost estimates. An example is the Constructive COst MOdel (COCOMO) [7.13], which is used in its various forms as a way of estimating costs and time to completion for software projects.

Cost estimating relationships (CERs) provide for the systems engineering team a way of estimating and calculating system costs in a generally top-down fashion. Instead of a process by which all the subordinate costs are estimated for, as an example, a radar system (bottom-up approach), we are able to estimate the costs as a function of only a few key variables for the system in question. This concept is further illustrated in Exhibit 7.3.

Exhibit 7.3: Illustrative Cost Estimating Relationships (CERs) [7.1]

The Cost of a Can Be Considered a Function of

Radar system

Missile booster Satellite terminal

Output power Frequency of operation Bandwidth or pulse width Weight Weight

Type of propellent Output power Antenna size Frequency of operation Receiver sensitivity

The Cost of a

Can Be Considered a Function of

Aircraft engine

Thrust Bypass ratio

Delivered source instructions Type of development effort Experience of team Number of channels Frequency Power

Size of antenna Frequency of operation

Software effort

Radio equipment

Dish antenna

The essential reason for using the above types of CERs, therefore, is that it is the best we are able to do at an early stage of design (e.g., the conceptual or architecting stages). If the estimating is being done for a new, clean-sheet-of-paper system, and by the users, it is especially important to have CER data so that budgets can be prepared for the system. Later on, it is useful to have these estimates to compare what the user believes the system should cost to what the system developer might believe it will cost. These concepts are traceable to the Department of Defense in the McNamara days, when he set up a group of ''Whiz Kids'' whose job, in part, was to be able to independently (from the contractor community) estimate the costs of new systems.

In general, we seek a cost-effective architecture and system, as illustrated in Figure 7.5. This figure shows three alternatives: a low-cost, low-effectiveness system; a high-cost, high-effectiveness system, and a system in between in terms of cost and effectiveness. The latter, hopefully defined at the ''knee-of-the-curve,'' may turn out to be our preferred system. However, the low-cost, low-effectiveness system might be our preferred choice as long as it satisfies all the system requirements. This first-order representation, however, must be examined in greater detail in order to select a preferred system. This important topic is covered in Chapter 9 and again in the Appendix.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment