- Improving Cost Efficiency In Large Programs
- Requirements Traceability
- Baseline Cost, Schedule and Performance
- Program Risk Analysis
- The Role of Cost in Phased Procurement
- Pre-Phase A
- Phase A
- Phase B
- Phase C/D
- Phase E
- Selling the Program
- Cost Estimating
- Defining the Program
- Work Breakdown Structure
- Managing the Program
- Design to Cost
- Design to Life Cycle Cost
- Change Control
- Managing Cost Reserves
- Traps and Pitfalls
- Buying In
- Design to Budget
- The UPN System
- The Cost of Operations
- The Institution and the Program
- Maintaining the Institution
- Management Stability
- The Tyranny of Experience
- Does It Matter?
- Can Anything Be Done?
by John D. Hodge
This paper examines the question of cost, from the birth of a program to its
conclusion, particularly from the point of view of large multi-center programs, and
suggests how to avoid some of the traps and pitfalls. Emphasis is given to cost in the
systems engineering process, but there is an inevitable overlap with program management.
(The terms systems engineering and program management have never been clearly defined.) In
these days of vast Federal budget deficits and increasing overseas competition, it is
imperative that we get more for each research and development dollar. This is the only way
we will retain our leadership in high technology and, in the long run, our way of life.
One of the most vexing aspects of managing large programs within NASA (or any other high technology government programs) is
how to allocate program funds in a way that is best for the program. One of the major
reasons is that the role of cost changes through out the phases of the program. Another
reason is that total cost is not all that easy to de fine; yet another is that funding,
which is based on annual appropriations, is almost never consistent with fiscally
efficient program spending rates. The net result is that program costs almost always
escalate and inordinate time is spent controlling costs at the expense of maintaining
performance or schedule.
Many studies have tried to address this problem. They show that program costs will
escalate by at least a factor of three, from approval to completion. The studies suggest a
number of guidelines that should be followed if costs are to be kept down, including clear
definition of requirements, stable management and strong central control. Unfortunately,
these factors are not always under the control of the program manager.
The principles are simple. First, define very carefully what it is you are trying to
do. Check everything you do against that baseline, even if it has to be changed, and
resist change once the decisions have been made. Second, break up the program into
manageably sized deliverables that can be measured in terms of cost, schedule and
performance, and define the interfaces between them. Third, continuously assess the risks
to success as the program proceeds, and modify only as necessary.
Most studies have shown that the primary reason for cost escalation is that not enough
time or resources are spent in defining the program. It is clear that you cannot control
what you have not or cannot define. It is during this period that some of the most elegant
systems engineering should be performed, especially in understanding the cost of every
requirement and its systems implication. Even if the definition is adequate during the
early phases of the program, it is imperative that great vigilance be exercised in
maintaining the baseline definition of the program and the fundamental reasons for doing
the program.
This process establishes a small but influential part of the program office, preferably
within the systems engineering organization. The program office must be dedicated to the
traceability of requirements and to ensuring that a clear path exists from program
rationale to program requirements to systems requirements to systems design. Too often,
once a design has been established, changes are proposed and enacted that bear little
relationship to the original premises of the program. As will be discussed later in this
paper, there are many reasons for change, but where possible, changes should be considered
during the formulation of the program and not later when the program structure is in place
and the program is in progress. Change is almost always costly; requirements traceability
provides a bulwark against which the program manager and the systems engineer can stand
and defend.
The three main parameters in the control process--cost, schedule and performance-- are
the program manager's bread and butter. Again, program definition is vital and necessary
from the very beginning. It may be argued that clear definition is not possible,
particularly early in the program; nevertheless, an approved, traceable baseline, although
it may alter, must be known at any given time, and must include everything in the program.
The "I forgots" can kill you. The key to success in handling these three
parameters is to manage the balancing act between them. Cost, schedule and performance are
usually dependent variables and at various times, one or another may assume greater or
lesser importance. A single variable, however, should never be changed without knowing the
impact on the other two. Within the NASA culture,
performance is generally the predominant factor, and schedule is a distant second. Cost
tends to be considered mostly in the context of the annual appropriation, but from the
point of view of the program manager, all three parameters must be defined and approved
continuously, which is a function of the systems engineering process.
In recent years, especially since the Challenger accident, program risk analysis has
come to be used largely in the context of crew safety, but this is only a part of program
risk. Basically, program risk analysis assesses the probability of meeting requirements as
changes occur. A number of analytical tools now available can be used to under stand the
relationships between cost, performance and schedule. Again, a small group within the
systems engineering organization should be dedicated to understanding the impact of any
change on all three parameters. Armed with this information, risk can be reduced in many
ways. Adding more money, reducing the performance requirements, or extending the schedule
are most often used. A competent systems engineer will know the relationships between
these three variables and the impact of any situation on the total program.
The most common form of procuring high technology capability within the Federal
Government is known as phased procurement. The theory behind this procurement method is
that commitment to the program gradually increases with time and in discrete stages.
Within NASA, there are four standard phases; others are
beginning to creep in as the ability to establish new programs becomes more difficult and
the duration and cost of operations becomes a more significant part of total program
costs. The role of cost is different in each of the phases. The phases are:
This is a very unstructured period that examines new ideas, usually without central
control and mostly oriented toward small studies. This period can last for a decade or
more and produces the list of ideas and alternatives from which new programs are selected.
Sometimes called the feasibility phase, this is a structured version of the previous
phase. Usually a task force or program office is established, and multiple contracts will
be awarded. The goal of this phase, which may last for several years but usually is
limited to one or two years, is to decide whether a new program will be started and what
its purpose and content should be. This phase represents less than one percent of the
total program costs. Nevertheless, it is largely a systems engineering effort and sets the
stage for everything that follows.
Sometimes known as program definition, this phase is the most important in establishing
the basic parameters of the program. By the time this phase is finished (a period of two
or three years), the program rationale, cost, schedule, performance, management style and
the most likely technical solution will have been established. This phase usually involves
multiple contracts to establish a variety of ideas and a competitive environment, should
the program proceed. Cost is continuously assessed as a function of design solutions
relative to basic requirements. Studies indicate that from five to ten percent of the
total program costs will need to be expended if control is to be maintained over the
program during Phases C and D.
Originally separate phases, this period covers design, development, test and
evaluation. Contracts may be open to all qualified bidders or only to those involved in
the previous phase. Although competition is not usually open between Phases C and D,
commitment to Phase D depends on a successful and acceptable design. In past programs, two
thirds of the total program cost was expended during this period. The systems engineering
role has begun to shift to ward systems specification and systems interfaces. The secret
to cost control is a sound definition of end items and their interfaces with a tight hold
on changes.
In most past programs, the operations costs were less than 20 percent of the total
cost. This was because there was a definite end to a relatively short-term program. In
recent years, particularly in the manned programs, the length of the operational phase has
increased significantly. In the case of the Shuttle, it could
be conceived as indefinitely long. For this reason, life cycle costs should be a major
consideration from the beginning.
The definition of a new start within NASA varies by
program and organization but can generally be said to occur at the beginning of Phase B.
Prior to that time, the program manager is selling the program. The total expenditure of
funds during the selling period is usually far less than one percent of the final program
costs; this is, however, when the basic parameters of the program are established. It is a
time of building constituents both inside and outside the Agency. Assuming that a feasible
technical solution is available and an acceptable management scheme can be provided, much
of the debate about whether a program should be approved centers largely around the
question of cost. Of course, with only preliminary designs available, only cost estimates
can be made and these are obtained from standard cost models.
During Phase A of the program, when the most rudimentary designs are available, it is
essential that program cost estimates are made before the program start can be authorized.
Estimates are made using cost models that have been developed on the basis of past
experience on similar programs. These models are among the most arcane devices invented by
engineers, so a few words on how they work are appropriate.
Past experience is captured by documenting the cost of each system on the basis of
weight. Regression analysis is performed to determine a straight line log relationship.
Once the weight of the system has been estimated, the cost can be determined. This
estimate is multiplied by a complexity factor to allow for the risk associated with the
selected technology and may vary from as little as 0.50 to 2 or more. This is repeated for
each system, and the total becomes the baseline cost. This total is multiplied by a factor
to al low for systems engineering and testing by the prime contractor. This is known as
the "prime wrap" factor and is again determined based on all relevant past
experience.
All prime contractor estimates are added and then multiplied by a second factor known
as the "non prime wrap." This is the cost of government work. Finally, a reserve
factor is used to allow for problems during the program. There are separate cost models
for manned and unmanned programs, which are significantly different. In general, for the
unmanned programs, about 40 cents of every dollar goes to hardware, and in the manned
programs, about 20 cents.
These cost models pose a great many problems. First, they are normalized on the basis
of weight. Clearly this is not valid in all cases, particularly structure. Second, they do
not explain why the costs are what they are. Factors such as management style, procurement
strategy and test philosophy are not differentiated. Third, they include all past
experience, including errors and overruns. In this respect, these cost models assume no
learning curve. As it was in the beginning, is now, and forever shall be! They must there
fore be used with great caution. From the systems engineer's point of view, these cost
models can be used to assess the relative costs of various design solutions; on an
absolute basis, however, they are of little use.
So far we have been able to make a tentative estimate of the cost of the flight system.
To this must be added the cost of new facilities, including launch, test beds, flight
operations, networks and data reduction, among others, and finally the cost of operations.
It is at this point that the program manager faces the first dilemma: What should be
included in the program cost? That sounds like a simple question, but it is complicated by
the fact that not all costs are under the control of the program manager, nor is he or she
responsible for justifying all of the associated appropriations.
For example, launch costs are provided by the Office of Space Flight, network costs are
provided by the Office of Operations, and civil service costs are provided by the research
and program management fund managed by the Office of the Comptroller. New buildings are
provided under the construction of facilities budget. In addition, most new program
managers are surprised to find that a tax based on the number of civil servants working on
the program varies from Center to Center, and neither the number of people nor the level
of tax is under the control of the program manager. Taxation without representation!
Despite this dilemma, the systems engineer should include all of these factors in the cost
estimate because the chosen design will affect all of them; overall program costs are as
important to the Agency as direct program costs.
Program costs tend to be presented as only those costs that are under the control of
the program manager. No matter how much this limitation is stated in presentations, it is
assumed that it is the total program cost (especially when it is a popular program) that
has the support of the Executive branch, the Congress and other constituencies. It is no
wonder that the average program increases in cost by a factor of about three from the time
of approval to completion and that most program managers during this period are accused of
everything from naiveté to self deception to outright lies. There is the added ethical
question that if all costs were actually presented, the program would not be approved!
This phase of the program, usually known as Phase B, will take from one to two years.
The purpose is to take the various concepts considered in Phase A and select a single
valid solution. By the time Phase B is over, a clear set of requirements should be
available with a complete set of functional specifications and a cost estimate based on
preliminary de sign concepts rather than on cost models. These are primarily produced by
the systems engineering organization and include at least one preliminary design and
selected technologies with well-understood risks associated with those technologies.
Don Hearth, former director of the NASA Langley Research Center, performed a study on how
much this phase has cost for various past programs as compared to the success of the
program in later phases. Success was measured as the ability to maintain performance,
schedule and cost as determined at the end of Phase B. He concluded that the most
successful programs spent between five and ten percent of the total program cost in Phase
B. The scope was limited to unmanned programs, but the rationale can reasonably be
extended to manned programs.
Apart from establishing a credible functional system specification, it is essential to
determine the management structure, the procurement strategy and a baseline cost for the
life of the program, including the cost of operations. Once again, the primary method for
cost estimating is the cost model, but there should be sufficient detail available to
check the model with bottom-up costs based on feasible design solutions. The systems
engineer is responsible for comparing these two cost estimating techniques. It is unwise
to proceed to the next phases unless some bottom-up cost estimating has been per formed.
Perhaps the most important product of this phase is a complete work breakdown
structure. Again, this is largely the responsibility of the systems engineering
organization. The axiom to be followed is, "You cannot control what you have not
defined."
Too often a program will be approved without a well-established work breakdown
structure (WBS) describing the whole program, which
inevitably results in large cost overruns. The WBS is the
basis for the procurement strategy and often for the management structure. Without it,
program changes will take place after the contractors are in place and have to be paid.
Overlaps between contracts, as well as missing elements and contract changes, are always
expensive. The following simple rules have to be followed:
1. Each element of the WBS should contain a deliverable
that can be defined.
2. The sum of the WBS elements must be the total
program. (Note that a given program manager may not have the responsibility for all
elements, but they should each be defined and allocated.)
3. Each deliverable should be accompanied by a cost and a schedule. The cost should
include a reserve based on the estimated risk associated with that element, and the cost
should be allocated to that element.
As simple as these rules sound and as much as NASA
requires contractors to adhere to them, the internal track record is dismal. We can go a
long way toward containing costs if discipline is established early and maintained.
One last word of caution. A WBS element should never be
established on the basis of function or organization. These elements are not end items.
Other mechanisms exist for identifying these elements, which in general could be defined
as program overhead and not entirely the responsibility of the program manager. They
should be recognized for what they are and identified, but they should not be included in
the WBS.
We have now reached the time in the program when promises have been made, deals have
been struck, and the program has been approved. All that remains is to deliver. A custom
within NASA stipulates that new managers are instilled
with the belief that the skills required to sell a program and to define it are different
than those required to run it. Certainly some changes can be expected, but I believe that
such changes are better if they occur sometime after a phase has been entered and the
basic management structures have been established. What the program needs at this time is
ownership of the concept, and changes in management will usually result in program changes
that inevitably will lead to increased costs. This is particularly true of the systems
engineering group that has carefully balanced the requirements against the design and is
familiar with the "why" of a decision as well as the "what." So far
the total expenditure has been relatively low, but once the contractors are onboard and
the manpower begins to build up, costs can escalate at an alarming rate. In a very short
time, increases or decreases in performance, extensions or reductions in schedule, and
decreases in annual funding will all increase cost.
There is much talk about design to cost but very little action, and for this there are
a number of reasons. Earlier, I mentioned that within NASA
there is a tendency to order the three variables by performance first, schedule second,
and only then worry about cost. So by tradition, cost tends to be put on the back burner.
One of the reasons for this is that during the Apollo program, the cost
function was transferred to the budget and program control groups. In a program where the
technical problems were so difficult and the budgets were ample, this was understandable,
but this is no longer the case. This situation resulted in a shift away from making the
design engineer accountable for cost as well as performance and schedule.
The second problem occurs when the cost is not allocated at the WBS element level, where it can readily be traded against
performance and schedule and easily traced. I believe that cost must be allocated to the
lowest possible level (a little scary for the program manager), but unless this is done,
it will be impossible to hold the designer ac countable and unlikely that overall costs
will be held in check.
The third problem is that in an organization that prides itself on technical
excellence, it is very difficult not to make things a little better; consequently, there
are always plenty of ideas around. The credo of the systems engineer should therefore be:
"The better is the enemy of the good."
Over the past decade, the operational costs of NASA
programs have steadily risen as a percentage of total program costs, largely due to the
fact that programs have a longer life in the operational phase. Whereas 20 years ago
operational costs amounted to no more than 20 percent of costs, they are now approaching
half of the NASA budget. It is time to place design to
life cycle cost on an equal footing with design to cost. The dilemma is that a design that
allows low-cost operations will usually demand higher development costs and in turn, this
means larger front-end program costs. It is essential that the systems engineer make these
assessments. The simplest thing for a program manager to do is walk away from this dilemma
and let the operations people worry about it later. As this is becoming an overall problem
for the Agency, the ability to make new starts will depend on the ability to ensure that a
sufficient percentage of the budget is available for operations.
Unfortunately, it is difficult to get enough operations people to participate early in
the program, but I believe it is essential. Some kind of veto power should be established
when it comes to making design decisions; too many program managers do not feel
responsible for operations costs and perhaps, what is worse, are not held accountable for
it. Let there be no doubt that operational costs are unacceptably high. An operational
concept must therefore be developed early enough in the program to have an effect on the
design process.
Once a program is under way, the program manager's responsibility is controlling
change, which is inevitable. Earlier I said that you cannot control what you have not
defined. It is equally true that you cannot control changing something that is not
defined. First know what it is! A complete WBS with
allocated schedule and cost is, once again, the key. Change requests must not be limited
to solving a technical problem. They must be accompanied by cost and schedule impacts and,
just as important, life cycle cost impacts.
In addition, there is always a rippling cost impact caused by change. Other WBS elements may be affected, including items in different
contracts or in totally different NASA codes, or line
items. For these reasons, change must be assessed at the systems engineering level as well
as at the WBS level. Perhaps the overriding rule is that
changes should be difficult to approve but easy to implement once the decision is made.
A qualified cost estimator would not let a program get started without making provision
for cost over-runs or reserve. The many uncertainties in a development program make it
essential. An analysis of past programs allows a fairly ac curate estimate to be made of
what is a reasonable total amount as a percentage of total costs, assuming that the
programs are similar. Determining how and when the allowance should be allocated is much
more difficult. One school of thought says that reserves should be held at the highest
level in the program and applied only to correct unforeseen occurrences. The problem is
that this tends to bail out poor performers.
I believe that the reserve should be determined based on the perceived risk of the
element when the WBS is formulated. The manager of the
element should then be held responsible for the stewardship of the reserve. In order for
this to work, some sort of reward system must be established for the manager who does not
spend the reserve. In any case, it would be prudent to maintain some reserve at the
central level for those things that cannot be anticipated. Just to keep the system honest,
a very simple tracking program can be established to follow the expenditure of the
reserves at the WBS element level after the fact. I would
like to see an in-depth study done on this subject.
So far we have talked about where cost fits into the program management and systems
engineering processes. There are a few areas that may catch the program manager unprepared
and a few ideas that may be used to make life a little easier in the future. It may not be
possible to implement all of them, but it is worth a try.
If you are involved in the selling of the program, the easiest trap to fall into is
under-pricing the program. Despite stories to the contrary, I do not believe that this is
a matter of deliberate low bidding. Although I once heard a distinguished gentleman say
that we do business the old fashioned way, we do underbid and make up on change re quests.
The fact is that every program manager I have ever met was convinced that he or she could
do it for less than the past record would suggest. Unfortunately, this usually involves
changing the way we do business. I believe that there are less expensive ways, but you
should tackle this one at your own risk and only if you have the support of the very top
of the organization. The systems engineer must be the conscience of the program manager
during this period.
Let us assume that we have completed a perfect Phase B and that everything is in place,
including the rate of expenditure by year. It is a virtually certain that two things will
happen. First, with eloquent rationales and spreadsheets by the ton, the various element
managers will find a need to increase their funding allocation. One favorite argument will
be that the sellers of the program, who are no longer in charge, will be blamed for not
understanding the problem. In addition, Congress may add a requirement or two.
Second, the budget will be cut in the Agency, at the Office of Management and Budget,
and finally in Congress. At this point, the intricate patterns of dependency between
performance, cost and schedule begin to unravel. In the first year, this is not
devastating because you can always delay bringing the prime contractors on board. But by
the time they arrive, the trap has been set for the most insidious form of management, de
sign to budget. Unfortunately, a fact of life is that very few research and development
programs have multi-year funding, and annual budgets will be less than planned. The net
effect is that program costs will escalate, and enormous pressures will attempt to bring
down the annual funding.
The first remedy is to stretch the schedule, and the second is to reduce the scope of
the program. You will no doubt find yourselves in this position, and you will receive a
great deal of advice from the non participants, but you should beware of
"de-scoping." A cursory examination of the cost models will show that in the
manned programs, only 20 cents of every dollar go to hardware. (In the unmanned programs,
the number is closer to 40 cents.) Once the management structure is in place and the
contracts have been awarded, virtually all of the other costs are fixed or very difficult
to reduce. Take out all the con tent and the program cost will still be 80 percent of the
estimate! The lesson is that if you are forced to remove content, you should be sure to
take out every cent that is associated with that content: prime wraps, non prime wraps,
test beds, personnel, and, if necessary, the kitchen sink. It will be difficult to find,
but it will be worth the effort.
If this were a mystery novel, it might well be called "The Case of the Missing 80
Percent." Where does it all go, and why is it only 60 percent for unmanned programs?
Much of this is valid and accounts for systems engineering and integration at all levels
of the program, including test and evaluation, operations, and many other things. But it
also accounts for duplication of test facilities, overlaps between assignments, management
style, inefficiencies and a host of hidden costs associated with maintaining the
institutions that are often invisible to the program manager. The systems engineer is
responsible for ferreting out the good from the bad. It is a simple fact that the first
one per cent reduction in these wraps (80 percent to 79 percent) increases the amount of
hard ware by five percent (20 percent to 21 percent)! A 20 percent improvement in the
wraps (80 percent to 60 percent) results in a doubling of the hardware (20 percent to 40
percent) or cutting the program costs in half for the same amount of hardware!
"Thar's gold in them thar hills."
The NASA budget is prepared and submitted using a
system of breakdowns known as the unique project number (UPN) system. All parts of the
Agency are required to report their annual needs on the basis of this system, including
the program offices. From a program point of view, a fatal flaw in this process is the
numbering system, which generally describes functions rather than end items and is there
fore not in consonance with the principles of a WBS
system.
It is essential that the program manager be able to trace the equivalence of the UPN number and its corresponding WBS
element. This will require a joint effort between systems engineering and the program
control people. Without this traceability matrix, the program manager will not know what
is being asked for or where the money is going. Too often the UPN
number is perceived as directly equivalent to the WBS
element, but this is very seldom the case unless the WBS
is not end-item oriented. (The latter happens more often than it should.) One way to avoid
this situation is to make the annual budget call for the program using the WBS system and then translate it to the UPN system for the purpose of aggregating the total NASA budget. I have never seen this happen.
I mentioned earlier that the costs of operations are now about 50 percent of the NASA budget. This is partly due to the increase in the
operational life of a program and to the fact that we have not learned to design systems
for operability. It has not been necessary in the past. It is also true that the
productivity of the operations infrastructure has not been high on the program manager's
list. If we are to reduce total program costs, which are vital to the Agency and to the
program, it is time to strike a new level of cooperation between these two normally
separate parts. The program and the systems engineer must assume a large part of the
responsibility.
Although not directly related to the systems engineering process, a number of things
bear directly on the program and have a major effect on the ability to perform the various
program functions. These generally concern the relationship between the program and the
institution. NASA was originally established using the
resources of the National Advisory
Committee for Aeronautics, known as NACA, an
aeronautical research organization that was seldom involved in large development programs.
The budget was relatively small, and there were few contractors. In fact, all contracts
were signed at the Washington office, the NACA equivalent
of Headquarters.
It quickly became apparent that, in addition to the research centers, a development
center was needed. Goddard Space Flight Center (GSFC) was established to perform this function. This was
rapidly followed by the Lyndon B. Johnson Space Center
(JSC) in Houston, the George C. Marshall Space Flight Center (MSFC) in Huntsville, and the Jet Propulsion Laboratory (JPL)
in Pasadena. Almost immediately, GSFC and JPL became responsible for multiple unmanned programs, which
were largely contained within a single Center, and JSC and
MSFC became responsible for multi-center manned programs.
In both cases, program offices were established and the Centers provided the resources,
both personnel and facilities, to support the program.
With the exception of JPL, which is a Federally funded
research and development center and operates outside the civil service system, all NASA personnel and basic facilities are funded separately
from the programs in line items known as Research and Program Management (RPM) and Construction of Facilities (CoF). Program-specific facilities are funded by the program
and these facilities are most often operated by support contractors, also funded by the
program. This system was established so that the programs would be managed by government
personnel who would rotate from program to program and carry their experience with them.
This worked very well until the late 1960s when the budget began to fall rapidly, and
there was a significant reduction in NASA personnel.
By the early seventies, both the budget and the number of personnel had been cut in
half, but the number of Centers remained essentially the same. The cost of maintaining the
institution could no longer be sustained by the RPM and CoF line items. The solution was to tax the programs based on
the number of personnel that were applied to the program. Unfortunately, the program
manager does not decide how many people should work on the program, which, by tradition,
is the responsibility of the Center director. Neither does the program manager participate
in determining the level of the tax. These decisions, again by tradition, are made by the
comptroller.
Unless the basic system of funding personnel is changed, the programs will most
certainly be responsible for funding some of the institutional costs that are not related
to the program; the RPM budget will never be allowed to
grow to compensate for this. The question is rather how large the institution needs to be
to support the program and how that decision is made. I mentioned earlier that the WBS should represent the totality of the program and should
always describe deliverables; this problem runs counter to that principle. I believe that
the solution lies in accepting this cost for what it is, negotiating the level of tax with
the program manager for the duration of the program, and taking it off the top each year.
It may not be controllable in the normal sense, but at least it is a known number.
Personally, I believe that the Agency would be better served if the development centers
were managed using an industrial funding system similar to JPL
and many other government facilities, including the Navy
labs. But until that happens, it will be necessary to find some balance between the
institutional and program needs.
Every program will change management during its life cycle. The common practice in NASA has been to make these changes deliberately between
phases. It is not uncommon to see as many as four different managers during a program,
including a specialist in closing off completed programs. The positive side to this is
that it is possible to match the needs of each phase of a program to the special
capabilities within the Agency. The negative side is that each manager has a different
style, each program has different management needs, and often these do not match when the
changeover occurs between phases. One way is not always right and an other always wrong,
but each is different, and changes even in management style can, and usually do, increase
the cost of the program. The secret then is to stick with a team as long as possible,
particularly the systems engineering team, something that is easy to say and difficult to
do in these times of declining internal expertise and increasing retirements.
Too often, you will find resistance to change in the way things are done. "We have
always been successful (measured by performance) doing it this way, and its very dangerous
to change winning ways." "If it ain't broke, don't fix it." "You get
no credit for an on-time failure." All true and at the same time, destructive to
valid new ways of doing business, especially when it comes to introducing more efficient
or less expensive ways. When the space program started, we had no experience and what
followed was the most innovative and exciting period in the history of high technology
programs. But now we have all that experience, and it has become a burden. By all means,
you should keep the wise heads around (they may still save you), but take advantage of the
explosion in new technologies and capabilities, which allows for things that we could only
dream of 30 years ago. You should be careful before you introduce a change, but you should
not dismiss it out of hand.
We have been in the civilian space business for almost 40 years, and time after time we
have shown that we can rise to any challenge and lead the competition, provided we have
the resources. Time and time again the Federal Government has provided the resources. We
have been the envy of the world. We have written the book on the subject, both from a
technical and a management sense.
Until now, it was enough to know that we were the best. There was no established
competition, most of the money was spent internally, and cost efficiency was second to
performance. Some have characterized it as a Works Projects Administration (WPA) for the
technologists! The problem is that in this era of budget deficits and trade deficits,
there is not enough discretionary money to go around. Even without international
competition, it would be imperative to get more out of our research dollars. The trouble
is that we have learned profligate ways, as neither the government nor the contractors
give rewards for cost efficiency. While we were basking in this glory, the rest of the
world has been catching up; they have read the book. The competition, supported by their
governments, is getting good and fierce.
But there is a difference; the competition believes that the space business is here to
stay. I said space business, but I meant commerce, and in commerce cost efficiency is
paramount. Do we still want to stay at the top, or are we ready to leave it to the rest of
the world? Are we prepared to do what is necessary to stay in the game? After all, it's
only a space program. Does it matter? You bet!
In this paper, I have attempted to show where cost fits into the space program's
engineering and management business. A combination of things have placed cost at the
bottom of the priority ladder except in matters of the inexorable annual budget. There are
many ways to improve cost efficiency, some of which are available to the program manager.
In the long run, it will take a concerted effort by all of us to make a difference. The
Executive branch and Congress, together with industry and academia, must work as before,
when we perceived that we were second. In the meantime, I hope that I have been able to
give the budding systems engineer and program manager a few tips to do something about the
problem of cost considerations. We can only do something about it if we want to!
Reprinted from "Readings in Program Control," edited by Francis T. Hoban,
William M. Lawbaugh and Edward J. Hoffman, NASA SP-6103, National Aeronautics and Space
Administration, Scientific and Technical Information Office, Washington, DC, 1994. |
|
