A Primer on Cost for COSTLESS

by

Edwin Dean


Foreword

I believe that cost is probably the most misunderstood phenomena we deal with every day. Anyone you meet randomly on the street can talk at length about cost, yet even accountant's often can't even add it up properly because accounting mixes the metaphors of cost and value. This same person on the street cannot tell you how much their next car will cost because there are so many variables involved. These variables include inflation from now to the data of purchase, the type of car, the features of the car, the dealer they will buy it from, the existence of manufacturer rebates, their personal skill at negotiating, and even the day of the month on which it will be purchased. Yet management expects to know exactly what a complex system that is hardly conceptualized yet will cost upon delivery at a date known only to be many years in the future.

Cost is a very complex field of study because of the systemic and emotional nature of cost. I have studied cost since about 1976. I performed my first cost substantial cost estimate in 1978 while Chief Engineer of an advanced development project for the Navy. Having now estimated trillions of dollars worth of advanced engineering projects, I can honestly say that analyzing and estimating cost has been the most complex endeavor I have ever attempted. I have used virtually everything I ever learned from my backgrounds in physics, math, statistics, operations research, engineering, project management, and business, only to fall short of providing what I consider to be good cost estimates. However complex cost is, a basic understanding of cost is necessary in order to become a smart buyer, a primary goal of the COSTLESS team.

I have been asked to put together reading material for COSTLESS on cost from an operations perspective. This primer is a hopefully evolving attempt to provide you with that reading material. Having read approximately two article-chapter reading units per workday for the last five years on this subject, this is a tremendous task in abstraction. The intent is to put the very core here. Your questions are appreciated because, by our answering those, you will learn what you feel is important and I will understand better what is needed to provide that core information. Thus your questions and our answers to your questions will become an iterative learning process by the team. Unless otherwise instructed, I will include all such dialog in a question and answer page with names attached. I will also attempt to integrate the content of the dialog within the body of this page.

I have chosen the Web as the media for this primer because of the ease of distribution. There will be a distinct bias in the reading material as a result because much of the material on the Web on this subject is my own and is in the open domain. Unfortunately, I cannot provide most of the other references because of copyright restrictions. You will have to use your own library resources for those. I will refer freely to my Design for Competitive Advantage (DFCA) pages for clarification or more depth. The references and bibliographies there are probably of more value than the words which have been intentionally kept concise. There, I have attempted to succinctly describe over thirty categories of knowledge which affect cost.

Ed Dean

A View of Cost

Cost is a measure or symptom of the way we do business. Cost is a cause of the way we do business. Thus, the way we do business affects how we do business. Thus the way we do business is recursive (and so is cost).

Cost is a measure in monetary units of the work of human endeavor. Cost has units of work. All real systems have an allocated cost which is a measure of the work of human endeavor required to conceptualize, evaluate, design, prototype, test, produce, deploy, operate, support, evolve, retire, and manage the system.

Cost is systemic. A change in the cost of one entity, a function or subsystem, may affect costs in other entities through systemic interaction.

A system with no cost would have no size and no complexity.

Low cost cannot be inspected into a system, it must be designed into the system..

A View of Design

We must concurrently

Design the conceptualization of the product
Design the evaluation of the product
Design the design of the product
Design the prototyping of the product
Design the test of the product
Design the production of the product
Design the deployment of the product
Design the operation of the product
Design the support of the product
Design the evolution of the product
Design the retirement of the product
Design the management of the product, and finally

Design the product

Introduction

Cost is a measure of human endeavor in monetary units. Putnam (1978) notes that cost has units of work. It is an expenditure of resources. He also notes that the time rate of change of cost has units of power. This is the level of the y-axis of the usual resource per unit time vs. time chart seen on projects. These observations provide a basis for the slowly emerging category of knowledge which I call theoretical cost analysis.

Why is the emergence of theoretical cost analysis important? Because, without theory we do not know what data to collect to improve the empirical basis of the science of cost. Is cost a science? Not yet, because we don't have theory to know what data to collect. The state-of-the-art in cost technology is represented by parametric cost analysis (PCA). In PCA noncost variables are mapped to cost through an equation. Typically this equation is linear in the logarithms of the variables. This generates a power law equation similar to those found in psychophysics and economics. Cost is thus represented by the product of variables raised to a nonintegral power. Linear regression is typically used to obtain these equations from unit cost data. Unfortunately, the analyst usually can only find the weight of a system to associate with the cost. Hence, most of parametric cost analysis is based upon weight based cost estimating relationships (CERs).

Besides being misleading, weight is not really a noncost variable which describes operations. Dean (1995b) presents an hypothesis concerning the appropriate variables, in general, in which to represent cost. They are basically the quality characteristics associated with the qualities described on the smart buyer page. For operations, the quality characteristics are measures of the goodness of the functions performed by the operations organization.

This leads us to activity based cost. An activity is an organizational implementation of a function. A function is associated with purpose. Thus, activity based cost measures the amount of the work of human endeavor consumed in accomplishing a specific purpose. Accountants use the average cost per activity times the number of times an activity is performed within a process to come up with the cost of an activity within a process. As an example, suppose we implement the function "print page" 50 times within the process "print report" at an average cost of $1.00 per time. The average cost of the process "print report" is $50.00.

Because activity based costing measures processes and since operations is defined by processes, activity based costing is the natural way to measure and estimate operations cost. NASA has not yet changed from historical and grossly misleading unit based costing to activity based costing. Thus, there is no process database within NASA which can be used for establishing operations cost appropriately. Work is progressing to obtain and analyze a few data points for a few very high level activities.

Accountants assume that the cost per activity is a constant. In reality, the cost of a process is probabilistic in nature because of the variations which occur within the process. Thus the cost each time is a realization from the cost distribution of that process. In theory, since it is not practiced, this permits the application of statistical process control to cost to look for and fix special and common causes of variation. According to the theory of the Taguchi loss function, reducing this variation will reduce the cost to society.

If we put parametic cost estimating together with activity based costing we have parametric activity based costing. This would express the average cost per activity in terms of process quality characteristics. Given such equations, we could then determine very clearly what must be done to reduce cost. Ahhh, but I dream. What American manager would expend cost to save cost? But this leads to the next section which addresses the practical world of reducing cost.

Current Means of Reducing Cost

Today, there are several major means of reducing cost. The first is value engineering and the second is business process reengineering. Both of these are processes. Both of these are based upon the concept of function. Value engineering operates upon the functions of the product. Business process reengineering operates upon functions of the system to bring forth, sustain, and retire the product.

Both value engineering and business process reengineering expand the design space so the least cost alternative can be chosen from a large design space. Incidentally, NASA usually only examines a few alternatives before the design concept is frozen. In many cases it attempts to obtain cost reduction through inheritance, which usually does not exist, from a previous design. If inheritance does exist, it usually fails to reduce cost as much as alternate designs which were never examined.

A third way is Kaizen, or continuing improvement. If an organization is focusing on continuing improvement, then cost is a measure to improve by reducing it. The creativity of the human mind, if focused on cost reduction, will find ways to reduce cost. It management will permit that creativity to flourish, the focus on cost reduction will generate real cost reduction.

A fourth way is to put quality first. A major issue here is the definition of quality. In years past, NASA, along with the rest of America, defined quality in terms of the fineness of the product. For NASA, fineness was defined as performance. Following the teachings of Deming in 1950 (Deming, 1986), the Japanese learned that quality was best defined in terms of the customer. Today, the Japanese, along with all in the world who must compete head to head with them, define quality in terms of what the customer expects, what the customer desires, and what will excite the customer.

When quality is defined this way and when quality is put first within an organization, costs within that organization will decrease rapidly because of the elimination of waste, rework, and timing mismatches. To accomplish this requires that the whole product development process be designed to provide what the customer wants. It also requires that all successor subprocesses in an internal serial process become the customer of any given subprocess. This requires concurrent engineering. Total quality control is a system to ensure that the product provides what the customer wants. Cost reductions of greater than 50 % over three to five years are not an uncommon result when quality, as defined by the customer, is put first within an organization under the philosophy of Kaizen.

When a process is highly automated, two of the largest cost drivers are machine ineffectiveness and line downtime. They are related. Total productive maintenance is a system of maintenance which greatly increases machine effectiveness and line throughput. By using the operators to maintain the machines, large cost savings are realized. Previous implementation of continuing improvement and a strong quality first system are prerequisites for realization of the large cost savings.

Just-in-time realizes large cost savings from the reduction of work-in-process inventory and serial process time variation. It also helps align production with demand. Previous implementation of total productive maintenance greatly enhances the cost savings realized by just-in-time. The concept of just-in-time can be applied to any serial process, hence, the concept of just-in-time applies to many NASA operations processes.

Autonomation (Monden, 1992) is the concept of reducing serial process waste by not allowing bad product to enter the process. This is accomplished by product quality inspection after each subprocess. This inspection is typically automated. The Japanese discovered that, in most serial processes, it is less costly to stop the serial process than to permit bad product to enter the subprocess. This follows from the cost-to-society theory of the Taguchi loss function. The concept of autonomation can be applied to any serial process, hence, the concept of autonomation applies to many NASA operations processes.

Task interleaving permits the same serial process to produce many different products in arbitrary sequences. The major enableing feature is the reduction of setup times to virtually zero. Cost savings result from highly effective use of the serial process and from inventory reduction because of the ability to match production very closely to demand. The concept of task interleaving can be applied to any serial process, hence, the concept of task interleaving applies to many NASA operations processes.

The most powerful way of reducing cost is multiprocess cost management because it implements a combination of many ways to reduce cost.

As an example of multiprocess cost management, to follow the Toyota way requires the implementation under Kaizen of total quality control, followed by total productive maintenance, followed by just in time and autonomation, followed by task interleaving. The order of implementation is important because each process enables the process to follow. Kaizen implements the desire to improve. Total quality control implements a structure to enable and control improvement by maximizing human effectiveness and reducing waste. Lewis Platt of Hewlett-Packard, among many others (Crosby, 1979), notes that the cost savings due to quality can be very large (Anon., 1994). Total productive maintenance implements increased machine effectiveness. Just in time minimizes work in process inventory and minimizes production variation. Task interleaving maximizes throughput and matches production to demand by producing arbitrary sequences of different products on the same production line. Incidentally Toyota uses value engineering within it's design process to reduce cost and considerably reengineered it's whole business process to arrive at the current state. Each of these processes is an element of the Toyota cost management strategy (Monden, 1992)

How do these production concepts relate to NASA operations? We can directly apply the philosophy of continuing improvement (Kaizen) within operations. We can directly implement total quality control within NASA operations. Considering each mission as a product, we can adapt the concept of total productive maintenance to maximize mission effectiveness. Total productive maintenance, with minor adaptations, applies specifically to the many information systems within NASA operations. We have many serial processes within NASA operations to which an adaptation of just in time could be applied. It would seem that we could develop a NASA operations process capable of producing many operations products from the same process through task interleaving. The ultimate in product interleaving is a product on demand system such as EosDIS.

Although the Toyota production processes do not all apply to NASA operations at a physical level, they do apply at a conceptual level. This is important since design starts at the conceptual level and moves through reducing levels of abstraction until the design is complete. The final design is a detailed abstraction of the system to be physically implemented.

It is important to note that NASA desires to implement many types of missions. This means that the cost of mission development is significant. How can reduce the cost of mission developement? Can we implement a system which will automatically encompass each new mission? At some far distant time that may be possible. Perhaps a shorter term approach would be to focus on the system to conceptualize and to design operations systems faster, better, and cheaper? This concept is an analog of the Toyota realization that setup times, which had previously been assumed to be fixed, were in fact variable and could be improved. This led to the concepts of just in time and task interleaving which they then designed. This also leads to the concept of concurrent design expoused above in the section "A View Of Design." Note that the COSTLESS concept of reusable and multiuse operations products fits within the framework of developing a system to develop mission operations systems.

The above means of reducing cost have all been proven effective and are currently in use. There is no reason to believe that they are the only means of reducing cost. They just represent a sample of the state-of-the-art.

Examining the above means of cost reduction we can see that each is an action of an organization. Each reduces the effort required to bring forth, sustain, or retire a product (service). Thus each is consistent with the definition of cost as the measure in monetary units of the work of human endeavor. Each of the above requires the design and implementation of a process to accomplish the cost reduction. Thus each is consistent with the concept that low cost must be designed into the product. Since management controls the processes of the enterprise, to design low cost into the products requires management ensure the design and implementation of the enterprise to design for low cost. It is, thus, the nature of the enterprise designed and implemented by the management team which controls the cost of the products of the enterprise. A smart buyer, thus, must be able to evaluate the cost related nature of the enterprise which supplies the product, as well as the established cost trend of the product.

Thinking about Operations in Terms of Cost

Einstein understood very well that how one thinks about something can very well determine the success or failure of an endeavor. He, in fact, studied tensor analysis for seven years in order to be able to obtain the language in which he could both state and solve the problem of general relativity. Following the thoughts of this master, we need to think about NASA operations in terms of a language which expresses cost naturally.

Since cost is a measure of the work required to accomplish a purpose, the language of functions is a natural way in which to think about both operations and cost. A function is an active verb and an object in the form {verb,object}. The verb represents the action taken upon the object. The top level function of a NASA mission is {do,mission}. In order to {do,mission} we must

{do,mission}
{conceptualize,mission}
{evaluate,mission}
{design,mission}
{prototype,mission}
{test,mission}
{produce,mission}
{deploy,mission}
{operate,mission}
{support,mission}
{evolve,mission}
{retire,mission}
{manage,mission}

The mission is the entire system which includes hardware, software, people, process, structure, organization, and purpose. The mission is driven by the purpose of the mission which is the function {do,something}. In a system engineering process we must now deploy this function to lower levels which are functions which represent the means of doing the something. For example:

{colonize,Mars}
{develop,subsystems}
{launch,spacecraft}
{fly,spacecraft}
{land,spacecraft}
{deploy,colony}
{operate,colony}
{support,colony}
{evolve,colony}
{retire,colony}
{manage,colony}

Note that the top level function clearly states the purpose of the mission, which is to colonize Mars. The second tier of functions is a set of functions which are both necessary and sufficient to accomplish the purpose. They are the means by which we will colonize Mars. The implementation of the function {colonize,Mars} is the activity (colonize,Mars) which generates the cost associated with the colonization of Mars. This is also true for all lower level functions. This language permits us to directly map cost to purpose and to the activities which implement the purpose. The cost of an activity is a direct measure of the effort of human endeavor expended to implement the purpose of the function which the activity implements. We now know how much its costs to do something.

If we now consider each second tier function as a purpose, we can deploy it to the next lower level by determining the means by which we will accomplish the function. This process can be applied recursively until the lowest desired level is reached. This is a standard systems engineering functional decomposition implemented as a systematic diagram.

Now on to operations as defined by COSTLESS. In terms of the above functions, it is not clear what COSTLESS means when it discusses operations. Sometimes it seems that COSTLESS means that operation is the implementation of the functions {deploy,mission}, {operate,mission}, {support,mission}, {evolve,mission}, {retire,mission}, and {manage,mission}. At other times COSTLESS seems to imply that operations is only an implementation of a subset of the second tier of functions for {operate,mission}. COSTLESS needs to unambiguously define the functions encompassed by "operations". This is equivalent to defining the purpose of "operations" an deploying in to the next level of means to accomplish that purpose. Only then will COSTLESS really know what must be done by "operations." I also assume that "operations" is the organization which conducts the activities which implement the functions encompassed by "operations." This needs to be clarified.

For the moment we will assume that "operations" is the system which implements the functions

{do,operations}
{deploy,mission}
{operate,mission}
{support,mission}
{evolve,mission}
{retire,mission}
{manage,mission}

In order to enable {do,operations} we need the additional function

{genopersist,operations}
{conceptualize,operations}
{evaluate,operations}
{design,operations}
{prototype,operations}
{test,operations}
{produce,operations}
{deploy,operations}
{operate,operations}
{support,operations}
{evolve,operations}
{retire,operations}
{manage,operations}

This may be deployed further as

{genopersist,operations}
{conceptualize,operations}
{conceptualize,{deploy,mission}}
{conceptualize,{operate,mission}}
{conceptualize,{support,mission}}
{conceptualize,{evolve,mission}}
{conceptualize,{retire,mission}}
{conceptualize,{manage,mission}}
{evaluate,operations}
{evaluate,{deploy,mission}}
{evaluate,{operate,mission}}
{evaluate,{support,mission}}
{evaluate,{evolve,mission}}
{evaluate,{retire,mission}}
{evaluate,{manage,mission}}
{design,operations}
{design,{deploy,mission}}
{design,{operate,mission}}
{design,{support,mission}}
{design,{evolve,mission}}
{design,{retire,mission}}
{design,{manage,mission}}
{prototype,operations}
{prototype,{deploy,mission}}
{prototype,{operate,mission}}
{prototype,{support,mission}}
{prototype,{evolve,mission}}
{prototype,{retire,mission}}
{prototype,{manage,mission}}
{test,operations}
{test,{deploy,mission}}
{test,{operate,mission}}
{test,{support,mission}}
{test,{evolve,mission}}
{test,{retire,mission}}
{test,{manage,mission}}
{produce,operations}
{produce,{deploy,mission}}
{produce,{operate,mission}}
{produce,{support,mission}}
{produce,{evolve,mission}}
{produce,{retire,mission}}
{produce,{manage,mission}}
{deploy,operations}
{deploy,{deploy,mission}}
{deploy,{operate,mission}}
{deploy,{support,mission}}
{deploy,{evolve,mission}}
{deploy,{retire,mission}}
{deploy,{manage,mission}}
{operate,operations}
{operate,{deploy,mission}} = {deploy,mission}
{operate,{operate,mission}} = {operate,mission}
{operate,{support,mission}} = {support,mission}
{operate,{evolve,mission}} = {evolve,mission}
{operate,{retire,mission}} = {retire,mission}
{operate,{manage,mission}} = {manage,mission}
{support,operations}
{support,{deploy,mission}}
{support,{operate,mission}}
{support,{support,mission}}
{support,{evolve,mission}}
{support,{retire,mission}}
{support,{manage,mission}}
{evolve,operations}
{evolve,{deploy,mission}}
{evolve,{operate,mission}}
{evolve,{support,mission}}
{evolve,{evolve,mission}}
{evolve,{retire,mission}}
{evolve,{manage,mission}}
{retire,operations}
{retire,{deploy,mission}}
{retire,{operate,mission}}
{retire,{support,mission}}
{retire,{evolve,mission}}
{retire,{retire,mission}}
{retire,{manage,mission}}
{manage,operations}
{manage,{deploy,mission}}
{manage,{operate,mission}}
{manage,{support,mission}}
{manage,{evolve,mission}}
{manage,{retire,mission}}
{manage,{manage,mission}}

We now have a function breakdown structure to which we can map the cost of the associated activities. If we replace {} with () above, we have the associated activity breakdown structure.

The cost of operations is the cost to genopersist operations.

Note that the above cost structure is implementation independent. It is, thus, a framework for comparing the costs of all possible implementations of operations. Note also that, since it is systemic, it will capture the repackaging of cost as managers attempt "reduce cost" by throwing costs into another bucket. Note further that this structure implies a natural organizational structure for operations by allocating each function to an organization. The resulting organization is structured by purpose.

Satellite Operations

A first cut at satellite operations is being derived from the ECS communications satellite. This is under construction here.


References


Bibliographies

Cost Primer Bibliography


Surfing the Web

AIAA Space Operations and Support Cost Reduction Guidebook
Cost Modeling Track
Space Project Mission Operations Control Architecture


To Design for Competitive Advantage


Originated on 951121 | Improved on 960505
Author Ed Dean | Curator Al Motley