A Guide to Pursuit, Capture, and

Management of Unprecedented
or High Technology Projects

By Evin Stump.

Page ii of 199
About the Author
Evin Stump has had a varied career of over 60 years in the aerospace and
construction industries. In the aerospace industry, he has been a laboratory test
engineer, flight test engineer, flight test instrumentation design engineer, cost engineer,
systems engineer, project engineer, or engineering supervisor in seven major
aerospace companies. As a consultant to three major aerospace companies, he has
led or played a key role in proposal writing or pricing. In the construction industry, for
two years he consulted as a trainer for a major international oil company in construction
project risk management. For five years, he coordinated construction proposals and
prices to the government of a Middle-Eastern country. For two years he managed a
mechanical contracting company, specializing in commercial buildings. For the past
twelve years he has divided his time between assisting companies with proposals and
building mathematical models for project cost and risk analysis.
Mr. Stump holds the BS in Engineering (mechanical) from Loyola University of Los
Angeles, and the MS in Operations Research and Industrial Engineering from the
University of Texas at Austin. He also holds the Professional Designation in
Government Contract Management from UCLA / NCMA. He is a member of Alpha
Sigma Nu Jesuit National Honor Society. Prior to his recent retirement, he was a
registered professional engineer (Texas) and was certified as a Cost Estimator / Analyst
by the Society of Cost Estimating and Analysis. He is a past president of the Southern
California chapter of the International Society of Parametric Analysts.
Distributed by Galorath, Inc.

Page iii of 199

Rights in this work

This Work is copyrighted by the author, effective January, 2010.
The author hereby provides all persons including You a worldwide, royalty-free, nonexclusive, perpetual license to exercise the rights in this Work as stated below:
a. to Reproduce the Work, to incorporate the Work into one or more Collections,
and to Reproduce the Work as incorporated in the Collections;
b. to create and Reproduce Adaptations provided that any such Adaptation,
including any translation in any medium, takes reasonable steps to clearly label,
demarcate or otherwise identify that changes were made to the original Work.
For example, a translation could be marked "The original work was translated
from English to Spanish," or a modification could indicate "The original work has
been modified.";
c. to Distribute and Publicly Perform the Work including as incorporated in
Collections; and,
d. to Distribute and Publicly Perform Adaptations.
e. For the avoidance of doubt:
i.
Non-waivable Compulsory License Schemes. In those jurisdictions in
which the right to collect royalties through any statutory or compulsory
licensing scheme cannot be waived, the Licensor reserves the exclusive
right to collect such royalties for any exercise by You of the rights granted
under this License;
ii.
Waivable Compulsory License Schemes. In those jurisdictions in which
the right to collect royalties through any statutory or compulsory licensing
scheme can be waived, the Licensor waives the exclusive right to collect
such royalties for any exercise by You of the rights granted under this
License; and,
iii.
Voluntary License Schemes. The Licensor waives the right to collect
royalties, whether individually or, in the event that the Licensor is a
member of a collecting society that administers voluntary licensing
schemes, via that society, from any exercise by You of the rights granted
under this License.
The above rights may be exercised in all media and formats whether now known or
hereafter devised. The above rights include the right to make such modifications as are
technically necessary to exercise the rights in other media and formats. All rights not
expressly granted by the authors are hereby reserved.

Page iv of 199

About Case Histories

I have worked at several companies that are now or have been engaged in the kinds of
proposal activities described herein. These activities are typically shrouded in secrecy
either for competitive reasons or because of customer requirements, or both. For that
reason, I do not present specific case histories in the book. I also do not name any
employers anywhere in the book. I feel that to do so could be a betrayal of
confidences.
In lieu of case histories, I have written a novella that addresses many of the topics
discussed in this book in a realistic but purely fictional context. The novella is titled
Saving SEIC: An Industrial Love Story. It concerns a small high tech company called
SEIC that is struggling to survive and grow. The novella is a useful and entertaining
companion to Bid to Win!
Evin Stump

Page v of 199

Contents
Rights in this work ......................................................................................................................... iii
Preface............................................................................................................................................. 1
I Get Off to the Right Start ........................................................................................................... 8
Chapter 1Use early start business development practices .................................................. 8
Chapter 2Understand who the customer is ....................................................................... 13
Chapter 3 Understand who we are ..................................................................................... 21
II Know what your customer wants ............................................................................................ 23
Chapter 4 Learn about and influence customer goals ........................................................ 23
Chapter 5Measure customer value judgments .................................................................. 30
Chapter 6Create customer satisfaction.............................................................................. 37
Chapter 7Persuade your customer away from mistakes ................................................... 41
III Know What Your Customer Is Willing to Spend ................................................................... 49
Chapter 8Find the upper and lower bid limits .................................................................. 49
IV Design Your Project ............................................................................................................... 54
Chapter 9Use modern programmatic design techniques .................................................. 54
Chapter 10Find minimal balanced and efficient product design solutions ....................... 67
Chapter 11Apply cost containment discipline .................................................................. 73
V Bulletproof Your Proposal ...................................................................................................... 84
Chapter 12Analyze your competitors ............................................................................... 84
Chapter 13Work the toughest issue: how much to bid? ................................................... 87
Chapter 14Analyze and abate project risks ....................................................................... 93
Chapter 15Get all of the right things into your proposal ................................................ 108
Chapter 16Keep the proposal going ................................................................................ 113
VI For the Future ....................................................................................................................... 115
Chapter 17Keeping the game going ................................................................................ 115
Chapter 18The efficient bidding frontier ........................................................................ 122
Appendix A--Be all that you can be ........................................................................................... 125
Appendix B--Maintaining cost discipline ................................................................................... 146
Appendix C -- Miscellaneous tools............................................................................................. 172
Appendix D -- Cost estimating checklist .................................................................................... 186

Page 1 of 199

Preface
This book is aimed at people involved in what I choose to call advanced contracting.
Who are they? They certainly include all of the teams involved in bidding defense
contracts in North and South America, Europe, and elsewhere, as well as those who bid
contracts involved in launch and operation of systems in space. Also included are many
who bid a variety of contracts with federal or local governments, other than routine
procurements and smaller or traditional construction
Exhibit P-1 Bidding
contracts. Larger service contracts of various kinds may
Situations Where This Book
also come under this umbrella. Excluded are all contracts
May Be Useful
where the low bidder automatically wins. Some bidding
Aerospace
situations where this book may be useful are shown
nearby.
Agency
Catering
As a member of an advanced contracting project team, to
Communications
survive you must win projects in open competition. Your
Concessions
work is high tech or unique in that what your customers
Construction
want is not routine, either for you or for them. In bidding
Defense
competitions that you enter, the low bidder generally wins
Environment
the contract, but not if the bid is so low that the customer
Housing
believes it to be reckless and non-responsive, or if the low
Insurance
bid is based on a concept the customer views as not
Legal Services
meeting perceived needs.
Maintenance
Outfitting
You cant win every job you bid, but you must win your
Security
share, or risk having to go out of the contracting business.
Special Analyses
A long dry spell with no wins could be fatal.
Testing
In the bidding competitions you enter, project design is
Training
important in many ways. Project design comprises both
Transportation
the design of the deliverable product and the means you
Upgrades
choose to develop and implement it. It drives cost and
Anywhere factors other than
therefore the amount you must bid in order to be profitable.
cost influence the award
The customer must also perceive it as meeting his or her
minimum needs. Moreover, costs must have a reasonable
correspondence to benefits as perceived by the customer, not only at the level of the
total project, but also at the level of major features of the project.
On a given bid, typically you may not have a large number of strong competitors
seeking the same work, but at least some of the competitors you do have will be smart,
entrepreneurial, and resourceful. If you win, the margin by which you beat them
generally will not be large. This means that to beat them you must fully understand the
customers needs, and fully provide for them, and you must do it in a way that is highly
visible and cost effective.

Page 2 of 199
Your customers generally are astute and knowledgeable, and are able independently to
assess the quality of your offerings and the prices you ask for your product or services.
Still, they are not immune from mistake, and you must be adept at guiding them away
from mistakes that might damage them and perhaps you as well.
You perceive that your competitors get harder to beat all of the time, and you are
concerned that your win / loss ratio is suffering or will suffer. You are looking for help to
improve your chances of winning, without having to bid so low that you are likely to lose
money.
If all or most of the above is true of you, this book was written to help you. The book
distills in one place expertise and wisdom from several fields of knowledge that bear on
the problem of designing and bidding to win in a market where design and cost both
matter. It points a way for you to proceed in the direction of increased win probability,
and a better chance of long-term survival.
This book does not pretend to be a silver bullet that will slay all of your dragons and
make you a sure winner on your next project, and on every project after that. In the real
world, there is no such thing as a silver bullet; there is only continual striving to do
better.
This book certainly cannot overcome organizational sloth or ineptitude. Only eventual
failure, or a new broom sweeping clean, can do that.
Finally, this book cannot make you a successful bidder in an area of expertise where
your team has little experience or is outclassed by one or more serious competitors.
Hopefully, you are able to recognize those situations and avoid them. Or, you are
willing to invest the time and money to rise to your competitors level.
If we offer no silver bullet, just how do we help? What we offer is useful ideas
integrated into a consistent strategy, which if followed rigorously should result in your
winning at least your share of the available work. The strategy is neither magical nor
mysterious. But it is coherent and logical. As you progress through this book, we hope
and believe that you will agree that it makes sense.
You may fairly ask: What if your competitors follow this or a similar win strategy? Here
is our answer:

If they are already following such a strategy, and you are not, they are probably
winning more than their share of the work. (Are you already feeling the pain?)

If you want to win your share of the work, you must maintain your competitive edge.
This book can help whatever your competitors are doing.

Page 3 of 199

Regardless of your strategy you cant expect to win it all, all of the time. The world
doesnt work that way. In the world of biddable projects monopolies tend to have a
short life.

What are our prescriptions for successful bidding? In a nutshell, you must understand
and act upon:

The minimal project design that satisfies your customer at the lowest possible price,
considering the risks (you cant afford to lose money on very many projects).

What your customer is able and willing to pay for your project design.

How your customer values various aspects of your design baseline (the issue of
design balance).

As a prerequisite to doing these things, you should have early and frequent contact with
the customer. You must have the ability to:

Help the customer define needs.

Research the customers ability to pay.

Persuade the customer away from mistakes1.

Exhibit P-2Pursuit Cycle

CAUTION: Do not approach a customer as a mentor or an instructor unless specifically asked to do

training. It could easily be interpreted as condescending. Also, dont approach as a guru, inducing in the
customer a sense of inferiority. Tact and humility are vital. The customer is always the alpha dog. See
chapter 6.

Page 4 of 199

Moreover, you must be willing to:

Reject traditional gold-plated design solutions in favor of balanced, minimal

solutions this may be a cultural change for your creative people.

Carefully estimate and manage project risk and consistently bid near the bottom of
the competitive range this may be a cultural change for your business people.

The book discusses all of these subjects in detail. It is organized into six major sections
with a total of 18 chapters, plus five appendices.
Most businesses are cyclic in some sense. Retailers regularly have a big push at
Christmas and smaller flurries of activity at other times. The demand for gasoline slows
in winter months, but the demand for fuel oil picks up. Machine tool manufacture
typically follows a larger business cycle related to economic booms and recessions.
Some types of projects are affected by these various cycles, but companies that have
substantial propose / bid activity have a unique type of cycle of their own.
We might call it the project cycle. It may not be tied to the calendar at all, but it is
nevertheless a cycle of repeated activities. It begins with learning of a project
opportunity. If the project is ultimately lost in competition, it ends with the customers
rejection of the contractors bid. If the project is won, it ends with completion and
acceptance of the work by the customer. Small contractors may have only one project
cycle ongoing at a time. Some very large contractors may have hundreds of projects
ongoing at the same time, typically a few large, and many small.
In this book we have some interest in the overall project cycle, and it will be discussed.
But our main focus is a subset of the project cycle.
We call it the pursuit cycle.
While excellent execution of an awarded project is certainly something contractors
should be concerned about, excellent execution in the pursuit cycle is something they
must be concerned about; else they will not long survive. What is the pursuit cycle?
As its name implies, the pursuit cycle is the part of the project that extends from first hint
of a project opportunity to acquisition of the project by the contractor (the win scenario)
or rejection of the contractors proposal (the loss scenario). The ratio of wins to losses
typically is strongly correlated with the financial health of a contractor. Lose too often,
and a contractor could be forced out of business.
We call it the pursuit cycle in this book, rather than just the pursuit phase, because
we believe that the activities that lead to a competitive win probability must be cyclical in
nature. A cyclical activity can lead to much desired continuous improvement of the win
probability, while a one-time linear activity by definition cannot.

Page 5 of 199

Exhibit P-1 illustrates the pursuit cycle. In this preface we will convey only an
elementary notion of what each sub-activity is about. Later chapters will discuss them
in much more detail.
The pursuit cycle activities are not necessarily repeated in precisely the order shown in
Exhibit P-1. Typically, the order is adapted to the flow of information and the
necessities of the proposal situation. Frequently, more than one of the activities will be
ongoing at a particular point in time.
Here are brief descriptions of the activities shown in Exhibit P-1. They will be the main
focus of this book, each in its own section.
I.
Get Off to the Right Startthis section discusses early start business practices
and promotes better understanding of who the customer really is. Customers do not
always speak with one voice.
II. Know What Your Customer Wantscustomers have particular goals and values.
You need to understand them. You may be able to influence them and help your
customer avoid mistakes to your mutual benefit.
III. Know What Your Customer Is Willing to Spendthe better you understand your
customers spending habits and perceptions of appropriate costs, the more likely you
are to be a successful bidder. This section focuses on helping you identify the
competitive bidding range.
IV. Design Your Projectin a project, you do both programmatic design and product
design. Your customer is certainly interested in what kind of product you intend to
design and eventually build for him. Will it meet his needs? Is it affordable? But your
customer may also be highly concerned about your programmatic design. How will
the project be managed? Where and by whom will the work be done? What kind of
management tools will be used? How will you manage project risks? These
important issues are thoroughly discussed.
V. Bulletproof Your Proposalyour proposal will be shot at in your competitors
proposals and may be criticized by members of your customers team. You must
carefully analyze what your critics are likely to say and do and counter it to the extent
you can. One of the toughest things to do is to choose the best bid amount. This
section discusses the Best Bid model which can help you make that decision, keeping
the right balance between bidding too high and bidding dangerously low. Also
discussed are proposal content and critiquing the proposal.
VI. For the FutureThoughts on planning between proposals. More thoughts on
balancing profitability and stability.

Page 6 of 199
We also provide five appendices. They contain supplemental information that can be
helpful in a successful pursuit. They are:
Appendix A Be All that You Can Be. This appendix discusses ways the project team
can be as efficient as it can possibly be.
Appendix B Maintaining Cost Discipline. Cost discipline is increasingly important to a
well managed project. This appendix contains a thorough treatment of the subject.
Appendix C Miscellaneous Tools. This appendix discusses several very practical
tools that can help make the pursuit more effective.
Appendix D Cost Estimating Checklist. All of your hard proposal work may be for
naught if your cost estimate for performing the work is seriously flawed. This appendix
contains a checklist that you can (and should) use to guard against both under and over
estimates of cost.
Appendix E --- Risk Identification Checklists.
Most chapters of this book contain review questions. They are designed to stimulate
thinking about issues surrounding the pursuit process. Most of the questions dont have
just one set answer. The best answer may depend on your particular circumstances.

Page 7 of 199

Acknowledgements
The authors would like to express gratitude to the people who helped make this book
possible or who helped improve it.
Evin Stump gratefully acknowledges:

My wife of 49 years, Evelyn Helen Stump without whose forbearance and loyalty this
book would not have been possible.

Our sons John, Michael, and Mark. John provided comments on the book from his
perspective as a CPA and financial consultant. Michael reviewed the book from his
perspective as a manager of plant maintenance working in a highly regulated
industry. Mark is an attorney in private practice who studied the manuscript for lack
of clarity, logical disconnects, or prolix language.

And our five grandchildren Rachel, Sarah, twins Isabel and Claire, and Getty, all of
whom (still children as this is written!) helped just by being their sweet selves.

My faculty advisors at the University of Texas at Austin in the 1960s, who

encouraged me to pursue some of the key ideas in this book. They were Dr William
Lesso and Dr Gerald Wagner, both of the Department of Operations Research and
Industrial Engineering, School of Engineering. (Dr Wagner headed the department.)

My nephew Mr Alan Garrett, professional artist, writer, inventor, and entrepreneur

whose encyclopedic knowledge prevented many an error of fact, belief, or nuance.

Ms Karen McRitchie, VP of Development, Galorath Incorporated. Ms McRitchie

helped me better understand the views of professional women in leadership
positions, and how the book could be more helpful to them.

Page 8 of 199

I Get Off to the Right Start

Chapter 1Use early start business development practices
It is enormously helpful to be in on the ground floor of a new project. These two
scenarios illustrate why.

Scenario 1. You have some new ideas that you believe will be of interest to a
potential customer. Your technical2 people create a dog and pony show and visit
the potential customer to demonstrate what you can do. You bring with you not only
presentation materials but also concept sketches, a mockup or perhaps even a
functional model. Your potential customer sees value in what you have done and
enters into a dialog about how your ideas can best be adapted to his needs. Along
the way, you get an excellent understanding of his goals and how you can best
satisfy them. You give your potential customer information about likely costs and
schedules so a realistic project plan can be structured and sold internally.
Eventually, your potential customer issues a request for proposal (RFP). Because of
policy, often others must also be invited to bid. All bidders have the same, limited
number of days to submit their proposals. Your pursuit team has been working with
the customer for several months. You give your proposal a final few tweaks and
submit your bid.

Scenario 2. You are one of the bidders receiving the RFP mentioned above in
Scenario 1. The technology is within your capability, but until now you have not
been aware of this opportunity. You send a few people to the bidders conference.
You form a proposal team and submit your bid after 45 days of crash effort, with
some members of the pursuit team working all night in the last few days. Daily,
empty pizza and Chinese food takeout boxes fill the wastebaskets in the pursuit
work area.

Who is most likely to win this contract? Perhaps a better question is: should the team in
Scenario 2 even bother to bid?
The Scenario 2 team probably has little chance of winning. Even though they can read
the same RFP that goes to the Scenario 1 team, they havent nearly the detailed
understanding of what the customer wants and what his priorities are. They may have a

The words technical and technology have been much overworked in recent years. Our use of those words will
refer to any specialized body of knowledge which may be the subject of a bidding situation, where expertise in that
body of knowledge will be a factor in who wins the bidding contest. Although many technologies in this sense are
the subjects of scientific or engineering study, many are not. For example, in a bidding situation for the right to
cater food to some organization, quality, variety, nutrition, and presentation of the food could all be factors which
influence the award.

Page 9 of 199
poor understanding of the competitive bidding range. They may have an even poorer
understanding of what their efficient competitors can offer.
Between Scenario 1 and Scenario 2 lies a continuum of other possibilities. For
example, there might be a Scenario 3:

Scenario 3. Your business development people hear rumblings that one of your
customers or potential customers is getting interested in a particular idea. An
internal champion may have proposed it, or a competitor may have. But there is
definitely interest. As it happens, the interest is closely related to an area where
your company has expertise and has been doing internally funded research and
development. Your management believes this to be a growth area, and that a major
project will develop and be funded in a year or so. You form a small pursuit team to
go after it. The team visits the customer, learns about (and helps define) what the
customer wants, and has the proposal half written when the RFP becomes available.
The team has studied the competition, and has a good understanding of what it has
to offer. It also has a good handle on the competitive bidding range, and is
convinced it corresponds to reality.

While the Scenario 1 team has the advantage of being first, and will probably
overwhelm the Scenario 2 team, it will not necessarily overwhelm the Scenario 3 team.
Many examples exist of come from behind wins by aggressive and powerful
competitors. But always to start from far behind is a sign of poor business development
practices.
In the kind of advanced
contracting this book
discusses, business
development is much more
than simply going down to
the lobby every day to see if
a customer happens to
have dropped by, or waiting
for bidders notices to arrive
in the mail. It is a coherent
mix of activities and
policies. We offer now
some thoughts on how
those should be structured
based on our observations
and experience.

Exhibit 1-1
Integrated Project
Team for Business
Development

Contracts

Top
Mgmt

Potential and
existing
customers

Bus Dev

Key
Tech

In some contracting firms,

business development focuses on selling existing strengths. In this paradigm, the sales
people mostly approach existing customers to squeeze out more projects based on an
essentially static base of knowledge. The business development and key technical

Page 10 of 199
people are only loosely coupled. An organizational wall divides them. There is little or
no internal research and development.
This approach will surely lead to a declining business base. Today, ten years is a long
life for many products; two years is long for many others. The ones that manage to live
longer are usually the ones that are frequently upgraded to meet new needs.
An excellent remedy for such a stagnant state of affairs is to extend the concept of
integrated project teams to business development.3 In this approach, historical skills
and achievements are merely the foundation for leveraging new ideas that may attract
customers. They are not the entire business.
Exhibit 1-1 suggests a business development team and process that stresses a full
frontal attack emphasizing new ideas and giving customers maximum exposure to your
company.
The team comprises four major skills: top management, business development,
contracts, and key technical innovators. The circle and arrows in the exhibit indicate
that team members are in frequent communication and work closely together, even
though they may belong to separate organizations.
The mission of the business development team (BDT) is to:

Assist pursuit and project teams in maintaining good customer relations and close
ties with key customer decision makers.4

Work with pursuit teams to obtain from customers (and other sources) information
about what customers want and what they can afford to pay.

Analyze competitors ethically to obtain as much information as possible about what

they are likely to offer, and provide that information to pursuit and project teams.

Continuously analyze the market for current or similar products and identify
opportunities for pursuit.

Continuously innovate, leveraging from existing products into new and sustainable
technologies that will interest current and new customers.

Convey needed information to customers and potential customers to help them

make better decisions about acquisitions.

In this book we use the expression integrated project teams in preference to the expression integrated product
teams which is often heard. The reason is that we expect the team to address the entire project (product +
programmatics) in an integrated fashion, and not just the product.
4
The role of the BDT is to identify for the customer a need which should be pursued. The pursuit team is the team
formed to respond to a specific customer request for proposal. The project team is the team formed to work an
awarded project. Some high value persons may be members of all three teams.

Page 11 of 199

Assist in the formation of new pursuit teams.

Here are typical roles within that mission:

Top management. A single senior executive should be appointed to the BDT. His
presence gives the team cachet and access to the highest levels of the company.
His network of contacts will frequently lead to opportunities to be explored. He or
she can expedite the flow of information and the mustering of resources.

Contracts. The traditional role of contracts people is to negotiate and administer

projects contractually. A problem that sometimes arises is that they do this without
adequate input from others. As members of the BDT, contracts people will have
better insights into what drives costs and schedule, and what is important and what
is not. They will be better prepared to develop a negotiating floor position and to
trade off scope versus cost.

Business Development. As members of the BDT, the sales people will be more
aware of current and developing technologies, and the status of current work. They
will be better able to identify the right customer people to approach with new ideas.
And they will have a better understanding of where and how to look for clues as to
burgeoning customer interests that have barely begun to surface.

Key technical people. These are sometimes called technology superheroes.

Sometimes, but not always, they are also gray beards. They are senior technical
people who have a demonstrated capability to imagine and follow through with
viable product ideas, especially those that push the envelope. Theirs is a central
role in the BDT. They maintain awareness of the current technological capabilities
of their company, their competitors, and their customers and potential customers.
They acquire information about competitor products and use it to analyze product
performance. They go to trade shows, attend meetings of professional societies,
and otherwise stay abreast of developments in the world at large. They are either
directly involved in their companys internal research and development, or they
monitor it closely. When new pursuit teams are forming, they advise on who should
be involved, and may participate themselves at least for a time.

Among the key technical people should be one or more persons who are well versed in
costs of the companys products. Such a person is sometimes referred to as a cost
engineer or a cost analyst. What makes this role necessary and even critical is the
inevitable need to assign costs or at least cost ranges to new product ideas and to
competitors products. Such a role is beyond the typical pricer who works in the
finance department assembling cost estimates into a format suitable for bidding. The
role requires a strong technical background, and training in statistics and cost
accounting.

Page 12 of 199
Chapter 1 Review Questions
1. In general, are your efforts to acquire new contracts more like Scenario 1, Scenario
2, or Scenario 3, as described in this chapter?
2. Does your organization tend to focus too long on existing strengths until it is forced
to propose new ideas and approaches?
3. Does your organization routinely present new ideas to potential customers?
4. Considering your competitive situation, do you feel your organization does enough
internal research and development? Is what you do truly innovative, or does it focus
mostly on minor improvements to existing products?
5. Does your business development effort more closely resemble an integrated project
team, or a bunch of separate companies? How could you improve its effectiveness?
6. Do your business development people attempt to convey information about likely
costs and schedules to potential customers as well as technical and other
information? Either way, why?
7. Do your business development balk at having engineers or other technical people go
along on customer visits? (This used to be quite common, but fortunately has been
changing. It can have huge advantages.)

Page 13 of 199

Chapter 2Understand who the customer is

Why it is necessary to have a chapter such as this? Surely we know who the customer
is. Everybody knows its the Federal Aeronautical Commission on Safety. Or is it
Xanadu Incorporated? Could it be both?
Maybe its both. Maybe it even includes others. Imagine this scenario.

The Federal Aeronautical Commission on Traffic Safety (FACTS), a hypothetical

organization, has been given money by government appropriation for the stated
purpose of designing and building a robotic machine that automatically cleans airport
runways and taxiways of small foreign objects that can be very dangerous to aircraft,
much as a popular roving cleaner automatically cleans swimming pools. It traverses
the runway or taxiway from end to end and from side to side. It must be smart
enough not to go off the edge of the runway when its cleaning, and also must be
smart enough never to be on the runway when there is aircraft traffic or even
pending traffic. Aircraft safety is a major consideration in its design.

Because of the complexity and difficulty of the project goals, Xanadu Inc., a consulting
outfit that does a lot of engineering studies related to the airline industry but builds no
hardware, has been selected as a system integration contractor to guide the
integration of the project into major airports across the U.S., and perhaps eventually
around the world. You hope to be selected as the prime contractor that will design
and build the system.
Who is the customer? Is it Xanadu because they will have a strong influence in
approving your design and will be monitoring your tests? Is it FACTS because they are
the proximate source of the money and have ultimate approval authority for what you
do? Or maybe its the legislature because of certain language in the authorizing
legislation? Or, maybe its the airline industry because they lobbied hard for the robotic
runway cleaner and will be watching its development closely. Or maybe in some ways
its all of the above.
The point emerging here is that you shouldnt be too quick to jump to judgment as to
who is the customer. You need to have a practical working definition for customer and
a means to test for customer-ship.
We offer the following definition of customer:
The customer is that group of people whose collective goals the contractor must
satisfy.
There are advantages in keeping a definition simple, as we have tried to do here. The
downside is that full understanding may come only after a fair amount of explanation.

Page 14 of 199
Parsing the definition, it seems that the words or phrases most in need of elucidation
are group of people, collective goals, and satisfy. Lets take them on one at a time.
The group of people
Our definition of customer intentionally emphasizes the notion that it is not really a
company or an agency you are dealing with. Those are just convenient abstractions.
Its the people who count. They will determine whether you win or lose the contract.
They may even determine whether you can execute it successfully if you win it.
As the scenario that began this chapter suggests, some members of the group you
need to deal with as customer may wear different badges or may get their paychecks
from different payroll departments. You must always be open to that possibility.
In dealing with any group of people in business, it is important to sort out and identify
members of three major types: Deciders, Influencers, and Passives. We can define
these as follows:

Deciders are the ones who make the major decisions or who can veto other peoples
decisions. Deciders may be Generals or Specifics. A General Decider can decide
virtually any kind of issue. A Specific Decider can decide within a particular area of
competence, but not in other areas. A General Decider usually can overturn a
Specific Deciders decision.

Influencers are people whose special knowledge, aggressiveness in solving

problems, or panache makes other people willing to listen to and take careful
account of their opinions. Its possible an Influencer should be listened to within an
area of expertise but can be safely ignored otherwise.

Passives are everyone else we encounter in our contract pursuit. Passives may do
most of the useful work, but they are not business warriors. They put in their time,
they may (or may not) strive for excellence in their work, they draw their pay, and
they are content. (Or not.)

Your business development team and your pursuit leaders and key players should
share a common understanding of who the Deciders and Influencers are in a given
pursuit situation. You often can learn a bit by looking at organization charts, but these
charts can be deceptive. A lot depends on hidden delegations and the so-called virtual
organization (i.e., who really does what, regardless of title and size of office). Personal
contact and observation are far better than looking at organizational charts.
Observers can be deceived, but over time they can get a pretty clear picture. The
picture comes from asking and answering questions like these:

Who shows up at meetings?

Do they only show up at certain kinds of meetings?

Page 15 of 199

When certain people talk, does everyone else listen respectfully?

Who conducts the meeting?

Who prepared the agenda?

Who hands out action items?

Who takes on which action items and why?

Is anyone consistently called Mister or Sir or Ms. or Mam?

Who signs what kinds of memos?

Who are designated as points of contact?

When you contact points of contact, do they decide, or do they have to go ask?

Who do they ask and why?

Formal lists of Deciders and Influencers together with notes about their observed
behavior and areas of influence are useful, and should be created by your pursuit team,
but their distribution and content must be carefully managed. It will not do to have an
unflattering observation leaked either intentionally or inadvertently to a Decider or even
to an Influencer.
A point worth noting is that Influencers and even Deciders may not all be outside your
own organization. One reason you could be hired to perform a certain contract is
because you have people in your organization whose skills and expertise are widely
recognized. Although they presumably owe first allegiance to your organization (which
writes their paychecks), they may become so closely entwined with the concerns of the
external customer group that they become a de facto part of it. This is especially likely
to happen with retired technology superheroes and retired vice presidents who are
called in as consultants. Not to say that situations like this are necessarily bad; they just
need to be recognized for what they are.
Here are some thoughts on Deciders, Influencers, and Passives:

In dealing with the military, a senior sergeant or chief petty officer may be a much
stronger Influencer than any ten green second lieutenants or ensigns. Similarly in
dealing with a civilian organization, a senior and respected but low ranked employee
may have more influence than a gaggle of junior supervisors.

Page 16 of 199

No organization is static. Watch for people whose power is on the wane. Also,
watch for people who are comers and who may soon be elevated in status if not in
formal rank.

At a personal level, always treat Passives well. If you dont, you may lose their
support and that could damage you. That possibility makes them important, if
nothing else does.

Be careful about organization charts. A Decider or Influencer of great importance

may be someone who is not even on the chart, such as a trusted outside consultant,
or the CEOs brother.

Recognize consensus decision situations. These are commonplace in Japanese

and European companies, but certainly are not unheard of in other companies.
Many boards of directors and executive committees operate on a consensus basis.
Not much happens until they have thoroughly talked the problem through and gotten
everyones agreement.

Watch for powers behind the throne. Many organizations have their rough
counterparts to Rasputin and Machiavelli, sometimes benign, sometimes not.

Collective goals
Now is a good time to introduce a useful concept that will appear elsewhere in this
book. It is the notion of positive and negative goals. We define:

Positive goals. A positive goal is something the customer wants that represents a
change in the state of nature. It could be a particular product or service. It could be
a continuation of something that would otherwise perish or degrade. It could be a
capability or potential that does not now exist. Customer positive goals can have
endless variety.

Negative goals. A negative goal is something the customer does not wish (or cannot
afford) to give up in order to achieve desired positive goals. Its a constraint. It
could be a money limit on contract expenditures. It could be a time limit on getting
something done. It could be an environmental constraint, or even a political
constraint. It could be strictures on labor compensation or access to a site. Again,
the possibilities are endless.

All pursuit situations encounter both positive and negative goals. All project customers
have positive things they want to get done and also things they are not willing to give up
to get them. It is fair to say that:
The measure of success in any project is the extent to which the positive goals are
accomplished and the negative goals are not violated.
In a perfect project, both things happen, 100 percent!

Page 17 of 199

[As an aside, please note that in this book we carefully segregate goals from what are
often called requirements. In this book, goals are what the customer wants, positive or
negative, while requirements are needful things that arise out a particular project plan or
design solution. If the plan or the design changes, so may the requirements, but the
goals are still the goals. This is not to say that goals are always stable. Customers
dont always have a clear and stable view of what they want. Lets rephrase that in
the high tech arena, customers seldom have a clear and stable view of what they want.]
What about that word collective in collective goals? It certainly does not mean that
every Decider and Influencer is necessarily 100% in agreement that a given set of goals
should be the goals of a project. That degree of agreement will probably never happen.
Heres what it means as far as this book is concerned:
The collective goals of a project are the apparent goals for which the strongest
evidence of customer intent exists.
This definition basically says that if a pursuit team wants to understand the goals of a
project, it must look at all of the available evidence and judge accordingly.
Generally, the strongest evidence for the existence of a goal is that it is clearly and
unambiguously recorded in an official document issued by the people who will pay for
the project, and that the means for satisfying it are clearly visible. Written requests for
proposal and written specifications generally are such documents. But these
documents may not be the only evidence. Not all valid goals are recorded religiously in
formal written documents. Some may be recorded in informal memos, meeting
minutes, or even in e-mails. Some may have been spoken orally in a meeting or in a
telephone conversation.
If a goal is stated orally only, and it is more than trivial, it is important who stated it and
what the circumstances were. It is also important that an orally stated goal not conflict
with a written goal. Legally, that which is in writing is almost universally held to have
precedence over that which is stated orally. Writings may have precedence over other
means of expression such as pictures. For example, goals stated in words generally
have precedence over goals stated in any graphical form.
A goal stated by an Influencer should be assigned less credibility than one stated by a
Decider. The more senior the Decider the greater his credibility in this regard.
For a variety of reasons, goals pronounced by the part of the customer group that is
paying for the project generally have precedence over those pronounced by non-payers
in the customer group. And finally, goals stated in formal contract documents have the
highest precedence of all.

Page 18 of 199
Goals have many issues; we will not attempt to discuss all of them in this chapter. For
example, there are issues of clarity, conflict, precedence, realism, and visibility, to name
a few. Chapter 6 has a comprehensive discussion of this topic.
Satisfying the goals
Are goals satisfied only when the customer says they are? That may be the case in
certain projects where the customer pays or reimburses all costs, no matter how high.
But in most projects, the notion that the customer is always right must be tempered by
reality. Satisfaction of a goal should be something that is easily and immediately
recognizable by both contractor and customer. That will be the case only when the
goals are truly clear.
The notion of a clear goal is important. In this book, we define a clear goal as follows:
A clear goal is one whose criteria for satisfaction are obvious.
If all goals are clear, then the only issue of satisfaction is when we fail to meet the goal.
Then we must pay whatever price or penalty the contract calls for. Unclear goals lead
to arguments and dissatisfaction.
We have observed that unfortunately many project goals are not clearly expressed.
That is a major reason why we have lawsuits, mediations, and unhappy customers.
Unclear goals are such a detriment to both customers and contractors that both sides
should always go to great lengths to keep them from happening.
Here are some examples of goals that may be unclear, depending on the context:

The software shall be user friendly. (What does friendly mean?)

The pipes shall be painted white. (Which pipes? What kind of paint?)

Contractor shall report status monthly. (Status of what? When in the month?)

The preliminary analysis shall be completed as soon as possible. (Who decides

when as soon as possible is?)

Contractor shall use computers supplied by us. (For all purposes? When will they
be supplied? Will they have the right software?)

Access to Bldg. 34 is limited. (Limited to whom? Do we need access? How can we

get access?)

Sorting out the true goals in a project is similar to what a communications engineer
would call a signal versus noise problem. The stronger the signal, and the weaker the
noise, the easier it is. The need for a strong signal versus noise ratio becomes even

Page 19 of 199
more imperative when you consider that you need to do more than just figure out what
the goals are. You also need to figure out how important they are relative to one
another. Sometimes a customer will volunteer that information for a few top-level goals,
but more often it will not be disclosed unless you ask. Not too surprisingly, when you do
ask, your customer will sometimes have to stop and think before giving an answer. In
the rush to get his projects organized, a customer will often not be too clear on his
priorities or his value system.
Why is it important for the customer to know the relative importance of goals and to
share that information with bidders? Here are three reasons:

The customer, having more certain knowledge of what is wanted, will be able to
judge proposals more realistically, consistently, and fairly. Goals are more likely to
remain stable throughout the project.

Bidders will be able to focus their efforts and costs on that which is essential,
avoiding unbalanced proposals that overemphasize the relatively unimportant, often
because it is simply something the bidder happens to like to do, or can do very well.

Potential project instabilities are likely to be avoided, as for example when the low
and winning bidder has heavily discounted the importance of certain goals that are
highly valued by the customer (this often happens when goals are less than clear).
If this happens, the customer is damaged, and so are the bidders who guessed right
about what was important and what was not. The winning contractor is likely to be
damaged also.

What is relative importance in this context? It comes in two flavors, ordinal scale and
ratio scale. If we are asked our order of preference for three particular movies, we
might rank them like this:
1. Star Wars
2. Matrix
3. Die Another Day
This is an ordinal statement of preference. Such a statement might be perfectly
adequate for certain decisions, but possibly not for others. In certain situations, we
might want to know how much more we like Star Wars than Matrix, and how much more
we like Matrix than Die Another Day. This type of information can be key to a decision
process. Merely to know the order of preference is to know a lot less than knowing that
with Star Wars at a ten on a ten-point scale, we would place Matrix at a 6 and Die
Another Day at a 3.5. This is ratio scale knowledge and it can be precious in making
decisions about levels of resources or degrees of application. A practical method for
obtaining subjective ratio scale rankings is discussed in Appendix C.
A very useful way to view goals is to classify them as either tradable or non-tradable. A
tradable goal is one for which options exist as to how to satisfy it. A non-tradable goal is

Page 20 of 199
one which can be satisfied in just one way. Tradable goals are desirable because they
give the contractor an opportunity to flex his imagination and find more cost effective
solutions. Non-tradable goals may be necessary in some cases to fulfill the customers
wants, but they can result in higher costs to the customer.
Chapter 2 Review Questions
1. Have you ever worked on a project where there seemed to be more than one
customer telling you what to do? How did you deal with this?
2. Has any project team you have worked with made a list of customer people and
characterized them with respect to their true roles, not just their titles?
3. Does the organization chart for your own organization accurately reflect who does
what?
4. Positive and negative goals create stresses and risk in every project. What do you
think is the best way to keep these tensions from damaging the projects chances for
success?
5. Can you think of an orally transmitted customer goal on any project you worked on?
Was it a tradable goal? Did it cause any problems?
6. In your projects, have you ever encountered any problems with unclear goals?
What was the ultimate outcome?

Page 21 of 199

Chapter 3 Understand who we are

The words we, us, you and our appear frequently in this book. To whom do they
refer? They refer collectively to the primary performer of a contract obligation and to all
entities that have assumed some responsibility for performance under the direction of
the prime performer.
In virtually all projects, except possibly some very small ones, the prime performer will
engage the services of some combination of consultants, suppliers, and subcontractors.
Under a common law doctrine called privity of contract, except under special
circumstances the secondary performers are invisible to the customer. The customer,
when seeking a remedy for any failure of performance, will talk only to the prime
performer. The prime performer generally is unable to shift blame to any secondary
performer.
For this reason, it is wise for the prime performer to be very careful in the relations it
creates with secondary performers. Not only should these relations be fully defined in
writing, but the writing itself should be carefully reviewed to be sure it is free of
ambiguities, conflicts, and omissions.
Using carefully drafted documents to create a relation between the prime performer and
a secondary performer is necessary but not sufficient to guarantee that the relationship
will be successful. Success depends in large measure on the desire and the ability of
the secondary performer to have a successful relationship. Hence, the prime performer
should seek to form relationships only with secondary performers who are 1) qualified
and 2) motivated.
Qualified means that they have available the resources, physically and intellectually, to
do what is asked of them. Motivated means that they strongly value and want to
protect their relationship with the prime performer. In the case of consultants,
qualification is usually established by reviewing some combination of academic
credentials, licenses and certifications, and a verifiable record of success in similar
consulting assignments. In addition, the consulting hourly rate or blanket fee must be
acceptable. Further, the consultant must come equipped with all of the tools (hardware,
software, memberships, relationships, knowledge, etc.) appropriate to his or her
specialty, and must be available when needed.
In the case of suppliers, unless a delay is acceptable for some reason, a supplier must
have in stock the item needed at the time it is ordered, and must have an acceptable
price. Suppliers must also offer acceptable warranty and return policies.
The relationships between a prime and a consultant and between a prime and a
supplier are generally quite simple compared to the relationship between a prime and a
subcontractor. Subcontractor relationships are frequently very complex due to the
many instructions necessary to define them. These may include drawings and

Page 22 of 199
specifications, statements of work, schedules, test procedures, quality requirements,
shipping instructions, and numerous other documents, plus mechanisms for reliably and
quickly accomplishing changes in design baseline. Therefore a prime has, or should
have, considerable interest in the details of the capability of a subcontractor and the
subcontractors supply chain, and in the stability and reliability of the processes the
subcontractor has in place. The skills and experience of the subcontractors
management will also be of interest.
Determining motivation of a consultant, supplier, or subcontractor is a trickier matter.
Motivation, unfortunately, can be feigned. It can also change with circumstances. The
only way to be reasonably sure is to test from time to time. Are commitments met? Are
promises kept?
Unfortunately, the due diligence necessary to verify these characteristics is often
missing. The sad result can be missed delivery dates, poor quality, design errors, and
extra costs.
Chapter 3 Review Questions
1. Have you ever experienced a significant failure to perform of a subcontractor,
supplier, or consultant? What damage did the failure do to your project?
2. Could the failure experienced in question 1 above have been prevented by
reasonable and appropriate due diligence? About how much do you think the due
diligence would have cost?
3. A frequent problem with subcontractors entrusted to create complex, high
technology devices is that their initial estimate of what the device will cost to produce
is quickly forgotten as the project wears on. Ultimately, it may turn out to cost five or
ten times as much. Given that this is not uncommon, what steps can you think of
that would keep this from happening?

Page 23 of 199

II Know what your customer wants

Chapter 4 Learn about and influence customer goals5
Customers dont always know what they want. Or they may know what they want but
not what they need. And they may have any number of half-baked ideas about how
what they want should be implemented. Thats why you dont just learn about customer
goals, you also try to influence them in the direction of a better outcome for the
customer. Your ability and willingness to help the customer find the best goals is part of
the difference between being a so-so contractor and an outstanding one.
You are the contractor and the customer is the customer because you have knowledge
and expertise the customer doesnt have. If you are hired it is because you can do the
job better than the customer, who may not be able to do it at all. And because the
customer thinks you can do it better than anyone else. Out of respect for his opinion of
you, you owe a duty to the customer to help get the best possible result.
But you cant approach the customer as a know-it-all, because there are some things
the customer knows better than you do, such as the everyday problems faced. Your
customer knows, at least in general terms, why he or she thinks that something is
needed that you can create. You must approach the customer with courtesy and
respect. Its the customers problem, after all. More importantly, its the customers
money.
Customer needs must at some point be converted to formal statements of positive
project goals. Then, the customer must consider what he or she is not willing to give up
in achieving those positive goals. Those will be the cost, schedule, and other
constraints that will be placed on the project. If your customer goes through these
goal-setting steps without any input from you, and especially if competitors are providing
input, the result may be a set of goals that you find difficult to live with. It may also be a
set of goals nobody can live with. The result could be an unstable and failed project.
Paradoxically, by far the best time to ask a customer about goals is before awareness of
them sets in. Consider the following hypothetical scenario.

Imagine that your companys main focus is software and methods to kill computer
viruses before they can do much damage, and to prevent their spread. You have a
very large customer who has vast computer networks that occasionally are crippled
by new viruses. While the new virus is being diagnosed, and your people are
developing a vaccine, the virus spreads rapidly, infecting many of your customers

If this book were about developing products for the public at large I would recommend the Quality Function
Deployment (QFD) approach to learning about customer wants and how to translate them into successful products.
An excellent source of information on that approach is (Ficalora & Cohen, 2010). But that is not what this book is
about, and the approach I describe here therefore differs from the popular QFD approach.

Page 24 of 199
computers and doing a lot of damage. One of your researchers notices that a
healthyl computers communications across the network tend to be at a relatively
sedate pace, while the communications of an infected computer tend to be frantic
because the virus is trying to spread itself as rapidly as possible.
Your computer scientists develop a process that slows down communications when
their rate rises above a certain threshold. The effect is that the virus is not stopped
from communicating itself, but it cannot propagate itself nearly so rapidly. This
provides more time for your computer scientists to diagnose the problem and find a
cure before great damage is done.
Your business development people analyze the economic benefits of this process to
your customer, and find that they are considerable. Indeed, they are so great that
your customer can afford to subsidize the development of your new anti-virus
software. So you develop project goals for the development and installation of the
needed software and approach your customer with them.
Your customer did not have those goals before you brought them up. But once you did,
your customer accepted not only your suggested positive goals, but also the negative
cost aspects. In essence, your customer bought the whole package. Your
competitors are pretty much excluded, so your win probability is close to 100%, as long
as your customer is comfortable that your price is reasonable and affordable. And the
careful cost / benefit analysis you gave him has already convinced him that it is.
Scenarios such as this are the ideal bidding situations. You dont have to inquire into
your customers goals, because you already know what they are. The goals came from
your innovations. Starting with this situation as the best of all possible worlds, we can
form the following hierarchy of difficulty to determine customer goals:

Pre-sold goals package. You propose an attractive solution for solving or at least
mitigating a serious customer problem, or you enhance a customer opportunity. You
provide both positive and negative goals that are convincingly realistic. Ideally,
competitors are excluded because you have too much of a head start. Less ideally,
one or more competitors may get up to speed fast enough to mount a challenge.6

Early goals shaping. By careful observation of clues dropped by a customer or

potential customer, you become aware of a developing customer need just as the
need is becoming apparent. You actively help the customer shape the goals,
especially the positive ones, but you may also advise the customer on likely cost and
schedule ranges to avoid the possibility that the customer may develop unaffordable
goals. Ideally, you can do this and keep it hidden from competitors. More likely,
alert competitors will sniff out what is happening and will offer the customer their own
advice about what the goals should be. Or, the customer may simply want to see all
of his options and will ask your competitors for information. You cant always win a

If you are able to pre-sell a goals package to a customer, keep in mind that other customers might like to hear about
it, too.

Page 25 of 199
tug of war over what the goals should be. Your competitors may have better
solutions than you can offer. But it is beneficial for you to be a player if your
approach even comes close to being the best solution for the customer. Here are
some reasons why:
o Your unique capabilities are made visible to the customer, who may have
need for them on other projects
o The customer will be pleased that you are interested in helping solve his
problems, even though you dont have the best solution this time
o Your participation may have made the customer more aware of the best mix
of goals, making it more likely that the project will succeed
o If the winning contractor performs poorly, you may be remembered as the
contractor who should have gotten the work, and perhaps next time you will
o Proposals, even losing ones, have internal value to you by sharpening your
proposal skills and making you more aware of good directions for internal
research and development

Late goals shaping. With little input from you or your competitors, the customer has
done much internal work on determining the ideal goals. There may be competitive
or security reasons for this state of affairs. When your competitors and you learn of
the prospective bidding opportunity, the goals are already at least fairly mature. You
have to go through an inquiry and learning process to understand the goals and your
ability to meet them. You may still have opportunities to provide feedback to your
prospective customer that may be useful in improving the goals and avoiding
mistakes.

No goals shaping. Your potential customer, perhaps with the aid of one or more of
your competitors, has arrived at a set of goals believed to be optimum. You have
not been involved in shaping the goals, but must learn and understand them the best
you can based on documents released by your prospective customer, and whatever
conversations you can manage. You have to arrive at a decision as to whether you
can be competitive given goals you did not help shape.

In the first of these scenarios, ease of understanding of your customers goals is

greatest, and the amount of effort you have to expend to understand them is minimized.
In the last scenario, the reverse is true. Understanding requires a learning curve, the
possibility of misunderstanding is highest, and time pressures to produce a proposal
may be extremely high. This argues that you always should be as near to the first
scenario as you can get. Unfortunately, you cant expect to always be in that scenario.
Even with a competent and aggressive business development team, you are likely
much of the time to wind up in one of the two middle scenarios. Given that, you need
to be as skillful as you can be in dealing with already developed customer goals.

Page 26 of 199
Because this is likely to happen from time to time, we believe it is best to follow a formal
process for doing this. The reason is that its too important to be left to a haphazard
effort that could lead to misunderstandings and mistakes. The process we suggest is
depicted in the flow chart in Exhibit 4-1. In this chapter we will to a limited degree
explore all of the steps shown, but some of them are more fully explained in earlier or
later chapters.

Understand
who the
customer is

Compile
goals

Classify
goals

We now explore these process

steps:

Understand who the

customer is. Chapter 2
discusses this subject. It
points out that the
customer may be people
Establish
Resolve goal
Critique goal
dispersed among several
customer goal
conflicts
problems
values
organizations, and that
these people may not speak
entirely with one voice.
Sorting out the most
Exhibit 4-1
authoritative voices often
Goal
Manage goals
Development
requires considerable
Process
analysis of the available
evidence. Chapter 4 points out the importance of understanding the customers
goals and priorities. If you fail to interpret correctly who the customer is, there is an
excellent chance you will wind up with a misunderstanding of the goals.

Compile goals. Compiling the goals simply means bringing them together in one
place in an organized and searchable format so that when you do further work on
them you are sure to have all of them. Most goals will be in writing. Those that are
not should be reduced to writing as soon as possible. With respect to valid oral
goals, a wise course is to put them in writing and ask the customer to transmit them
through formal contractual channels.

Classify goals. Requests for proposal in major projects may state literally hundreds
of goals. They may be scattered throughout several thick documents. Some of
them may ask for essentially the same thing but in slightly different language.
Modern practice is to organize all goals whatever their source into a single computer
database so they can be rapidly queried and so that related information can also be
stored and accessed. Related information might include who is responsible for
being sure the goal is met, the date meeting it was confirmed, and perhaps other
information. In such databases, goals are often classified according to subject
matter, importance, and other aspects.

Resolve goal conflicts. There are always tensions between positive and negative
goals, but this is not what we mean by goal conflicts. Conflicts arise when two goals

Page 27 of 199
say to do different and irreconcilable things. If a negative goal says the project must
be completed in 18 months for less than $10 million, that outcome may be highly
improbable, but it is not a conflict. If it is merely improbable it is a risk. An example
of a conflict is when one statement says that task A must be completed by a certain
date and must use certain customer furnished equipment, yet another statement
says that the customer furnished equipment will not be available until after the
required completion date for task A. Another example of conflict would be when one
statement says to paint something black, and another says to paint it white. Early
resolution of goal conflicts is extremely important to project success. Resolution
requires identification of the conflicts, then presenting them to the customer for
action to clear the conflict. If we submit a proposal that is based on conflicting goals
of which the customer is unaware, we run the risk of mistakenly being judged nonresponsive by the customer.

Critique goal problems. Conflicts are only one potential problem with project goals.
There are many others, such as lack of clarity, departure from reality, hidden
agendas, etc. Probably the biggest potential problem with goals is when the
customers expectations far exceed his budget. That subject is discussed in Chapter
6. The chapter discusses several types of mistakes often made by customers that
you, as a contractor, should be able to recognize and help the customer avoid.

Establish customer goal values. Customers obviously dont value all goals the
same. This does not mean that you can meet only the most important ones and
ignore the rest. If you expect to be a successful bidder, you must convince the
customer you can meet all of them, even the relatively unimportant ones. But you
should try to balance your efforts so that the bigger efforts go, more or less
proportionally, to the most important goals. To be able to do this, you must
understand how the customer regards the goals in terms of relative importance.
Chapter 4 has a discussion of this subject.

Manage goals. Sometimes customers are very good at managing their goals. If
they are, you will likely observe all of the following:
o

Goals will be stable. You will receive few changes in the request for
proposal, and few changes in the contract once it is awarded

Goals will be internally consistentno conflicts between positive goals

and no conflicts between negative goals

Goals will be realistic. Tensions between positive and negative goals will
not be unbearable, leading inevitably to project failure

An excellent idea is to track the process of goal understanding in a manner well suited
to management briefings. Exhibit 4-2 nearby is a good way to do that.

Page 28 of 199
If the customer does not manage goals well, you will not observe one or more of the
above. Lets look at situations of poor goal management and consider what they might
mean to you as a contractor.
Perversely, some contractors hope for goal instability. Their strategy is to bid at their
expected cost or even below in order to assure a win, then they hope to become
profitable by charging an exorbitantly high price for changes. We deplore this strategy.
It is unethical. Moreover, it is dangerous. If the expected changes are not forthcoming,
or if they are small, the contractor could lose serious money.

Exhibit 4-2 Goal Management

Also, many
customers today
are much better at
spotting a buy-in
bid than they were
in years past. A
bid that is below
your expected
cost will probably
be detected as an
attempt to buy in,
or it may be
regarded as a sign
that you just dont
understand the
job.

Conflicting goals are a sign that the customer may have problems with contractor
management. At the least, it is a sign of carelessness. As previously noted, it is
important that you point out goal conflicts to the customer and request their removal.
Failure to do so can result in an unstable project that is prone to failure.
Realism of the goals has several aspects. One is technical possibility. Rarely will a
customer be so grossly uninformed or careless as to ask for something that is literally
impossible, but it is fairly common that a customer will ask for something very difficult
that the budget will not support. Unrealistic goals are a frequent customer mistake. We
should tactfully warn our customers away from such mistakes as a gesture of good will.
Customer visits during the pursuit cycle are vital in major projects. There is no
substitute for face-to-face discussion to gain understanding and to minimize mistakes.
Chapter 1 discusses a concept for an integrated business development team with
membership from four areas of the contractors organization: top management,
contracts, business development, and key technical people. All four areas should
participate in customer visits. Here are some reasons why.

Page 29 of 199

Top management visits demonstrate your commitment to helping the customer solve
his problems. If problems need to be resolved, top managers by virtue of their
authority can most often find fast and effective solutions.

Visits by senior contract administrators to their counterparts in the customer

organization are an excellent way to minimize problems due to poor contract
structure, unclear or oppressive reporting requirements, and the like. Such visits
may also result in more favorable terms of payment, e.g., faster payment, lower
withholds, etc., that increase return on investment. They may also help minimize
risks due to late delivery of customer materials or facilities, or risks that these may
not be well suited to the work or may be defective. A further useful service contract
that administrators can provide is to help better define who the customer is and what
is affordable for the customer.

Business development people must visit to detect possible beneficial expansion of

the scope of work, or new bidding opportunities. Their visits also serve to make the
customer more aware of what you have to offer and how the customer can best
profit from it.

Visits from key technical people are vital to proper understanding of the customers
technical problems and definition of the trade space. They can help eliminate
inappropriate customer attempts to venture into problem solution, as opposed to
problem definition. Often a key technical person can be instrumental in changing a
difficult non-tradable goal into a less difficult tradable goal that you are better able to
deal with. Visits by key technical people can also help your organization set better,
more current priorities for internal research and development.

Chapter 4 Review Questions

1. How long has it been since your organization has pre-sold a goals package to a
customer? Are you working to do that now?
2. In your current or most recent pursuit cycle, what efforts were made to influence
customer goals? Was or is a competitor working to counter your influence?
3. Can you remember winning a project where you had little or nothing to do with
shaping the goals? If so, why do you think you won?
4. Does your organization have a formal process for compiling and classifying goals?
Is it effective?
5. Have you recently experienced a customer who had problems in managing his
goals? What was the impact on the project?

Chapter 4 Bibliography
Ficalora & Cohen, 2010: Quality Function Deployment and Six Sigma: A QFD Handbook,
Prentice Hall

Page 30 of 199

Chapter 5Measure customer value judgments

Chances are that in your previous project pursuits a lot of attention was paid to figuring
out what the customer wants, but not a lot of attention was paid to how strongly it is
wanted. This chapter will make the case that you should be very interested in just how
much, relatively speaking, the customer values the things he is asking for. We will try to
show that having this information can improve your win probability. The effect on win
probability is much more subtle and complex than factors like bid amount or number of
efficient bidders, but it is nevertheless important.
To illuminate and inform this subject, it seems best to start with a simple example.
Suppose that the customer has issued a request for proposal for development and
production of a laptop computer. You, as a prospective bidder, have managed to elicit
the information shown in Exhibit 5-1 from the customer:
Exhibit 5-1Example Customer Relative Value Assessment
Features
Relative Value%
Weight
20
Processor speed
9
Storage
9
Display
5
Battery life
5
Price
20
Warranty
5
Options for growth
13
Availability
14

Goal
5.9 pounds
800 mhz
300 mb RAM
25"
6 hours
<$1,000
3 years
Options #1, #2
1 year

As a prospective bidder, you are concerned that the customer 1) may be asking for
more than is affordable, and 2) may be unwittingly adding expensive requirements that
are out of proportion to their value to him.
Using the above table of features, you estimate relative costs for each feature as a
percentage of total average product cost. Most of the estimates will be simple and
straightforward, but some will require careful thought. An example of the latter is the
weight requirement. Weight is neither hardware nor software. It is actually a constraint
on a physical property of the hardware. How can it have a cost?
That question can be answered in the following way: If the weight requirement can be
met without violating any of the other goals, then it has no cost. But if cost must be
incurred to reduce the weight of one or more of the components of the laptop in order to
meet the weight goal, then that incremental cost should be assigned to weight.

Page 31 of 199
To further illustrate, suppose you add to the above table your estimates of relative cost,
with the following result (Exhibit 5-2):

Exhibit 5-2Example Customer Relative Value/Cost Assessment

Features
Relative Value% Relative Cost
Weight
20
35
Processor speed
9
7
Storage
9
6
Display
5
5
Battery life
5
5
Price
20
18
Warranty
5
5
Options for growth
13
11
Availability
14
8

Goal
5.9 pounds
800 mhz
300 mb RAM
25"
6 hours
<$1,500
3 years
Options #1, #2
1 Year

An interesting way to present this data for internal review is a radar chart such as the
following:

5
-

In this chart, for

each feature the
ratio of relative
value to relative
cost has been
plotted. A value
of unity indicates
an exact match.
A value less than
unity indicates a
deficiency.

Of all the
requirements in
this example, only
weight has a
relative cost that is significantly higher than its relative value. Since the relative cost
considerably exceeds the relative value, it may be worthwhile for your customer to reexamine the weight requirement to see if it should be relaxed. If the answer is that it
should not be, then perhaps weight is really more important than was previously thought
and that should be acknowledged.
Comparisons between relative cost and relative value should be based on minimal
efficient designs. Such design solutions are discussed in Chapter 9.

Page 32 of 199
Aside from possibly helping your customer re-order his priorities to be more in line with
costs, what other reasons are there to do the type of analysis shown above? Here are
some thoughts on that subject.

Is the customer asking for expensive, unaffordable features? This is a critical issue.
If the customer wants a $100 million product and you know that only $75 million is
affordable, how do you best influence him or her in the direction of affordability? A
many-sided question, but probably you would start by suggesting elimination or
scale down less important items. To do that you have to know what they are. If you
don't succeed in that you may not be the winning bidder, because you normally don't
want to bid below what you believe to be your true costs. Moreover, the winning
bidder may well fail in project execution. That bidder probably knew or guessed that
affordability was only $75 million and bid that amount, either not understanding the
true costs or hoping to make it up on changes. You lose because you lost the
contract. The customer loses because his project seriously overruns its cost goals.
Unrealistic expectations make a project unstable. Many outcomes are possible in an
unstable project, and failure certainly is one of them.

Suppose that the customer says that a certain feature has 20% of the value but your
analyses say it has 50% of the cost. Two possibilities present themselves. One is
that you need to be sure you have a truly minimal design and have squeezed out all
of the costs that you can. The other is that if things go along in this state, the
customer will wind up paying a higher than reasonable price, given the low
importance of the high cost feature. Again, two possibilities. One is that the
customer says, Yes, I know it's expensive, but I have to have it because of ___ (fill
in the blank) even if I don't like it all that much. The other is that the customer says,
Am I glad you noticed that and pointed it out to me. Let's get rid of that goal. That
will really cut my costs.

The customer wants a feature that has 50% of the value and only 10% of the cost.
Provide it, and make a big fuss about how wonderful it is that you can meet stated
needs so economically.

If your ratios are significantly different than your customer's preferences, you
introduce what we call an unbalanced design. (Later in this chapter we show a
simple metric for design balance that can be used to track it.) Is there any risk in
having an unbalanced design? Yes. One risk is that your customer will sense that
you are not paying enough attention to needs. Another is that your competition may
have a more balanced design and can convince your customer it is more like stated
needs than your design. This is subtle but can be quite real.

How do you go about finding your customers scheme of values? You may find little
information about this in your customers request for proposal. Recall from Chapter 2
that it can sometimes be daunting to find out who really speaks most authoritatively for
the customer. It may be necessary to conduct a poll of authoritative customer
representatives and average the results. If some customer representatives are not

Page 33 of 199
responsive, credible answers sometimes can be had from consultants, especially those
who are former customer employees or advisors. Exhibit 5-3 below shows a
hypothetical example of a values survey.
Exhibit 5-3Using Weighted Survey Data to Assess Importance to Customer
Parameter
Weight
0.6 x
0.6 x
0.6 x

Speed
Altitude
Payload

FACS
Value
0.4 +
0.1 +
0.5 +

Weight
0.4 x
0.4 x
0.4 x

Xanadu
Value
0.3 =
0.2 =
0.5 =

Customer
Importance
36%
14%
50%

Once you have created a table such as the above you want to also determine the
weighted costs. With some product features, such as the features of the laptop
computer described earlier, it is fairly easy to assign relative costs to individual features.
With features such as speed, altitude and payload, it may not be obvious how to do this.
So instead you could create a proxy for these relative costs.
An example of such a proxy is the Performance Difficulty Index (PDI). The PDI is a
subjective assessment of the relative difficulty of meeting particular goals. A survey
process analogous to the customer value process described above can be used. See
Exhibit 5-4 for an example.
Exhibit 5-4Using Weighted Survey Data to Assess the PDI
Parameter
Speed
Altitude
Payload

Engineering
Weight
0.7 x
0.7 x
0.7 x

Value
0.5 +
0.2 +
0.3 +

Project Management
Weight
Value
0.3 x
0.4 =
0.3 x
0.3 =
0.3 x
0.3 =

PDI
47%
23%
30%

We are now able to introduce a design balance metric that can be used to track design
balance throughout the pursuit cycle. We first combine the results of the above two
tables in Exhibit 5-5:
Exhibit 5-5Combining Customer Importance and PDI
Parameter
Speed
Altitude
Payload

Customer
Importance
36%
14%
50%

PDI
47%
23%
30%

You can immediately see that the effort, as represented by the difficulty proxy, is
substantially out of proportion with the customers importance ratings. What is the
significance of this metric? It basically is a signal that you may be working too hard and

Page 34 of 199
spending too much time and money in areas that are not that important to your
customer. Then again, you may not be. The metric is not infallible. Its a flag that you
need to look more closely.
For example, payload is the most important goal (50%), yet it represents only 30% of
your effort as measured by difficulty. It is just possible that with your design approach,
the payload goal is easy for you to reach. In that case, your present approach would be
reasonable. On the other hand, you may need to restructure your efforts to put more
emphasis on the payload goal, and less on the other two goals
Just what form would a restructuring of effort take? Thats hard to say without
examining the reasons why the difficulty assessment came out the way it did. Suppose
for example that the team believes that the difficulty with speed arises because of a
complex of problems relating to engine thrust, fuselage shape, and other factors. At
bottom, these problems loom large because the teams experience has mainly been
with larger, faster aircraft. The remedy may be as simple as hiring a few people with the
needed experience.
The comparison approach advocated here is not science, exact or otherwise. It should
never be regarded as a positive indicator that the approach taken is wrong. Rather, it
should be regarded as a form of self-examination to be sure that what is being done is
in your customers best interests.
Cost and difficulty are just two possible comparisons you might want to make with the
customers view of relative importance. In your proposal you will want to discuss in
some detail how you will approach meeting customer goals. In response to customer
goals, many (mostly losing) proposals make terse and uninformative statements such
as The aircraft will be able to carry a payload of 10,000 pounds. If you know that
payload is the most important customer goal, you would be wise to be sure that your
customer is convinced that you can meet that goal. You need to be clear on how you
know you can meet the goal. This is emphasized in chapter 14.
It would be too simplistic to claim that the number of pages in the proposal devoted to
each goal should be proportional to the importance the customer attaches to it. But
clearly the strength of the arguments in your proposal should in some sense be
proportional.
A common mistake in proposals is to rave on endlessly about the things the project
team does well instead of focusing specifically on how the teams skills can be applied
to assuring that the customers goals are met.
This is especially egregious when the goals are tradable. The customer will want to
know how you have taken maximum advantage of the available trade space, and that
requires convincing words of explanation.

Page 35 of 199
Earlier in this book the phrase project design was used. We explained that it referred
to both product design and programmatic design. Up until now in this chapter, we have
focused on matching product efforts with what the customer regards as important. We
need to go beyond that to be sure our customer understands that our programmatic
efforts also are appropriate.
Customers usually spell out in considerable detail what they expect the product
performance to be like. They often are a bit less explicit as to their programmatic goals.
Programmatic goals, like product goals, can be either positive or negative, and either
tradable or non-tradable. They can also be ranked, just as we discussed above for
product goals. An obvious question arises: should they be ranked in the same list with
the product goals, or separately?
Separately is probably best in most cases. Separating them avoids the apples vs.
oranges sense that arises when they are combined. (But see Appendix C for an
approach known as the Analytic Hierarchy Process that can make sense out of many
apples vs. oranges situations.) The important thing is not to focus exclusively on
product goals to the detriment of programmatic goals.
Keep in mind that your customer may be much more sensitive to certain programmatic
issues than to some product issues. For example, if it has been made clear that a $50
million spending cap is not tradable, you need to be sure that you can do the project for
less than $50 million. If you are pretty sure you cant do it, and that no competitor can
either, you should suggest downgrading or elimination of some other goals.
The pursuit manager should have primary responsibility for assessment of customer
priorities and values, but she should be assisted by the pursuit team and by the
business development team. The information should be logged into a project database
so that it becomes available to all members of the core pursuit team. If the proposal
has a review wall, it should be posted there.
Chapter 5 Review Questions
1. In the laptop example in this chapter, explain how you might assign a relative cost to
the price goal. Hint: Review the discussion of assigning a relative cost to the weight
goal.
2. Explain in your own words how a customer having unaffordable wants can lead to
project instabilities that adversely affect the customer, the winning bidder, and all of
the other bidders.
3. In the example table of values survey (Exhibit 5-3), the Federal Aviation Commission
on Safety (FACS) weight was consistently set at 0.6 for all parameters and the
Xanadu weight was consistently set at 0.4 for all parameters. Could there be a
situation where, for example, one might want to set the FACS weight differently for
different parameters, say 0.6 for speed and payload and 0.5 for altitude? What
practical problems might this create for building the table? How could you overcome
them?

Page 36 of 199
4. If difficulty is to be a proxy for cost, what definition needs to be assigned to
difficulty that is reasonably consistent with typical dictionary definitions?
5. Name five typical elements of programmatic design other than schedule and budget.
Hint: Look in Chapter 8 if you cant think of five.
6. Your contract, in a paragraph titled Period of Performance, says you shall complete
not later than 30 September of the current year. Is this a positive or a negative
goal? Is it tradable or not? How sure are you about whether or not it is tradable? If
not completely sure, describe a way you might become sure. If it is tradable, why do
you suppose the contract doesnt say so explicitly?

Page 37 of 199

Chapter 6Create customer satisfaction

We have all had the experience of being in a restaurant and being asked, usually by a
small sign, not a human being, to fill out one of those ubiquitous little survey cards that
want to know if we are happy with the food, the service, etc. Or, a server might wander
by when our meal is half eaten and inquire Everything OK here? Or when we are
leaving the cashier might ask Was everything OK? To which we are expected to reply
Everything was fine. And smile.
If everything was only a little bit shy of fine, many if not most people nevertheless will
still say that everything was fine. Only those earnest and confrontational seekers of
perfect social justice will voice a complaint about a small failure on the part of a
restaurant. But the memory of that small failure may linger and as a result their next
meal out may be at a different restaurant. Or they may remark to a friend that, You
know, last time I was in there the soup was cold. The friend may decide not to eat
there either.
Small customer dissatisfactions can be damaging to business. Thats why most
successful retail businesses go to great lengths to keep them from happening, and
quickly repairing them when they do happen. Some project teams pay little attention to
the matter, relying on their project and contract management people to buffer them from
most customer concerns. But in many projects, there are many interfaces with the
customer, and total buffering is neither possible nor desirable.
Unfortunately, maintaining good customer satisfaction in the world of projects can be
enormously more complex and difficult than in the retail world. One complicating factor
is the often diffuse nature of the customer, as discussed in the previous chapter.
Which customer element should you try to satisfy? Another complexity can be the
many levels and points of contact with customers that often occur on projects. Often
people at many levels of the project team are in frequent contact with their counterparts
on the customer side. At each point of contact dissatisfaction can occur, and it
potentially can propagate throughout the customer organization.
Just as in a retail business, dissatisfaction can go unnoticed without customer feedback.
The ubiquitous questionnaire is not a practical tool for gathering feedback in most
project situations. Most people dislike filling them out unless they have been
egregiously offended, and the feedback may be slow in coming. So do you train your
people to occasionally ask their customer counterparts How is it going? or Is
everything OK? as a server in a restaurant might? If you do, the answers you get will
likely be vague and not particularly useful.
We recommend a somewhat more direct approach. We like to call it TCB, short for
Taking Care of Business. If you want a fancier name, try Anticipative Closed Loop
Feedback or ACLF.

Page 38 of 199
The theory behind TCB is that dissatisfaction is most likely to arise or to become evident
at a time when members of the project team are in contact with members of the
customer organization. Therefore at every significant contact or transaction with the
customer, the project team elicits specific feedback from the customer and promptly
reacts to it in a closed loop manner. The principle is best illustrated with a couple of
simple examples.
TCB example 1
A few days ago, the same day it was requested, you mailed your customer counterpart
a report of some tests that you supervised. Just after dropping the report off at your
mail room, you called your counterpart to say that the report had been mailed and that it
should arrive in three or four days. This is a transaction in which dissatisfaction can
arise in at least two ways. One way is to have the report get lost or delayed in the mail.
Another is that the report may not provide the information your customer needs (even
though you may think it does!).
To avoid the first problem, you make a note to yourself to call your customer in four
days to be sure the report arrived. If it didnt, your proper course of action should be to
follow up and see what went wrong. If necessary, you should mail another copy of the
report, or send it overnight mail if the need is urgent.
If your counterpart did get the report, ask if it contains the specific information needed.
If it does, tell your counterpart you are glad you could be of service. If your counterpart
hasnt had time to look at the report yet, say that you would welcome his phone call if
there are any questions.
Of course, if your counterpart cant find the needed information, you should help find it.
If it doesnt exist, and you can readily generate it, do so. If an issue arises about
whether providing the information is in the scope of project work and the information is
not available, discuss the matter with your boss to see if you can accommodate your
customer. If not, be sure to call back and explain that the information is beyond the
scope of project work and suggest that if it is really badly needed, a contract change is
in order so you have financial cover to do the work.
After this transaction has been completed, log it in a convenient database or log book or
PDA. The entry should describe the wanted information, who wanted it and why, the
dates involved, and the final disposition of the matter. With such an entry, if any
question about the matter comes up in the future, you have the information you need to
resolve it.
The following key points can be made about the transaction described in this example:

Prompt responses to customer requests build the customers confidence in your

team.
The world is an imperfect place. Things get lost in the mail. You may think you are
sending what is needed, but then again your understanding of what is needed could

Page 39 of 199
be wrong. Entropy exists in human affairs as well as in thermodynamics. Murphy
and his Law lurk everywhere. Therefore meticulous follow-up is necessary to be
sure things dont get fouled up. Anticipate problems.

Surround your customer in a cocoon of confidence. Make him marvel that you are
so interested in his success.

Keep a diary of customer transactions. Never leave the customer hanging, even in
small matters. Close the loop.

TCB example 2
You have called a meeting at which several of your team members as well as customer
representatives will be present. Before you decided to call the meeting, you carefully
determined that what needs to be done cannot be done by telephone or by e-mail, thus
avoiding an expensive meeting. You have followed the principles of effective meetings
by publishing an agenda, setting a time limit, and assuring that the meeting place and
all needed materials will be available.
During the meeting, all members of your team are civil and courteous, even though one
of the customer reps is noisy and somewhat abusive. You scrupulously avoid criticizing
anyone. You carefully steer team members away from overly long war stories and side
issues, maintaining the meetings focus. You take (or have someone take) minutes and
assign dated action items. When attendees return to their places of work, or soon
thereafter, they find in the mail or e-mail a copy of the minutes and the action items.
You follow-up on the action items to assure they have been taken care of. You advise
attendees of their status as they are accomplished or otherwise disposed of.
Key points:

Meetings where customers are present are potentially a source of dissatisfaction.

Customers may not appreciate overly long and poorly structured meetings.

Failure to take and propagate meeting minutes and action items is sloppy and
wasteful of valuable time. It will lead customers to believe your team is not well
managed.

Courtesy and civility are critical in customer meetings. Rudeness and violation of
accepted norms of behavior can leave lasting feelings of ill will.

Follow up. Close the loop.

Some final comments before closing this chapter:

Page 40 of 199

If it becomes clear that anyone on your team has offended someone on the
customer side, the offending person must make a sincere apology, in person if
possible, and directly to those offended.

Hiring interviews dont always screen out team members prone to incivility. Any
team member who shows signs of incivility of any kind, including but not limited to
sexual harassment, coarse speech, and aggressive or rude behavior, must as a
minimum be counseled, and if necessary removed from customer contact.

Project teams must be aware of and respect cultural differences between

themselves and the customer. If the project team is going to work with a new
customer, the customers cultural modes and preferences should be studied and the
team should be briefed. Such study is obviously appropriate when dealing with
foreign nationals, but it is also warranted when merely dealing with a new company
of your own countrymen. What works in Dallas does not necessarily work in New
York.

Obviously a project team that doesnt get the job done will have an unhappy
customer. Fortunately for all concerned, such a team more often than not loses out
in the bidding process and never gets the job in the first place.

Chapter 6 Review Questions

1. Think of an example of customer dissatisfaction on a project you worked on. Try to
trace it back to its root cause. What could have been done to anticipate and avoid
the problem? How was it finally resolved?
2. Do you agree with the recommendation in this chapter to keep a log of customer
transactions to be sure the loop is always closed? Why?
3. How effective and well organized are your meetings with customers? Could they be
improved? How?

Page 41 of 199

Chapter 7Persuade your customer away from mistakes

Always a difficult thing to deal with in a pursuit is a customer whom you believe is
making a mistake. When you think this to be the case, its necessary to do some
rigorous self-examination to be reasonably sure its the customer making the mistake,
not you. There is always the temptation to think that you know better than the customer
does what the customer needs. Sometimes its just your self interest speaking.
Here are three of the most egregious mistakes a customer is likely to make in the
pursuit environment. We will discuss them in the order shown:

Wanting more than the available funds can buy.

Having poorly structured project goals.

Presenting a poorly prepared customer team.

Customer mistakes require fixes that are specific to the nature of the mistake, but there
are also some universal considerations. We suggest the following:

Always approach the customer with courtesy, even humility. Your goal should be to
help the customer get the best possible result, not to demonstrate how smart you
are.

Dont use abrasive words like mistake or bad idea with your customer. Instead
use terms like perhaps a better way or may we suggest or have you
considered?

If the customer recognizes a problem area and is willing to discuss it with you, you
should offer to help suggest possible solutions. It generally is not necessary to
provide solutions that favor your competitors! They are likely to provide those
themselves.

Wanting more than is affordable

In many circumstances this is the most serious mistake a customer can make. If not
corrected, it can make the pursuit a guessing game and can destabilize the project after
a contract is awarded. It seems to arise in two different ways:

The customer people who decide how much to spend and the customer people who
manage the work are disconnected. A common scenario in which this happens is
when the people at headquarters have a pot of money $X they are not using and
decide it would be nice to spend it on Project Y. The people who will execute
Project Y make a realistic effort to estimate its cost and come up with $k*X, where
k often is something like 1.5 or 2, or even more. The people who will do the project
make a plea for more money and are told thats all there is, followed by strong

Page 42 of 199
statements like We really need this project, so just go do it, or Go ahead and start,
we may be able to get more money next fiscal year. (Or not.)

The other way is when the people who will do Project Y dont understand it very well
and/or they have poor estimating capabilities so they simply estimate too low. The
lack of understanding could come from either poorly structured goals or from a
novice team with little experience in the subject matter.

We are not sure which is worse, a customer who doesnt have enough money and
knows it, or a customer who doesnt have enough money and doesnt know it. In the
former case, the customer will be tempted to award the work to the low bidder
regardless of whether that bidder understands the work. This can lead to project failure.
It also wastes the time and money of serious bidders who could do a good job if there
was enough money. In the latter case, the customers notion of the appropriate
competitive bidding range will be poor. Serious bids will be unaffordable, and this could
trigger cancellation of the project. But a poorly informed low bid could win, and again
the result could be failure.
If the customer is willing to listen, project teams can help correct this error by providing
informal cost feedback to the customer. This has to be done with full awareness that
your competitors may be cynically pumping sunshine to the customer to lead the
customer to believe that the stated needs are affordable given the available resources.
There is always the risk that as a bearer or bad news you will be rejected.
An effective way to provide informal feedback is to provide a credible cost study. This
could take the form of a study of cost outcomes on other projects of similar nature. It
could also include appropriate information collected by various public agencies. And it
could include results from parametric cost models of good repute.
Another good approach is to suggest that the customer order an independent cost
analysis. Your recommendation should be that this be done by consultants who have
no direct or even indirect interest in the project, and who have no fear of telling the truth.
Although this could be costly, it might be much preferable to a project overrun.
Whenever dealing with a customer that you think is moving out of the arena of
affordability, always keep in mind that the customer may have access to resources of
which you are unaware. For example, your customer may be seeking additional
allocations from other budgets you dont know about, or cancellation of some existing
project may be imminent, freeing up funds. So always proceed carefully.
Poorly structured project goals
We have over the years encountered six serious problems with project goals. Existence
of any of these can predispose a project to failure, and as a minimum will increase
project risks. Here are the six, and a few suggestions for dealing with them:

Page 43 of 199
Stability. One of the most difficult risks a project team can face is instability of the
project goals. Conscientious as a project team may be, it is hard (and expensive) to
satisfy a customer who keeps revising the goals. Of course, in the fixed price contract
project environment where the work content is tightly defined, the project team can
handle this rather neatly by recording all of the changes and presenting the customer
with the bill. This may or may not result in an unhappy customer.
In other situations, goal instability can be a difficult problem for the project team in
controlling the customers risk. Failure to control the customers risk can result in a
customer who is dissatisfied. Even though the customer is a major contributing cause
of the problem, the customer may blame the project team.
We believe instability of the goals has two main causes, 1) a poorly organized
customer, and/or 2) technological immaturity. Often the project team can help relieve
the instability problem if the customer is cooperative. The key is trying to identify why
instability may exist. If it is due to technological immaturity, it might be well to delay the
project (or create a less ambitious pilot project) until the technology is more mature. If it
is due to conflicts or uncoordinated decision-making in the customers organization, it
may be possible to resolve the problem at a higher level of management.
A common source of instability is multiple customers who keep disagreeing about what
to do. If it is necessary to have multiple customers, the distribution of power among
them and the protocols for exercising it should be carefully considered.
Sometimes it is helpful to do more prototyping. This means communicating better with
the customer what the product will be like without actually building it. There are many
forms of prototypes. Examples are brass boards (for electronic products), static and
working models, mockups, pilot plants and computer simulations. Software projects
often create so-called rapid prototypes that are little more than inactive or semi-active
screens the customer can look at to better understand what the final product will look
like. If the customer dislikes what is presented, changes to a prototype are relatively
inexpensive. Prototyping helps satisfy the customer who says, Im not sure what I
want, but Ill know it when I see it.
Anticipatory documentation is another form of relatively inexpensive prototype that has
been used successfully to assure customer satisfaction before proceeding with
expensive detailed development of a product. It involves creation of draft user guides or
training materials based on what the product will be like. By simply reading the
documentation, the customer is able to obtain an excellent mental picture of the final
product configuration.
There is a form of volatility of the goals that can be benign, but is not necessarily so. It
is called goals creep. Sometimes when a project is in progress, it becomes clear that
for a relatively small amount of additional time, money, or both, the project can be made
to produce benefits that outweigh the added costs. Or sometimes, for example in
military projects, a new or modified threat or problem is discovered that must be

Page 44 of 199
countered, causing goals to increase in scope. But all too frequently, goals creep
represents nothing more than a hidden agenda that is gradually revealed. When this is
the case, it is just a form of bait and switch. Hidden agendas and bait and switch are
discussed later in this section.
Basis in reality. Aside from goal instability, little can make a project more risky than to
have goals not based in reality. We have all likely had the experience of working on a
project where the goals were poorly grounded. Even though the plan may have been
thorough and the project team may have performed as well as could be expected, the
problem didnt get solved because its true nature was never recognized.
Goals can be at variance with reality in several ways. Some of the most common are:

Mathematical or logical error or misapplication of scientific principles,

misunderstanding of laws and customs, etc.

Failure to appreciate the size of the gap separating what is known and familiar from
the expected end state at project completion. Heres an extreme example of what
we mean: In 1492, suppose that Christopher Columbus decided to go, not to India,
but to the moon. He would have been about 470 years ahead of the needed
technology. No matter how much money Queen Isabella gave him, he would never
have made it in his lifetime. As this is written, there are probably projects out there
that will fail because their proponents do not understand that what they want to do
will not be possible for another 20 years, or more. However, we should keep in mind
that technology moves much faster today than it did in the time of Columbus.
Projects that anticipate rapid maturing of new technology are not necessarily a bad
thing. But the risks must be recognized.

Attempting to do too many new and untried things in one project. This requires a
long learning curve, the scope of which is almost always underestimated. A good
rule of thumb is that if we are trying to do more than two new things in one project,
the project is very risky. A frequent remedy for this is to divide the larger project into
two or more consecutive smaller projects. If there is a failure, the impact is likely to
be less.

Failure to determine the availability of a critical resource. The resource might be

people skills, equipment, infrastructure, or even data. It could also be political
support.

Failure to understand the nature of an existing situation, especially the nature of

complex systems that the project is intended to influence or with which it will interact.

The latter way of being disconnected from reality is sometimes recognized after the fact
by unintended consequences. A classic example is the introduction into agricultural
practice of the insecticide DDT. It was hailed as a boon to mankind, especially in third

Page 45 of 199
world countries, where it significantly raised crop yields. Yet only a few years after it
was introduced, it was condemned as an environmental disaster.
A post-project excuse commonly heard when goals are not based in reality is We didnt
know then what we know now. While that may be true, it may also be true that
someone could have, but did not, take the trouble to work the problem through before
starting the project. There used to be a common saying in project teams: There is
never time and money to do it right, but there is always time and money to do it over.
In todays competitive, resource limited environment, there is seldom time and money to
do it over. It needs to be done right the first time.
Another aspect of poor basis in reality is when cash flow or elapsed time constraints are
overly tight. This often happens because the constraints are rigidly set before there is a
good understanding of the desired product. This problem cannot always be avoided
when the project deals with very sophisticated state of the art systems. But it should
be avoidable for most low-tech public construction projects, infrastructure projects, and
other projects where there is a huge database of consistent cost and schedule
experience that can easily be used to verify estimates. Yet amazingly, these projects
often experience serious cost and schedule overruns. The difficulty is often traceable to
a lack of realism in the goals, often introduced by micromanagement and political
meddling. It can also be introduced by the opposite of micromanagementa failure of
proper oversight. Trust but verify, as a famous presidential saying goes.
Clarity. A clear goal is one that has definite criteria that can be used to decide whether
or not it has been met. A counterexample is: The software shall be user friendly.
This goal is vague and unclear. The customer and the project team may have radically
different ideas about what user friendly means. The difference in these ideas could
span a cost range of millions of dollars. If these extra millions are not in the plan, failure
is likely.
An unclear goal is often in reality a complex of linked sub-goals, which are not well
articulated. In failing to articulate them, risk is introduced into the project. Faced with
unclear goals, the project team will tend to work on what is most familiar, or what is
most convenient. The result is likely to be completely unsatisfactory.
It is seldom necessary to define every goal in a project with mathematical precision. But
certainly all of the important ones should be clearly expressed. Not all problems with
goals are preventable, but lack of clarity almost always is.
Generality. General goals have one or a few criteria. Specific goals have many. A
general goal in a project might be to create a system that will move all baggage from an
arriving aircraft into the baggage claim area within ten minutes of aircraft arrival. There
are many possible means for achieving this, and each of them can be defined by a set
of specific design requirements.

Page 46 of 199
A great source of risk in projects is the premature transition of goals from general to
design-specific requirements. It is very risky for project goals to prescribe specific
design solutions before the nature of the problem is clearly understood. What is
generally best is an orderly and careful transition from the general goals to designspecific derivative requirements, as the situation unfolds.
Particularly in complex cost-plus contract work, the customer must avoid the temptation
to over-specify the end product in the concept phase. This may force the project team
down a path that leads to a poor, costly design solution.
Linkages. We have already noted that vague goals can be a cover for a set of multiple,
linked sub-goals. When a set of linked goals is examined in depth, there can be several
types of linkages. Most notably, there can be positive and negative linkages between
goals. The result can be stresses and risks in the project.
If two goals are positively linked, satisfying one tends to satisfy the other. But if they are
negatively linked, satisfying one tends to dissatisfy the other.
Product performance goals and cost and schedule constraints have strong negative
linkages. Negative linkages are explicitly revealed in expressions such as cost /
benefit, cost efficiency, and cost effectiveness. Real projects must deal
successfully with negatively linked goals. They are unavoidable. The first step in
dealing with them is to recognize that they exist and to identify them.
One way to proceed is to give priority to one goal and let all negatively linked goals find
their own level. This minimizes risk. The more usual situation is to set limits on all
goals. But be aware that the tighter the limits, the higher the risk.
Visibility. A perilous situation arises when negatively linked goals comprise a hidden
threat that only becomes visible when trouble arises. It is important that goals be visible
when the project begins.
Unfortunately, hidden threats are not always easy to find, especially when they take the
form of a secret agenda that someone wants to keep under wraps as long as possible.
The best defense is generally a thorough review of all of the goals for consistency and
coherency. Hidden threats may reveal themselves simply because they distort the
pattern established by the goals that are clearly visible. Its a bit like having a snake
sleeping under a sheet. You cant see the snake, but you can tell theres something
under the sheet that doesnt belong there.
Ambiguous, obfuscating language often betrays a hidden threat. This is especially true
when it occurs in specifications that govern the performance of the projects product.
Whenever a specification is written in a confusing way, you should strongly suspect that
whoever wrote it doesnt know what he or she wants. Later, when he or she has finally
decided, you may be blamed for not understanding what was (according to him or her)

Page 47 of 199
always as clear as spring water. This sounds like a rare condition, but actually it is not
all that uncommon.
An especially pernicious form of hidden agenda is the bait and switch. The expression
bait and switch comes from the retail world. It happens when a merchant advertises a
product at a very low price to entice customers into the store. But when they arrive
there, they find that the advertised low cost product is mysteriously sold out, and will
never be stocked again. So the merchant attempts to sell them a much higher priced
and more profitable product. Something similar often happens in the world of projects,
especially government sponsored projects. Someone, often a project team or interest
group, successfully sells a project to a sponsor (such as Congress or a city government)
on the basis of a phony, low cost estimate. Once the project has begun, the true extent
of the cost is gradually revealed. It is typically much higher than the phony estimate.
The sponsor, to avoid losing face or for other reasons, goes along and continues the
project.
The bait and switch phenomenon in projects is not necessarily due to overt dishonesty.
It can also be due to pride, greed, and simple hubris. Truly independent cost reviews by
expert analysts are usually an effective remedy for the bait and switch.
In the visibility category, there is a subtle form of risk that might be likened to not being
able to see because you have a hundred bright lights shining in your face. Sponsors of
projects who have some uncertainties as to what they really want and are willing to
accept sometimes load up project contracts with extensive boilerplate language and
lists of related specifications to the point that even they dont fully understand what they
are asking for. This is especially common in government procurements, where 50 or
100 or more specifications may be listed. This gives the customer comfort that nothing
important has been left out. But it leaves the pursuit team in an uncomfortable
condition.
Often in a long list of boilerplate specifications one will find ambiguities and even
conflicts. Boilerplate specs are often neglected and get out of date. The pursuit team
either must try to sort it all out, and insist on exceptions when troublesome items are
found, or go ahead and accept the work as is and hope for the best. Chances are, the
fine print will never become an issue, but if it does, the problems could be huge.
A sponsor who wants a successful project will not load it up with unnecessary
boilerplate requirements that require a team of lawyers and engineers a month to sort
out. This practice is unprofessional. The dubious protections it provides are likely to be
more than offset by a higher price for the work.
Poorly prepared project team
The customer who does not understand the project well or who is in a rush to get it
started is likely to field a poorly prepared team to manage it. Poor preparation can be at
two levels and sometimes it occurs at both levels.

Page 48 of 199
At one level is the team that has been pulled together from various customer
organizations and other sources. It typically includes people who werent busy enough
where they were and may include new hires. Such a team probably has a poor
understanding of the nature of the project and may be weak in the technologies
involved.
At another level is a team that is inherently competent but has not had enough time to
work important project issues. There is a rush to get someone under contract and get
the project rolling. Unless the team is lucky, this situation will lead to costly mistakes.
If your pursuit team is competent you will be able to quickly sense that the customer
team has not reached that level. A common manifestation of weakness on the
customer side is likely to be poor understanding of likely costs and poorly structured
goals, both previously discussed.
Dealing with a poorly prepared customer team can be costly. If you expect the
customer team to be poorly prepared it is wise to plan to spend more interface time
explaining what you are doing and why. It also may be that they will tend to make
mistakes that you may be able to help them avoid.
Chapter 7 Review Questions
1. Have you ever encountered and had to deal with a serious customer mistake in the
pursuit phase? How was it approached? What was the eventual outcome?
2. Explain in your own words how the customer wanting more than he or she can afford
can result in project instability.
3. This chapter discusses six major problems with project goals. Can you name at
least one other?

Page 49 of 199

III Know What Your Customer Is Willing to Spend

Chapter 8Find the upper and lower bid limits
General considerations
As a contractor, you must be seriously concerned with the question of what the
customer is willing and able to spend on a project opportunity you think you want to
pursue. The primary concern of course is being able to bid an amount that the
customer can afford, but there are several side issues as well, for example:

Does the customer now have the money in hand, or is there a process the customer
still has to go through to get it? How likely is it that this process will fail? How long
will it take if it succeeds?

How powerful is the advocacy for the project relative to the resistance against it?
Who are the champions and who are the resisters? Who ultimately decides?

What are the chances the project will be abandoned or seriously downgraded due to
its being unaffordable?

What constraints will there be on the rate at which funds are spent? Will these
handicap efficient flow of the work?

Are the customers financial constraints consistent with what the customer wants to
accomplish? Are the goals realistic?

What is the minimum bid the contractor would find acceptable?

Some of these issues relate to the often-asked question Is the project real? If there is
a significant chance the project will not go, and especially if you perceive your win
probability to be uncompetitive, you may decide you do not wish to mount a pursuit.
Pursuits are not free, and every misguided pursuit you decide to take on may foreclose
going after another, better opportunity.
Sometimes a customer will respond forthrightly to direct questions about these critical
issues, and sometimes he or she may try to hide some of the answers, sometimes for
valid reasons. In that case some digging may be necessary.
Government customers (at least in Western nations) usually operate on a fairly open
basis, unless there is a specific national security or political problem with being too
open. Several channels to good information may be available, including legislative
sources, freedom of information and open meeting laws, trade publications, reference
databases, lobbyists, and the press. Private-sector customers may be more reclusive
for various reasons, but still a lot of their information finds its way into the public domain,
especially for publicly owned companies.

Page 50 of 199
An often-reliable guide to future behavior is past behavior. Like people, organizations
develop habits. Study of past behavior may be worthwhile in estimating what a
customer is likely to do in the future. For example, if a customer is known to have a $20
million budget for a project, historically you may know that 10% will be reserved for
customer management functions and another 15% for contingencies.
Like poor poker players, customers often signal their intentions without realizing it. You
need to stay in frequent contact with customers and prospects and closely observe their
tells, that is, their language, body language, and actions.
All budgets are based on certain assumptions. Can you find out what they are? Are
they realistic? Government budgets may have been the subject of legislative hearings,
transcripts of which are available to the public. Even if exact numbers are concealed,
knowledge of estimating assumptions made by the customer could lead to a good
guess as to his budget.
Customer budgets are (hopefully) based on estimates. Are these estimates
competently made? If so, are they later nullified at a high level of customer
management for political reasons? Are they fiat estimates made by upper management
that are otherwise unsupported? These practices are commonplace in some
government agencies, and are not unheard of in private firms. A frequent result is
under-funded and poorly performing projects.
The top end of the competitive range
Determination of the top of the competitive bidding range is normally approached in one
(or both) of two ways. The first is examination of the customers available budget,
assuming it can be determined or guessed to a close approximation, combined with
consideration of historical patterns as to allocations for internal costs and management
reserves.
A key issue in this process is whether the customers expectations fit within the amount
available. For this reason, it is well to also pursue the second approach, namely to
create a ghost estimate for the project.
A ghost estimate is an estimate made by or on behalf of the prospective contractor of
what the project should cost, with a contingency added to account for obvious risks,
with on the order of 75 or 80% confidence of having enough money to complete.
Such an estimate must make assumptions about the product design and programmatic
solutions that will be adopted, and these should be based on the most expensive
solutions the customer is likely willing to accept.
If the ghost estimate reveals that your customer is expecting too much for the available
money, you should consider warning your customer away from this mistake. See
Chapter 6 for further discussion of this.

Page 51 of 199
As a practical matter, a ghost estimate cannot be made using the traditional bottom-up
estimating technique. In this technique, the pursuit team members, based on personal
and group experience, make wholly subjective estimates and sum the results. The
information available in the early pursuit phase almost always is too little for a reliable
bottom-up ghost estimate. The realistic estimating methods available are the analogy
and parametric methods.
An analogy estimate uses judgmentally adjusted comparisons with past projects of a
similar nature for which costs are known. You must be careful to take note of and
account for all of the major differences in the projects. Examples of commonly
encountered differences are year dollars (cost inflation), complexity of the product,
inheritance from past projects, and skills of the project team. Production quantity
differences must be dealt with carefully due to the complexities of the learning effect.
The best tool for ghost estimates is a credible parametric model, if such is available in
your industry. A parametric model is a sophisticated, automated analogy estimator that
asks the user for perhaps 10 to 50 bits of information about a product element, and then
produces one or more cost estimates for it. Typical costs produced are for development
and implementation. Its basis typically is a large pool of historical cost results and
project characteristics that have been subjected to sophisticated statistical analyses.
Most contractors license or buy regularly updated parametric models from companies
that specialize in this field. A few contractors have the resources to build their own, but
this can be expensive, and the model can quickly become obsolete if not regularly
updated. Failure to update is a common problem. Another common problem is that
contractor models are often too specific to one product type and cant estimate much
else.
The name parametric refers to the fact that these models require information about the
parameters of, or related to, the object being estimated. For example, to estimate cost
of construction of streets in a new subdivision, a parametric model designed for this
purpose might ask the user about dimensions, features, materials used, and so forth.
For development of software, a model might ask about number of lines of code,
programming language to be used, experience of the software developers, complexity
of the softwares functionality, etc. This is the superior approach for ghost estimating
because one can usually supply the parametric information needed by the model,
whereas good analogies may not be available, and judgmental adjustments of them are
not always reliable.
One caution: Parametric models tend to give industry average answers. For a particular
project, your team may be better than average, or worse. The best parametric models
have a calibration feature that allows you to make adjustments (usually a few
percentage points) to the model to bring its answers more in line with the way you do
business.

Page 52 of 199
The low end of the competitive range
What about the low end of the competitive range? Theoretically, a contractor with a
good record of performance and a lot of cash could offer to do the project for nothing,
for whatever benefit the experience might bring, but such an event is rare, and such an
offer normally would be suspect to the customer. Almost everyone believes in the
saying that there aint no such thing as a free lunch, and almost everyone becomes
wary if one is offered.
A common problem facing customers is contractors who bid at their expected cost or
below in the hope of buying in. Once the customer is committed to them, they hope
the customer will ask for many changes for which they can charge exorbitant prices.
Another problem facing customers is inexperienced contractors who dont understand
the difficulty of the project and bid too low out of ignorance. Such contractors almost
always get into serious trouble, and may even abandon the project.
Most customers today are well aware of these problems. While they are attracted to
real bargains, and will generally choose the lowest responsible bid, they will avoid a bid
they think is too low. Their process for determining this cutoff number is typically to
select a low cost, low risk approach and to do a ghost estimate of it, with assumptions of
small or zero contingency funds and low or zero profit to the contractor. And that is
exactly what you should do. After doing this you should ask yourself whether you are
bidding this same low cost, low risk approach, and if not, why not? (See chapter 9 for
further discussion of this vital issue.)7
You should set the competitive range early in the pursuit cycle so that you can estimate
and work toward your competitive bid amount.
You should frequently update the assumptions that went into this initial estimate, and be
willing to reset the competitive range as new information becomes available.
Chapter 8 Review Questions
1. On your most recent major proposal, how did you arrive at your bid amount? Did
you win? Why?
2. Do you have or have you had a customer whose budget is politically derived as
opposed to being estimated realistically? How did you come to know that? What
problems has it caused?
3. Has your organization ever made a ghost estimate of either end of the competitive
range? If so, how did you do it? Did you use the results to position your bid
amount?
4. Does your organization use parametric cost models? Does it use them to help
determine the bid amount?
7

A situation that sometimes arises is the cash-rich competitor who wants the project so badly that he bids on a loss
basis. He may do this to capture a leading place in a new technology, or perhaps simply to cause short- or long-term
damage to one or more competitors. If the customer will go along with this, it can be very difficult to defend against
unless you are willing to do the same thing.

Page 53 of 199
5. Have you ever faced a competitor who literally tried to buy the project at a loss in
order to assure a win? What were his motivations? What was the ultimate
outcome?

Page 54 of 199

IV Design Your Project

Chapter 9Use modern programmatic design techniques
We have defined something we call project design to include both programmatic
design and product design. Product design of course is the design of the product that
you will deliver to your customer if your proposal is accepted and you are awarded a
contract. We will have much to say about that in subsequent chapters. Our concern in
this chapter is programmatic design.
Customer requests for proposal typically have a lot to say about what is desirable in
terms of product functionality, and sometimes about what they can and cannot afford.
Sometimes they are much less instructive about how you should run the project. Still,
most customers are interested as a minimum in having a warm and fuzzy feeling that
you will manage efficiently and that you will not fail. Programmatic design is the way
you try to provide this assurance.
As a bare minimum, programmatic design should respond directly to every single
programmatic goal formally stated in the request for proposal, and generally also to
ones stated informally by authoritative customer voices unless you have extremely good
reasons to ignore them.
A number of best practices have grown up in recent years with respect to project
planning and management. Not all of them are appropriate for every project. It will be
helpful to begin by discussing what a project truly is as a means for understanding why
some of these best practices make sense. Then we can discuss the best practices
themselves.
The nature of projects
Websters New Illustrated Dictionary gives the following primary definition of project.
Something proposed or mapped out in the mind, as a course of action, a plan.
An Internet dictionary site provides this definition:
A plan or proposal; a scheme. Also, an undertaking requiring concerted effort.
Clearly, the notion of a project is closely associated with the notion of a plan. The
notion of a concerted effort also rings true. Implicit in these definitions, but not clearly
enunciated, is the notion of goals. You are not likely to decide upon a course of action
or a concerted effort that goes nowhere.
To further flesh out the definition, consider that a project is an agent of change. Its
purpose is to change something that already exists, and often to create something

Page 55 of 199
entirely new. In a project, that which exists may be replaced, enhanced, or eliminated,
or some combination of these.
We bring the notion of change agent into the dialogue because our instincts should
warn us that attempts to institute changes can have unforeseen outcomes. Projects of
all sizes and shapes are inherently risky to some degree, larger ones generally much
more than smaller ones. Therefore, to effectively manage a project requires some
understanding of how to manage risk. Some people go so far as to say that project
management is project risk management, because without risks, project management
could be turned over to the project team, or nowadays even to computer programs that
remind everybody what to do next, once the plan is set in motion. We dont go that far,
but we do believe that management of risks is much of what a project manager should
be doing, and also a considerable part of what his team should be doing.
The concerted effort mentioned in one of the above definitions calls to mind that
pursuits and resulting projects virtually always require a mustering of the resources
needed to conduct them. The needed resources are seldom standing idle and available
where and when the pursuit / project team (PPT) needs them. Resources needed by
the PPT that must be mustered include time and money, of course, but also people,
materials, equipment, data, information, facilities, and infrastructure.
This mustering and subsequent release of assets to do a one-time job is a key
characteristic that distinguishes projects from routine operations in business or
government.
A reasonable analogy for the role of projects in human affairs is the operation of an
aircraft. Getting the aircraft airborne is a project. Once it is airborne, it flies more or
less uneventfully (most of the time!) to its destination, and the resources used to get it
airborne are diverted to less stressful pursuits, like drinking coffee and taking naps,
assuming you have a co-pilot. A second project is required to get the aircraft safely
back on the ground. You should note that common knowledge among pilots is that the
most dangerous parts of a flight are the takeoff and the landing, especially the takeoff.
By analogy, projects are generally riskier than routine business operations.
Projects begin with the perception of a need for change. Typically, some project
champion (a person or a group) sees an important unmet need or opportunity, and the
project is born. The first step after recognition of the need for change is to define the
projects positive and negative goals. A positive goal is some new state of nature that
someone wants to create. A negative goal is a constraint someone does not wish to
violate. Typical negative goals are caps on costs, limitations on project duration,
environmental constraints, avoidance of undesirable secondary consequences, required
practices and processes, licenses, clearances, permissions and the like. Note that the
coexistence of negative and positive goals is inevitable in any project, and that this
stress assures that there will be risk. The source of risk is the tension between positive
and negative goals.

Page 56 of 199
The goal creation step is often contentious, because different people may have different
perceptions of what changes are needed, how much time and money should be spent,
and what compromises should be made. Project champions and the sponsors of major
technology projects who support them typically screen a proposal to initiate a major new
project by looking at many alternatives and options before accepting it. Two questions
must be answered for any new project: 1) why do this project at all, and 2) why not do
some other project instead?
Ultimately, goals are the criteria used to determine if a project has been successfully
completed. If all of the goals are unequivocally met, we say that the project is hugely
successful. If a few are not quite met, but the deviations are small, we generally
concede moderate to good success. Anything less is generally viewed as a failure or at
least a near-failure. Most would concede that the following are examples of project
failures:

The partially completed project was cancelled because of actual or likely cost or
schedule overruns, or apparent inability to meet positive project goals.

The cost or schedule constraints were seriously violated, with serious

consequences, even though the project was completedonly extreme need for the
product kept the project from being terminated.

There had to be a major and unwanted restructuring of the goals after the project
started in order to avoid an overrun condition in cost, schedule, or both.

The project created seriously bad unintended consequences for the sponsors or for
others.

A vital mission related to the project was not completed.

Revenues were so small that a financial loss resulted (for projects that have revenue
goals).

Programmatic planning is important because it is the medium through which the goals
of the project and the proposed means of meeting them are communicated within the
project team and to interested stakeholders outside the team. The project plan is a
dynamic, not a static entity. The rough plan that was drawn up when the project was
first conceived will seldom be a suitable guide to action when the project is running at
full speed later on, when 50 or 500 or 5,000 people are involved. The plan is merely an
expression of what is currently considered to be the best course of action to achieve the
goals. It is not a god. It can and should be changed when it needs to be changed.
In todays world, it is not uncommon for the plan in a major project to change in some
degree almost every day due to new or unforeseen circumstances. Projects tend to be
dynamic. This is both good news and bad news. The bad news is that changing a plan
takes effort and costs money. And, the new plan must be checked to see if it still

Page 57 of 199
permits the goals to be accomplished with acceptable probability. The good news could
be that the project team is kept current in what is supposed to happen, so they can
adjust their actions accordinglythat is, provided the changes are promptly and clearly
communicated to them.
Programmatic design best practices
A well-conceived project plan includes most if not all of the following elements, in one
form or another:

Positive and negative goals.

Statement of work (SOW).

Baseline product design.

Work breakdown structure (WBS).

WBS dictionary.

Project schedule.

Project cost estimates.

Project budgets.

Staffing plan.

Risk management plan.

Statement of earned value.

Other plans for the acquisition, retention and use of assets.

Disaster recovery and business continuity plans.

Miscellaneous ad hoc plans.

Record of tradeoff analyses contemplated and conducted.

Revenue forecast.

Project metrics.

Project phases definition.

Page 58 of 199
The project plan can be implemented in many different physical forms. Parts of it
typically are conventional text documents on paper. Other parts may be graphical
material on paper. A few parts may be graphical material mounted on a wall, such as a
master schedule. Increasingly, project plans are maintained in electronic format only, to
enable rapid access by computers.
Because plans on major projects may many component parts stored in different
locations, it is wise to maintain a project plan index that can be readily consulted by
team members.
This index could be used at any time to locate the current authoritative documents and
artifacts that define the project plan.
Each of the above listed plan elements is worthy of further discussion to clarify its
function and establish its need. We do so here.

Positive and negative goals. These are the positive and negative goals as agreed
with the project customer. See Chapter 2 for further discussion. They are the
criteria used to measure project success. Often project goals are scattered widely
throughout documentation and sometimes authentic verbal communications
received from the customer. The proposal / project team (PPT) benefits enormously
if these are collected and catalogued in a well organized database. The cost of the
collection and cataloguing activity usually is more than repaid by the elimination of
confusion that can be caused by complex goal statements and location and
correction of vague or conflicting goals.

Statement of work (SOW). The SOW describes what the team is supposed to
accomplish and by when. The SOW is sometimes integrated into the goals, but may
also supplement them separately. The SOW is initially generated by the customer,
in its broad strokes. Details are supplied by the PPT. A common mistake made by
customers is to let the SOW drift into decision areas best dealt with by the
contractor.

Baseline product design. This is a description of the current concept for the product
design solution that is believed will satisfy the goals. A baseline design is typically
defined in the form of drawings and specifications. Derivative product requirements
and all existing design information plus information about manufacturing or other
implementation or support processes are also included in the baseline. These are
details that flow from the selection of a particular baseline, as opposed to
requirements directly associated with the customers goals. It is important not to
confuse what the customer wants with what you say the solution should be. The two
must be maintained separately to assure integrity of the design process. A baseline
is not necessarily a completed design. Early in the project, it could be little more
than a conceptual sketch with some explanatory text.

Page 59 of 199
o Failure to maintain an early and unambiguous baseline can lead to project
drift and working at cross purposes. Team members must be able to readily
distinguish between the currently agreed baseline and other options that are
under study as possible baselines.
o PPT members must know at all times and with absolute clarity whether what
they are working on is 1) further definition of details of the current baseline, or
2) speculative studies that could lead to adoption of a different baseline in the
future. Confusion of those two types of work has led to wasting thousands of
labor hours on projects and is a leading cause of cost overruns.
o A change in baseline must be executed crisply, much as a change in direction
is smartly executed by marching troops. To minimize waste motion and
misunderstandings, the plan must contain a command language for
implementing baseline changes that is well understood by the PPT. A
command language is a consistent means of communication that is well
understood by all core team members.

Work breakdown structure (WBS). The WBS is a hierarchical list of (mostly)

product-oriented items to be designed and / or implemented by the team to create
the overall product defined by the baseline design. Although purists may insist
otherwise, most projects find it convenient to have some elements of the WBS that
are not directly product-oriented. For example, in addition to elements for a Wing
or the Control System of an aircraft development project, there also could be a
Project Management element, and perhaps a Legal Matters element. Exhibit 9-1
presents a simplified WBS for an aircraft project.
Exhibit 9-1--Example (Simplified) WBS for an Aircraft Development Project
WBS Element #
0
1
1.1
1.2
1.3
2
2.1
2.2
2.3
3
3.1
3.2
3.3
3.4
4
4.1
4.2
4.3
5
5.1
5.2
5.3
6
7

WBS Element Name

Total Aircraft
Fuselage
Nose Section
Center Section
Aft Section
Empennage
Vertical Fin
Left Horizontal Fin
Right Horizontal Fin
Wing
Primary Structure and Wing Box
Skins and Secondary Structure
Pylons
Nacelles
Propulsion
Engines
Fuel System
Fire Suppression System
Control System
Cockpit Controls
Autopilot
Actuators and Sensors
Landing Gear
Avionics

Page 60 of 199
8
9
10

Environmental System
Fittings and Furnishings
Project Management

o Often the same WBS element is used for both development and production, but
with an added code of some sort to separate the work. For example, autopilot
development might be coded 5.2D and autopilot production might be coded 5.2P.
If the project must account for work beyond development and production, such
as deployment, operations, and maintenance, the usual practice is to append
additional elements to the WBS, many of which may not be product oriented,
such as fuel and crew costs, and airport access costs.8
o The customer may (or may not) specify the top two or three levels of the WBS.
The contractor usually is expected to define any lower levels needed for effective
project management. In practice, work breakdown structures that go beyond four
or five levels deep are difficult to manage.

WBS dictionary. The WBS dictionary is a description of the work to be

accomplished for each WBS element. Such descriptions are sometimes referred to
as work packages and may include budget and schedule allocations and a wealth
of other information. Creative variety abounds in the way projects handle the WBS
dictionary function. The important thing is that there must be a way for core team
members to understand the nature of what is (and what is not) included in each task
beyond a simple title such as Autopilot.

Project schedule. Every project of any importance must have a schedule so that
team members know, as a minimum, when tasks are supposed to begin and end. If
all tasks are sequential, that information can be conveyed by a WBS listing with
begin and end dates appended (see Exhibit 9-2). Using the horizontal bar chart
graphical technique expands the simple listing into what is known as a Gantt chart
(see Exhibit 9-3). A Gantt chart contains essentially the same information as a
simple listing of dates, but makes it easier to visualize. In a Gantt chart it is also
possible to portray concurrent tasks.
Exhibit 9-2Simple Sequential Schedule
Prepare kickoff briefing
Present kickoff briefing
Prepare list of subject matter experts
Contact subject matter experts (SMEs)
Prepare SME statements of work
Negotiate SME statements of work
Contract with SMEs
SMEs prepare course materials
Review and approve course materials
Issue course materials

Jun 1
Jun 8
Jun 9
Jun 15
Aug 3
Aug 12
Aug 22
Aug 30
Oct 15
Oct 28-Nov 5

See Appendix E for a discussion of the shortcomings of typical work breakdown structures, and what might be
done about them.

Page 61 of 199
Exhibit 9-3Simple Sequential Schedule Expressed as a Gantt Chart
Jun

Jul

Aug

Sep

Oct

Nov

Prepare kickoff briefing

Present kickoff briefing
Prepare list of subject matter experts
Contact subject matter experts (SMEs)
Prepare SME statements of work
Negotiate SME statements of work
Contract with SMEs
SMEs prepare course materials
Review and approve course materials
Issue course materials

o In modern practice, the Gantt technique if often used to depict simplified

versions of project schedules for uses such as customer and management
presentations, but large, important projects almost always will create as well a
full-fledged schedule network. A schedule network is a schematic that
typically depicts tasks as rectangular boxes with interconnecting lines (other
styles are sometimes used, but this is the preferred style). The
interconnecting lines show the dependencies among tasks, that is, what must
be completed before a given task can be started. Exhibit 9-4 shows a simple
example of a schedule network. A major advantage of the schedule network
method of schedule presentation is that you can use it to find the project
critical path. The critical path is the longest path through the network, from
project beginning to project end. It establishes the total duration of the
project.

Exhibit 9-4 ScheduleTank Purging System Schedule

Order Air Compressor
6 weeks, $20K

Install Air Compressor

1 week, $15K

Construct Foundation
3 weeks, $5k
Integrate & Test System
1 week, $15k

Start

Order Piping
1 week, $15K

Install Piping
4 weeks, $50K

Order Controls
5 weeks, $15K

Install Controls
4 weeks, $25K
Manage Project
10 weeks, $60k

Finish

Page 62 of 199

o In Exhibit 9-4 there are four paths (left to right) through the network. The longest
path is ten weeks, and for it the boxes are shaded. The three tasks on the critical
path need more management attention than other paths because any delay on
this path stretches out the whole project. All of the other paths have slack, that
is, delays up to and including the amount of slack will not affect the overall
project duration. Your customer will be pleased to know that you understand
which tasks are on the critical path, and that you intend to give them extra
management attention so that they wont be late in completing.
o The task Manage Project in Exhibit 9-4 is not actually a path through the network.
It is an example of a spanning or bridging task, also called a hammock. All
spanning tasks assume the length of the tasks they span. The Manage Project
task spans the entire project, so its duration is equal to the length of the critical
path.
o In the exhibit, task duration and cost are shown for each task. This illustrates
that many different types of information can be shown in task boxes in a
schedule network. Other information that might be shown is a start and an end
date of each task, name of task manager, and so forth.
o Start and end dates of tasks that have slack are ambiguous unless some kind of
rule is specified. The most common rules are As Soon As Possible (ASAP) and
As Late As Possible (ALAP). ASAP is the most common rule, perhaps because
it gets things done early and minimizes the chance that some delaying event that
occurs can cause a late completion. ALAP is sometimes used to delay cash
flows associated with tasks, or to level labor resource requirements. Start time
rules intermediate to ASAP and ALAP are also used for manpower leveling.
o The tasks shown in a schedule should be the same ones shown in the WBS, and
should have exactly the same names. This rule is sometimes ignored to the
confusion of all concerned.
o Remember: a WBS is a hierarchy, and a schedule, especially a network, may or
may not be expressed as a hierarchy. Frequently, a schedule network will show
only the lowest levels of the WBS hierarchy.

Project cost estimates. Project cost estimates are preferably made for each lowest
level task in the WBS. Sometimes they are made at higher levels, because of use of
some preferred estimating process that does not lend itself to estimating at the
lowest level. If this is done, we recommend that allocations be made downward to
the lower level tasks in some rational fashion. This allows all lowest level tasks to
have both an assigned duration and an assigned cost. This can useful in several
respects, for example in trade studies, risk analyses, and task management.
o Cost estimates are usually made separately for labor costs (based on labor
hours), material costs, and other costs, for each task listed in the WBS, and

Page 63 of 199
each fiscal period of interest (often monthly, but sometimes weekly or even
daily). The cost estimates must be based on the baseline product design and
other parts of the plan concerned with implementing the baseline product
design.
o It frequently happens that various parts of the cost estimate are made using
different cost estimating methods. This is perfectly acceptable. The best
available method should be used for each estimate.

Project budgets. Budgets are financial allocations to groups or functions within the
team that show how much they are authorized to spend and when. Typically, the
budgets are based on the cost estimates, except for funds held in reserve by the
project manager as a means of dealing with risks and problems. (Sometimes project
budgets have no connection to estimates. This can happen when the project
sponsor says This is all the money I havelive with it, and the project does not
shrink to conform. This unfortunately common situation is a recipe for project
disaster.)

Staffing plan. The staffing plan describes by name or at least by skill category each
person expected to work on the project. The plan also identifies which functional
group in the project team each person is to work in, and who leads that group. The
staffing plan also shows how many hours each person or skill category is supposed
to work in each fiscal period, and on which tasks.

Risk management plan. The risk management plan usually comprises descriptions
of identified risks and their possible project impact, plans for avoiding or modifying
risks, the accomplishments to date in modifying risks, and the special expenditures
budgeted or incurred to modify risks. Persons responsible for risk mitigation actions
are also usually named.

Statement of earned value. A statement of earned value compares what has been
done and what has been spent at the present time with what the plan calls for. It is
a measure of success to date in overcoming risks and problems. It also can be
extrapolated to roughly predict future success (or failure).

Other plans for the acquisition, retention and use of assets. If appropriate, there
may also be other plans for the acquisition, retention, and use of various assets,
such as capital assets, raw materials, manufactured items, expendable items,
computers, data services, consultants, utilities, local transportation, etc. From a risk
management standpoint, such plans should always exist and be scrupulously
executed unless the availability of the assets is otherwise assured.

Disaster recovery and business continuity plans. It may be appropriate to have

disaster recovery plans and also business continuity plans that are not necessarily
limited to natural disasters. A disgruntled employee may do more damage than a
hurricane. An embezzler can wreak financial havoc. In todays computer dependent
word a server or data line failure can put a project out of business, at least for a time.

Page 64 of 199

Miscellaneous ad hoc plans. Various other plans may also be needed, such as for
human safety, quality control, hiring, etc. The general rule should be, if something is
important to avoiding project failure, or hurting people, or loss of vital assets, have a
plan for it, and make sure the plan is followed.

Record of tradeoff analyses conducted and accomplished. The baseline product

design, as it evolves, is always the result of tradeoffs between design options.
These tradeoffs typically include customer satisfaction, cost, schedule, and risk,
among other factors. It is important that the project team not lose sight of how it
came to select the current design baseline, while moving away from previous design
baselines. Loss of this understanding can result in confusion and reinventing the
wheel.

Revenue forecast. Many major projects are managed totally from a cost
perspective, even though they may generate revenue after or even before project
completion. But if revenue generation is expected as part of the scope of the
project, then the plan for revenue generation should be included as part of the
project plan. Once the time has come when revenue is expected to flow, the actual
flow of revenue should be recorded and compared to the plan. Activities to ensure
or enhance revenue flow should be recorded.

Project metrics. Project metrics are records of trends in major results related to
satisfaction of goals and derivative requirements. For example, if maximum product
weight is a key requirement, then a record that tracks computed or actual weight as
the project proceeds is a vital metric. Metrics are important to an understanding of
how well the project is meeting positive and negative goals and derivative
requirements.

Project phases definition. One last aspect of project plans needs to be discussed
before moving onproject phases. Larger projects typically are divided into several
major phases. There are many preferences for how to do this, and often the project
team must follow the scheme of phases decreed by the customer. A generic
scheme for phases that has wide acceptance follows:
o Concept. This is the initial phase wherein the need for the project is first
understood, and advocacy for it begins to build. The key positive and
negative goals are roughed out. Steps may be taken to alert or even solicit
help from organizations that may later be involved, such as potential prime
and subcontractors, or other departments within the same organization and to
solicit from them advice on how to structure the project. The costs of the
concept phase are often not considered to be project costs, but bid, proposal,
or business development overhead expenses.
o Business case development. In this phase the value of the project is initially
assessed. This phase often runs more or less concurrently with the concept
phase. The assessment may be done based on a number of different criteria,

Page 65 of 199
such as return on investment, net present value, internal rate of return,
competitive positioning, customer satisfaction, long term stability,
effectiveness, survival, mission objectives accomplished, etc. Government
projects often use value measures such as benefit / cost ratio or cost
effectiveness. It may be more appropriate in a military project to use the
phrase threat case development rather than business case development.
Usually business (or threat) case development includes some consideration
of inherent risk, as well as it can be understood at the time. Contractors or
other performance agents are contacted and qualified. They may submit
rough order of magnitude cost estimates. If a formal proposal is required
either internally or externally, it is prepared as part of this phase. The costs of
the business case development may not be considered to be project costs,
but rather bid, proposal, or business development overhead expenses.
o Preliminary design. In this phase, available product design options are
explored and traded off, and at least the first baseline design is created.
High-level derivative requirements and specifications are developed. Needed
project sites are explored and surveyed. Some may be acquired. Study of
logistics, safety, reliability and support begins. Critical designs requiring longlead procurement are detailed. Development and qualification testing is
performed. Analyses, simulations, studies, etc. are done, and models,
prototypes, and pilot plants are created and tested. The phase typically ends
with a comprehensive product design review.
o Detail design. In this phase the entire design is detailed in specifications,
drawings, and reports. Tooling and other implementation aids are designed
and built. Support equipment and facilities are designed and built. Product
validation testing is performed. Implementation and deployment planning are
completed. Critical material is acquired. Sites not already owned or
otherwise available are acquired. Sites are prepared for implementation and
deployment. The phase typically ends with a comprehensive product design
review.
o Implementation. In this phase the product is created. The means of creation
vary with the nature of the project. In hardware projects, implementation
generally means manufacture. In software projects, it means design, coding,
test, and related activities. In construction projects, it means construction
work at the site, and related support activities. In a health care project, the
product could be a set of procedures to be followed, or it could involve the
acquisition and use of new diagnostic tools. In a financial project, the product
might be a new instrument for investment. Creation of the product ends with
acceptance and deployment.
o Operations and support. In this phase the product is operated and supported
in its deployed state. Maintenance, adjustments, retrofits and repairs are
performed. In many projects, this phase is not the responsibility of the team

Page 66 of 199
that created the product, yet it may have large inherent risks, such as
warranty costs, for the sponsor or other stakeholders.
o Retirement. In this phase the product is retired and disposed of. This may be
irrelevant to some projects, but to others, such as the aircraft industry,
chemical plants, factories, or especially the nuclear power industry, it is a
major factor. Retirement is not always considered to be a part of the project.
In smaller projects, it may be regarded as simply a routine business activity.
Not every project has all of these phases. And in projects that have them, sometimes
they are at least partially concurrent. Software development projects usually combine
design and implementation. If the project includes revenue generation, that is usually
included in operations and support. That phase also typically includes warranty actions.
Chapter 9 Review Questions
1. What ultimately are the criteria a project team will use to determine whether or not a
project is successful?
2. What significant demands regarding programmatic features or approaches has your
current or most recent customer imposed on you? Do you regard them overall to be
helpful or detrimental to the success of the project?
3. On your current or most recent project, how easy is (was) it for a team member to
locate for purposes of understanding and verification any part of the project plan? If
there are obstacles to this, should they be removed?
4. Do you think your teams project planning is as thorough as it should be? What
would you do to improve it?

Page 67 of 199

Chapter 10Find minimal balanced and efficient product design solutions

In chapter 4 we discussed how our products cost or difficulty distribution should
reasonably reflect our customers perception of what is important. This is the issue of
design balance. If the customer perceives that the product we want to design
overemphasizes some features at the expense of others, the customer may become
uncomfortable, even dissatisfied, as discussed in chapter 5. A customer in this state
will be less inclined to award us the contract we seek. There is, of course, the
possibility that the customers wants are poorly conceived, and it may be to our benefit
to try to lead him away from mistakes, as discussed in chapter 7. Having done (or at
least considered) all of that, we need to understand what the customer can afford to
pay, and what the customer perceives as the minimum responsive bid, as discussed in
chapter 8. Then, as discussed in chapter 9, we need to design a project process that
will encourage the customer to believe that we are not likely to mismanage the project.
That brings us logically to this chapter.
It is of course unwise to offer the customer a product that is seriously unbalanced with
respect to his goals. It can lead to losing the bidding competition. Oddly, another easy
way to lose a bidding competition is to offer the customer more than has been asked
for.
Its easy to demonstrate how this works. The customer asks for X and we offer X+Y. X
costs $100 and Y costs $10. Our bid is $110 plus contingency and profit. Our
competitor offers X and assuming equal efficiency as a bidder, he or she bids $100 plus
contingency and profit. That bid is probably more than 10% less than ours. (Offering Y
likely increases not only our costs, but also our contingency allocation and our profit
expectation.) Do we lose?
Generally, we do. There can be special circumstances where we do not. Here are two
of them.

Based on our intimate understanding of the customers wants, we KNOW that the
customer secretly wants Y and is willing to pay extra for it. Our competitor has failed
to reach this same understanding because Y was not listed as a goal in the written
request for proposal.

The customer has a special place in his heart for us and is willing to accept our bid
even though it is higher than the lean but adequate bid of our competitor.

In the first of the above two situations, we would be wiser to include Y as an option, not
as part of our primary bid. That way, our bid can be more competitive and if our
customer really wants Y, the option is available. In the second situation, we must be
careful. Someone in our team and/or someone in our customers team may be risking
sanctions.

Page 68 of 199
From this point on we will accept it as a given that it is best not to add into our bid any
features beyond what our customer has asked for, with one exception, as described in
the next paragraph. If we think our customer might want them, we add them to the
proposal as options.
The exception is when the added features or advantages have no additional cost or the
cost is so low as to be immaterial to the customer. Then we can add them gleefully and
brag about them in our proposal.
Adding features beyond what the customer has requested in his goals statements is in
principle a simple thing to avoid. We simply dont add them. Would it were so simple in
the real world. Many project teams add unnecessary features without even thinking.
They often do it in many small and subtle ways. And they do it not to satisfy the
customer but to satisfy themselves. They map their perceptions of what the product
should be on top of what the customer has asked for without even realizing it. This
practice is quite common; there is even a vernacular expression for it. The expression
is gold plating the design.
Of course, gold plating doesnt literally mean that the designer requires plating with
precious yellow metals for items that dont need it. It refers to any practice that adds
features that are not needed. It also refers to levels of quality and reliability that are not
needed, and to poorly conceived extras that may be irrelevant in practice. It refers to
unnecessarily tight tolerances and to costly finishes beyond what the customer expects.
It could refer to requirements to use products from a certain high cost vendor, with no
options allowed, or to requirements to use favored old methods and processes that
have been replaced with better, cheaper processes. Or, it could refer to a product
capability that the contractor perceives to be nice, but the customer perceives as being
useless.
We will use the expression minimal balanced design to refer to a design that is
balanced in the sense described in chapter 5 and minimal in the sense that it is free of
gold plating. A minimal balanced design is what we must strive for in our proposal.
Any additional features we think the customer might like to have (other than those that are
essentially free) should be proposed and priced as options the customer is free to choose or to
reject.
In some teams the tendency to gold plate is so strong that a culture change is
necessary to overcome it. Some teams that attempt such a change go about it in a way
that could lead to failure. They begin by building a typical gold plated design. Then
they attack it by doing cost reduction studies to see where costs can be taken out. They
generally succeed in getting some of them out but eventually they may find that their
competition is still below them in cost.

Page 69 of 199
Please recall the following statement from an earlier chapter: Comparisons between
relative cost and relative value should be based on minimal efficient designs. What
exactly does that mean, and how do we arrive at such a design?
A minimal design is easy enough to define. It is a design that satisfies the customers
goals and little or nothing more. It is not burdened with features that were not
requested. It is not built to unnecessarily tight tolerances, which increase costs. It does
not have expensive surface finishes that are functionally unnecessary. It does not have
features not requested by the customer.
An efficient design, for our purposes, is one arranged such that the cost of
implementation is minimized, given that the required functionality is retained. This
means use of the lowest cost materials that will do the job, and fabrication and
assembly made as simple as possible to minimize the labor hours, and to avoid
unnecessary special, expensive labor skills, tooling, and processes.
It follows that a minimal efficient design combines both of these characteristics. It
further follows that such a design should be the one that wins a bidding competition,
based on price.
There are two main approaches to creating a minimal efficient design. One is typical of
how many (if not most) designs are done. The design team considers all of the
customers goals as a package, and tries to design to meet, and usually slightly exceed
all of them simultaneously. More often than not, this will result in a design that is heavy
and expensive. To get it light enough and cheap enough, the design team must do a
weight or complexity reduction program and a cost reduction program. When the team
has given this its best effort, chances are the design still will not be minimal and
efficient. It may meet
functional requirements, but a
Exhibit 10-1 Evolutionary versus typical design
competing design will often
Typical design
meet them at lower cost.
Functionality
adequate for
customer

The other approach we will

call evolutionary (see Exhibit
10-1 nearby). It begins with
rank ordering the customers
goals as was discussed in
chapter 5. Create a design
that focuses on meeting the
top goal as minimally and
Functionality
efficiently as possible, just as
Evolutionary design
Mother Nature might create a
simple new species that can
function in a simple
environment. Then, imagine that the new species you have created enters a new
environment that includes the next goal on the list. As in nature, it must adapt to this
Cost

Page 70 of 199
new environment. Think of the simplest adaptation that will permit barely adequate
functionality with respect to both goals. Incorporate that into the design.
Continue this process, working your way through the goals. Arrive eventually at a
design that meets all of the goals, some perhaps just barely. Simulate giving it ten
million years of evolution to make it more efficient by doing a design for
manufacturability study (more on that shortly). You should be there minimal and
efficient.
An excellent mental aid in working through the goals is to use a tool of value
engineering called functional analysis. As implemented in VE, a functional analysis
comprises expressing the function desired as an action verb followed by a noun, such
as measure temperature to define the functionality of a thermometer or a moist finger,
or contain liquid to define the functionality of a glass, a pipe, a bucket, or a tub. The
advantage of this approach is that when the functionality is thus reduced to its simplest
form, options tend to become visible, and one can choose the least expensive one.
Even if the next goal to be considered renders it impossible to use the cheapest one, it
might still be possible to use the second cheapest one, or alternately, to make a slight
change in the cheapest one that has little cost effect.
Sometimes several passes through this process will result in a choice of several low
cost designs, among which one can choose the best based on such subjective criteria
as appearance or comfort. It can sometimes be productive to shuffle the goals into a
new, random order, and repeat the process.
It frequently comes as an unpleasant surprise to teams who think they will win a
competition hands down that some competitor out there has come up with a way to
provide the same or better functionality at lower cost. If this is a possibility, even
having a balanced minimal design does not guarantee a win. It may turn out, for
example, that a competitor can build a product with the same functionality as yours but
15% cheaper. The competitors design is more efficient than yours in the sense that it is
more in tune with efficient manufacturing processes. This competitor has considered
design for manufacturability (DFM) and you have not.
Design for manufacturability is a process by which designs are crafted so that they can
be manufactured at minimum cost. Such designs minimize what must be done by hand
or with expensive materials. Snap into place replaces screw down with many fasteners.
Testing is automated. Parts counts are minimized. DFM is further discussed in the next
chapter.
Many expensive and risky projects today are concerned only with the development of
software. Design for manufacturability is not a consideration, because software is not
manufactured. The closest equivalent to DFM in the software world is probably
function point analysis.9 Function points are features of the software that meet specific
9

Function points are a unique and clever way of measuring the functionality of software. Interested readers should
contact the International Function Point Users Group (IFPUG).

Page 71 of 199
customer wants. They are strong drivers of both effort and schedule in software
development, and they are closely related to software architecture. Through function
point counting, you can show your customer how his wants relate to costs. And you can
conduct trade studies that lead to minimal designs.
A current trend in software development that must not be overlooked by astute pursuit
teams is the re-use of existing code and use of commercial off the shelf software
(COTS) to avoid software development costs. These options are not cost free, and in
some instances may be more expensive than developing code from scratch. But used
judiciously, they can cut development costs and schedule considerably.
Design of services products likewise may involve little or no manufacturing. The
equivalent of DFM in services design is process design. See Appendix A for more
information on this important subject.
Other ways a competitor might beat you on cost include use of low cost labor and
rigorous application of certain cost disciplines such as value engineering, life cycle
costing, design-to-cost, cost as independent variable, and target costing. These are all
discussed in the next chapter and in Appendix B.
The minimal approach must be pursued across all aspects of product functionality, not
just the one or two most important aspects. This means that product functionality must
first be fully defined. Functionality definition ultimately comes down to allocation of the
customers goals to the various elements of the product. Such allocations are
commonly referred to as the products architecture.
Generally, the same overall functionality can be achieved with more than one
architectural option. Ideally, in our proposal we will examine as many architectural
options as possible and will reduce them to minimal balanced designs before trading
them off using conventional trade study processes, or perhaps simply looking to see
which one has the lowest cost. Because such trade studies virtually always include cost
as a factor, trade study costs are usually estimated using parametric estimating
methods because of the speed with which the estimates can be done.
Chapter 10 Review Questions
1. Can you think of an example of design gold plating in any product you recently
worked on?
2. Is it possible to have a conflict between the concepts of balanced and minimal
designs? If such a conflict could occur, how would you try to resolve it?
3. On your most recent project, were customer goals explicitly considered in design
reviews?
4. Customer goals are the criteria by which project success must be measured.
Design requirements are constructs of the design team based on selected product
architecture. In your most recent experience, did the design team carefully
segregate customer goals from requirements derived from architecture choices?
(Some teams lump them together, thus potentially confusing what the customer

Page 72 of 199
wants with what they like, potentially resulting in designs that are neither minimal nor
balanced.)

Page 73 of 199

Chapter 11Apply cost containment discipline

Design teams not used to commitments to low cost design frequently have a lot of
trouble achieving them. A good corrective is to create and enforce an effective form of
cost containment discipline in the design effort.
Proof that this subject is of compelling interest is that since the early 1970s several well
publicized forms of cost discipline have appeared and have been enforced by various
government and corporate directives. Designers and others with design related
responsibilities have been subjected to many hours of training and cajoling aimed at
keeping costs under control.
Some readers will have heard of several or all of these disciplines, but for those who
may not have we recap them here. However, hearing of a method does not assure an
understanding of how to execute it, so we will explain each method sufficiently to give
readers at least the gist of it. Suggestions for implementation can be found in Appendix
B.
These are the cost reduction disciplines we will discuss in this chapter:

Design-to-cost.

Life-cycle cost.

Cost as independent variable.

Target cost.

Value engineering.

Design for manufacturability.

Low cost labor.

However hard you work to achieve cost reduction discipline, all your effort will be to no
avail if your organization suffers from conditions that prevent good estimating practices.
This chapter concludes with a discussion of this common malady, and what might be
done about it. See also Appendix D.
Design-to-cost
In the early 1970s the U.S. Department of Defense (DoD) found that it was unable to
fund all of the projects it thought it needed in order to do its job. It had been subjected
by Congress to declining budgets, and its costs of maintaining and operating the
resources it had were squeezing out new developments it felt it sorely needed.

Page 74 of 199
As a way of getting more for its development and production money, DoD produced a
requirement for design-to-cost. The gist of the idea was that challenging but
presumably doable goals would be set for product costs (usually measured by average
recurring unit production cost) and the design team would have to design the product to
be produced for that cost or less.
A few project teams took this very seriously and there were some early and notable
success stories. Other teams took it much less seriously, and business as usual
continued. When it was taken seriously, it was generally because the customer forced
the issue. When it was not taken seriously it was generally because the customer only
paid lip service to the idea, and the contractor naturally followed the customers lead as
being the path of least resistance.
The idea of designing to a predetermined cost has several implications that are worth
noting. The first is that it partially reverses the notion prevalent in many design shops
(especially aerospace and defense design shops) that product performance is king. In
principle, under the DTC discipline the designers are required to make cost calculations
at every step of the design process. But many designers are notoriously poor at such
calculations. They have no training or experience in it. Moreover, the estimates must
be done quickly and concurrently with the design. If they are not, the pressure to
release drawings for prototyping or for production will overwhelm the estimating effort.
This implies that highly qualified estimators must work closely with the designers on a
day to day basis. In addition, the estimators must have tools capable of providing
reasonably accurate estimates with minimum effort, even for subcontracted and
purchased items!
A second implication is that the preset cost target must somehow be estimated without
prior knowledge of the details of product design, and yet the goal must meet the
standard of being challenging but doable. This implies a rather prescient estimating
capability that did not exist in many customer or contractor shops. The challenge of
doing such should cost estimates in advance of knowledge of product architecture or
sometimes even knowledge of who the contractor will be is substantial. The temptation
is to set the goal based not on product knowledge but on knowledge of available
funding, often with strong political considerations. If the goal is based on past
experience, that experience may contain wastes and inefficiencies that should be
purged from the goal, but a difficult issue is how much to purge. If these costs that dont
belong are not purged, the goal tends to simply reflect past inefficient experience and
no real savings are realized.
A third implication is that cost uncertainty (risk) must be taken into account continuously.
Consider a simple device that comprises only three parts, A, B, and C. A qualified
estimator makes the following estimates of factory labor hours to fabricate the parts and
create the assembly, including inspection and test. (We ignore the material cost for the
sake of simplicity.)

Page 75 of 199

A
B
C
Assembly

5 hours
2 hours
9 hours
4 hours

Assume that the labor rate is $50 per hour in this factory.
Following typical estimating practice, the estimator adds these
hours to get a total of 20. Multiplying this by $50 yields $1,000
per assembly. Suppose that the DTC goal is $1,100. We are in
good shape, right?

Not necessarily. A deeper inquiry reveals that the estimator believes that the estimate
for A may be off by as much as 20%, for B by a like percentage, for C by as much as
30%, and assembly by as much as 50%. All of these uncertainties reflect the fact that
the item is merely a concept at the time of estimating.
A statistician working with the estimator calculates that there is a 30% chance that the
ultimate cost of the assembly will exceed the DTC goal. Is this acceptable? Someone
has to decide. If it is not, additional work is needed to cut costs, remove uncertainty, or
both. If no attention at all is paid to the accuracy of the estimates, a probable result is
not meeting the DTC goal.
Keep in mind that the estimates of product cost must be made concurrently with the
design activity, before actual production costs are known. Estimates always have error
until actual costs are known.
The implications mentioned above are probably at least part of the reason DTC had few
early successes. It imposed unaccustomed requirements that many teams had neither
the training nor the tools to fulfill. Many struggled with it the best they could and often
failed. As time went on, performance did improve in some design teams, but in others
business as usual prevailed with DTC often getting little more than lip service. Today,
the practice of DTC and related disciplines such as life-cycle cost, cost as independent
variable, and target cost is more routine as processes have matured and design teams
have become more accustomed to working with cost analysts. Still, however, cost
overruns are quite common.
Appendix B contains many suggested implementation ideas for the DTC discipline.
Much of what is said there applies also to most of the other disciplines discussed in this
chapter. There is considerable similarity in activities related to cost discipline.
The notions behind DTC did spread to the private sector in the 1970s, probably
because at that time the U.S. was lagging in international competition. Today, many
private sector companies use DTC principles. It may be no accident that as this is
written the U.S. is the most competitive nation on earth.
Life-cycle cost
While the DTC discipline is typically concerned with average unit production cost, the
life-cycle cost (LCCalso called Total Ownership Cost or TOC) discipline concerns the
total cost of a system from its earliest development through its ultimate retirement.

Page 76 of 199
Usually the discipline involves either 1) minimizing LCC or 2) creating the system such
that a target value of LCC is not exceeded.
LCC is generally an appropriate view when dealing with major systems that have long
lives and particularly those that require considerable tending after they have moved
from implementation to an operational state. LCC is especially appropriate for systems
that do not die readily, such as nuclear power plants, large buildings, ships, aircraft,
and certain kinds of factories that may leave significant toxic residue, such as paint
shops and metal plating facilities.
Customers often have LCC goals because they are concerned about their long term
liabilities for the system. This concern can exist even though the customer knows that
the system ownership may change one or more times in its lifetime, because the
residual LCC obligation at all times affects the value of the system. Customers who
own many long life assets they intend to keep must be concerned about LCC to assure
that the funds and other support resources will be there in the out years.
Here are some typical uses of LCC estimates:

Long range planning and budgeting.

Comparison of competing projects.

Timing of replacement of old or obsolete systems.

Selection among competing bidders.

Trading off initial investment in development and implementation against the often
much larger costs of operations and support and retirement of a system (this may be
the most important use of LCC estimates).

In one sense LCC estimating can be a guessing game. The reason is that certain
assumptions must be made that may turn out to be untrue. A major assumption among
these is the useful life of the system. It matters a lot to LCC whether we assume that a
ship will be in naval service 30 years or 50 years. This particular difficulty is often
overcome by using standard lifetime assumptions, e.g., all ships of a certain class
shall be assumed to remain in service 30 years. Everyone using the estimate is
informed of this and makes decisions accordingly. Another way of handling this
problem is to state an average annual cost once the system has been deployed.
Another key assumption is the rate of use of the system, also sometimes referred to as
the duty cycle. For example, if we assume that an aircraft will fly 1,500 hours a year,
the cost of operating and maintaining it will be considerably more than if we assume it
will be flown 750 hours a year.
Because they have so many long life systems, many LCC estimates are made for the
U.S. military. The military customer frequently specifies what assumptions should be

Page 77 of 199
made for lifetime and for duty cycle. They may also specify other things, such as pay
rates for military and civilian personnel that will be involved in operations and
maintenance. Also, to avoid unnecessarily complicating the estimating process, the
military generally requires that only peacetime operations be considered, and that
certain higher level labor costs (e.g., officers or civil servants above a certain rank) not
be factored in. Other estimating ground rules may also be specified.
Another major consumer of LCC estimates is the construction industry, especially that
part that works major projects such as office buildings, freeways, industrial plants, etc.
Many systems built by the construction industry have long lives, and significant out year
costs. For example, a large office building of conventional design in a city like Houston
requires substantial costs in operating and maintaining its air conditioning system.
What if a more environmentally green but initially more expensive construction
techniques were used, but savings in air conditioning over out years resulted? That
might be a tradeoff worth examining.
LCC is also of concern for many software systems. There can be significant LCC
tradeoffs in software, for example between costs of developing a system and
maintaining it over the years. Typically, the more effort put into development, the fewer
defects (bugs) and the less the out year maintenance costs.

Concept.

Business (or threat)

development.

Preliminary design.

Detail design.

Cost Profile

Exhibit 11-1 Typical LCC Effort Phasing

When do life-cycle costs
begin, and when do they
end? Chapter 9 offers the
following generic
identification of the
phases of a project:

Operations and
Support

Retirement

Implementation
Detail
Preliminary
Design
Design

Time

Implementation.

Operations and
support.

Retirement.

Page 78 of 199
Of these, all but the first two are generally included in an LCC estimate. The first two
are usually regarded as overhead costs related to the development of new business.
But bear in mind that various practitioners do not necessarily have the same view of the
world, and may use different ways of organizing and naming phases.
Exhibit 11-1 illustrates a typical time phasing of LCC effort. The time scale might be
anything from a few years to 50 years or more.
Cost as independent variable
In the 1980s the U.S. Department of Defense apparently decided that it needed a more
powerful tool for cost control than DTC, and Cost As Independent Variable (CAIV) was
born. Understanding of this new approach was probably not helped by its rather odd
name, but through aggressive marketing in the military and contractor cost communities
the idea spread and eventually became fairly routine. Practice is not perfectly uniform,
but here is the general idea.

Strong affordability goals (limits, actually) are set by the customer at the beginning of
the project.

The goal may be for total LCC , or sub-goals may be set for one or more
components of life-cycle cost. The contractor is expected to not only live within the
goals but also to make a best effort through extensive trade studies to try to do
better than the goals. The extra trade studies generally add to the cost of
development, perhaps as much as 20% or so, but the DoD apparently believes that
extensive trade studies (also called trade space exploration) save it money in the
long run, especially on major projects.

Aggressive cost risk management is expected during development.

If it develops that the goals are such that the cost target cannot be reached, a
relaxation of the goals may be considered. This option was generally not allowed
under the DTC discipline, and is not always allowed under the CAIV discipline.

CAIV generally is not applied to smaller projects. The extra trade studies generally do
not make economic sense for them.
Target cost
What if you developed a totally new product that fills a new role never filled by any
previous product? Your cost analysts say they cant find a similar product to compare it
to. A product like this that comes to mind is the Segway battery powered Human
Transport System. We have no idea how much the Segway people are charging for
their HTS, or what it costs to manufacture it. But if we were made responsible with
trying to figure out what the cost to develop and produce it should be, based on a
conceptual design, we would first conduct focus groups to find out what likely customers
would be willing to pay.

Page 79 of 199
And if we were rational members of such a focus group, how would we come up with a
reasonable number? We would likely proceed to figure how many labor hours we could
save by using the machine in our business. We would estimate how many hours per
day certain highly ambulatory employees are on their feet walking around, and would
take cognizance of the fact that the Segway can move them about three times faster
than they can walk.
How much time would they save? What does their time cost per hour, not just salary
but also fringe and allocated overhead? Would idle time be reduced anywhere in the
organization because people would not have to wait (or wait as long) for parts,
authorizations, etc.? Then we might want to consider tradeoffs. What are the
alternatives to the Segway? Maybe some of those ambulatory employees could be
replaced with e-mail, or a system of pneumatic conveyor messaging tubes. When we
got through with our analysis, we would have a pretty good idea what we would be
willing to pay for a Segway, and how many we would want to buy. It might be zero if we
thought we could get the same or better results by doing something different. Or, it
might be millions of dollars if we found that using the Segway could result in substantial
savings.
Different members of the focus groups would arrive at different conclusions. But if a
sufficient number of people were willing to pay enough money to make it worthwhile to
develop and produce the product, we might be willing to proceed.
Once we determine what people are willing to pay, we decide how much profit we need
to make to satisfy our investors. Subtracting the desired profit from what people are
willing to pay results in a target cost. If we can figure out how to build the product for
the target cost or less, we proceed. If we cant, we pass up this product opportunity.
The process we have just described is called target costing. It had its origins in Japan;
then it spread to Germany, and is now widely used in the U.S. For information on
implementing target costing, see Appendix B.
Value engineering
Value engineering (VE), also known as value management or value methodology, is a
technique for obtaining maximum value from a product or service. Value, for this
purpose, is defined as the ratio of function to cost. Ratio is in quotes because in
value engineering function is not a number. Rather, it is two word expression
comprising an active verb followed by a noun. When necessary and appropriate, an
adjective can be inserted between the verb and the noun, or sometimes an adverb after
the noun.
Suppose, for example, that you have been given the task of developing and providing
some means of stirring paint that is sold in cans. You might consider the function to be
well defined by the expression stir paint. More generally, you might define it as blend
liquid. However you define it, the goal is to define a design solution that minimizes the

Page 80 of 199
cost for satisfying this function. We will return to that goal shortly and have more to say
about it.
Value engineering began at General Electric Company in World War II as a response to
shortages of skilled labor, raw materials, and component parts. It was quickly
recognized that VE also reduces costs, and that is its main use today. Typically, a VE
effort involves a job plan with steps along these lines:

Gather information. What are the requirements for the object? What does it do?
What must it do? What could it do? What must it not do?

Generate alternatives. What are the alternatives?

Evaluation. How well do the alternatives meet the requirements? What do they
cost?

Choose. Select the best alternative and present it for decision.

Recall now the goal previously stated: Define a design solution that minimizes the cost
for satisfying this function. There has been some criticism of VE practitioners in that
they tend to focus exclusively on the lowest cost alternative without regard for how well
it satisfies the function. For that and other reasons, when taking a VE approach to a
problem, it is wise to be sure you have included all valid and necessary secondary
functions. For example, does stir paint tell you everything you need to know about
that function? Perhaps open can is a secondary requirement. Maybe fit hand
comfortably is another. If you dont include them all, you could wind up with a product
that makes nobody happy.
Design for manufacturability
Design for manufacturability (DFM) is an idea that became prominent in U.S. industry
and elsewhere in the late 1980s and early 1990s. It has saved hundreds of millions of
dollars in design and manufacturing costs.
The focus of DFM is to reduce product costs (including design costs) and speed up time
to market through design simplification. An enormous lore of DFM has accumulated,
and is available in numerous texts and courses. Here we can only provide a flavor of
what it is about. Here are some specific DFM techniques that are widely used.

Minimize parts count: A lower parts count results in fewer parts to design and
fabricate, and reduced assembly time. It also reduces inventory costs, and could
reduce requirements for factory capacity. Procurement lead times are often
shortened. The main tools for minimizing parts count are elimination of unnecessary
parts, combination of two or more parts into a single part, and finding simpler ways
to perform necessary functions.

Use standard parts. If off the shelf parts are available to perform a needed function,
it is almost always cheaper to use them than to design from scratch. Benefits

Page 81 of 199
include reduction of engineering design hours, reduction of the amount and diversity
of inventories, and reductions in manufacturing tooling. Higher quality could also
result. Manufacturing learning curve costs, which can be huge, are usually reduced
or even eliminated.

Use castings, forgings, and extrusions to eliminate machining for high volume parts.

Design items for ease of assembly. This includes providing features for automatic
alignment, reduction in the number of fasteners, and use of methods that eliminate
fasteners, such as fast setting adhesives. Consider human factors such as the
difficulty an operator has in reaching and tightening a nut. Avoid forcing operators to
look up into overhead work.
o Avoid using thin members that easily distort during assembly, slowing down
the assembly process.
o Avoid all processes that require special operations and tools.
o Avoid small or weak features that can be easily damaged in fabrication and
assembly, resulting in scrap and rework.
o Use through holes instead of blind holes wherever possible.
o Specify only the tolerances you really need. Fine tolerances are a major cost
driver in fabrication. (See Appendix C for a discussion of this important area.)
o Avoid specification of small internal radii. The larger the radius the easier it is
to make.
o Do not specify parts that can become entangled, wedged, or disoriented. For
example, it should never be possible to mate two electrical connectors that do
not belong together.
o If assembly requires or tends to result in parts lying on the factory floor (such
as electrical cables or connectors), damage is likely when workers step on
them. This can result in scrap and rework, not to mention injury.
o Use parts that are large enough to be easily handled. Tiny parts are easily
lost or damaged.
o Consider use of automation when it is cost effective.

Low cost labor (outsourcing)

An idea that has changed the distribution of manufacturing (and to a lesser extent
design) activity worldwide is the use of low cost labor. In the past four decades much
manufacturing activity has moved from countries with higher labor costs, such as the
U.S., Germany, and Japan, to countries with lower labor costs, such as Mexico, Brazil,
Taiwan, China, Malaysia, the Philippines, Costa Rica, and South Korea. As this is

Page 82 of 199
written, manufacturing direct labor costs in China are about 2% of costs experienced in
the U.S., and costs in the Philippines are about 9%. Such low costs create a strong
incentive to site production in these countries in order to be more competitive.
But before you take such a step, you need to consider factors other than just direct
labor cost. In a typical manufacturing operation you also have freight costs, material
costs, indirect labor costs, land costs, facility depreciation, equipment depreciation,
utility costs, lease costs, legal costs, licensing and environmental costs, and taxes, as a
minimum. Anyone considering establishing an operation in a foreign country needs to
evaluate all of these factors, as well as issues of political stability and quality of life.
There is also the question of training and productivity. Can the foreign labor force
produce as effectively as its U.S. equivalent? How much training will they need?
Very often a tradeoff between manufacturing locally and manufacturing overseas will
work out in favor of the overseas option. When it does, and especially when you
suspect or know of competitors using overseas labor, you should strongly consider it, if
your customer permits it.
Not all lower cost options involve going overseas. For example, your author once
worked on a project where a high priced operation located in California structured its bid
to take advantage of the fact that it had a division in Colorado where productivity was
excellent but labor costs were about ten percent lower. Not all of the work could be
done in Colorado because of physical limitations of the plant there, but the bid was
reduced considerably by moving some of the work there.
Problems that prevent good estimating practices
Some organizations habitually underestimate their costs yet are seldom called to
account for it. When this pattern is once established, it is difficult to break out of it.
In such an organization, costs are estimated not to determine what the true cost will be,
to reasonable accuracy, but to determine a number that is politically acceptable. Such a
number is often less than half of what the true cost turns out to be. Once the number is
accepted, then overrun, the project is usually allowed to continue because it is deemed
too important to fail, or perhaps it is too embarrassing to let it fail. Somehow, the money
is found to let it continue.
In such an organization, cost discipline is essentially meaningless. It cannot be
meaningfully exercised. The only remedy is a harsh awakening that may someday
arrive.
Other organizations strive to achieve realism in their cost estimates, but are hampered
by lack of historical precedent for what they are trying to do. Realistic, accurate cost
estimates are always based on what something else once cost. One remedy for this
situation is small pilot projects to explore options and gather information before
proceeding with a full scale development. The cost of the pilot project is treated as a no
fault investment. This is the approach which has been wisely taken in attempts to

Page 83 of 199
harness nuclear fusion energy for commercial purposes. There has been a succession
of pilot projects in support of this goal, all of which have failed in achieving the main
goal, but all of which have contributed to our general state of knowledge.
A solution that can sometimes be made to work in the event of no direct precedents is
to look for indirect precedents. Sometimes a group of indirect precedents can be
cobbled together and used to make an estimate based on rough similarity. This
sometimes works very well for manufactured products if all required manufacturing
processes exist and are proven.
Finally, there is the issue of estimating mistakes. These can creep in to the best
managed estimates. We believe that the best safeguard is a good estimating checklist.
If you dont have one, we recommend the one in Appendix D.
Chapter 11 Review Questions
1. Have you worked on a project subject to rigorous cost discipline? Were the targets
met? What problems were experienced and how were they resolved?
2. For many systems, operations and support costs over the system lifetime dwarf
design and implementation costs. But this is not true in other systems. Can you
think of the most likely reason for this? Can you think of such a system?
3. Some manufacturing companies in Asia have established manufacturing operations
in the United States. This partially reverses the trend of moving them from the U.S.
to Asia. What reasons do you think these companies have for doing this?

Page 84 of 199

V Bulletproof Your Proposal

Chapter 12Analyze your competitors
Rarely if ever will you know exactly what your competitors are doing in a given pursuit.
Like you, they will try to hold closely their vital competitive information, restricting access
to only trusted people usually on a need to know basis. What you are able to learn
about them is usually learned inferentially from past behavior and sources of general
information such as SEC filings, corporate quarterly reports, industry newsletters,
newspaper articles, former employees, etc. Sometimes you may be able to hire or
interview a former employee and glean some inside information, but often it is dated or
incomplete information and may have been overtaken by events.
Sometimes competitor presentations at trade shows and professional societies will give
clues. Other times competitor press releases or data stolen by reporters with inside
contacts will contain information that you wouldnt have otherwise known. The rumor
mill also may contain useful information, but it could just as easily contain
misinformation.
Some project teams spend considerable intellectual energy trying to figure out what a
particular competitor will bid. This is made doubly difficult by the fact that the competitor
may not decide on a bid amount until the last minute. And that bid amount could be
strongly influenced by the strength of the competitors desire to win and aversion to risk
at a certain point in time, both of which could be subject to countless unknown
variables.
It is precisely because of the dense fog that typically surrounds the competitive bidding
situation that we recommend use of the Best Bid model,10 a competitive analysis
process that demands relatively little specific information about individual competitors.
The information that is wanted is fairly general and can often be pretty well guessed or
subjectively assigned with reasonable confidence based on the occasional fleeting
glimpses we are able to get into the competitors inner sanctum.
A key piece of information required by the Best Bid model is the count of competitors, N.
N represents the number of effective competitors (other than us.) Assuming that we
judge ourselves to be an effective competitor, the expected total number of effective
bidders is N+1. N does not include bidders who are judged not to be effective, that is,
who are not qualified or who may intend to bid, but have little or no chance of winning
the bidding competition.
An effective bidder is one whose mastery of the technology is credible, whose
resources are adequate to perform the work, and who is likely to offer a competitive bid,
10

The model is described in more detail in Chapter 13. It is available free from the author in the form of
an Excel spreadsheet.

Page 85 of 199
as that concept is later defined. A bidder whose technical offering is likely to be
unsatisfactory to the customer probably should be considered ineffective. A bidder who
is in political disfavor or who has other problems with the customer might be considered
ineffective. That is a judgment call, because sometimes political disfavor is a temporary
condition that can be overcome in various ways.
While N may be a bit difficult to nail down in some smaller projects that have many
bidders, its usually pretty easy to determine in major projects. Typically only a few
companies can handle a given major project, and they tend to be highly visible.
Sources often available are bidders lists, lists of attendees at bidders conferences,
news articles, and the grapevine. Sometimes CEOs can just ask other CEOs and get
a straight answer.
Why is N important? Clearly if the field is crowded, each bidder has a lower win
probability than in a field that is not crowded. In a field of N+1 equal competitors each
competitor presumably has a win probability of 1 / (N+1). In this book we define a
competitive bid as one having a win probability of 1 / (N+1) or better. If our win
probability is consistently uncompetitive in this sense, its likely we will eventually have
to subsidize our contracting business or get out of it. To get our share of the work our
win probability should average at least 1 / (N+1) across all bids we make.
The larger the number of competitors, the better our proposal will have to be in order to
win. Having a better proposal means, in general terms, having a lower price and a
better offering technologically speaking. For all of these reasons, N is a very important
number. Please take care in determining it.
An important issue dealt with by the Best Bid model is the competitive pressure. While
N is certainly a form of competitive pressure, there is another form that is based in part
on the mood of the bidders. If a single one of the effective bidders is hungry and has a
must win attitude, including us, competitive pressure might be said to be moderate. If
several bidders are hungry and need the win, we could say that it is high. If bidders in
general have about all of the business they want, of the kind they want, and can do
without the instant project, it can be said to be low.
Typically, the effect of increasing competitive pressure is to cluster the assumed bids
more tightly near the bottom of the competitive bid range. The overall effect is to force
us to cut our costs or improve our competitive posture relative to our competitors.
Competitive posture has nothing to do with bid price. It is a consideration of all of the
other factors that are likely to influence the customer to award us the project, or award it
to someone else.
Chapter 12 Review Questions
1. Did you know the number of competitors N in your most recent pursuit? If yes, how
did you come to know it? If no, why not?

Page 86 of 199
2. How would you evaluate the overall competitive pressure in your most recent
pursuit? Consider both the number of competitors and their aggressiveness.

Page 87 of 199

Chapter 13Work the toughest issue: how much to bid?

The simple-minded, obvious approach to bidding is to read your customers request for
proposal, come up with a project design, estimate what the package will cost, add profit
and perhaps a contingency, and submit that amount as your bid, without giving the
matter another thought. That might work often enough in road construction or
provisioning where the technology is well settled, and the work content is well defined
and understood, but in any high tech or otherwise unusual project, it often is recipe for
failure, especially if the market is shrinking or competition is intense.
Our goal in this book is to move well beyond this obvious bidding approach. We will try
to gain some appreciation of the dynamics of the bidding situation, and also some
appreciation of what bid amount is appropriate to ensure you getting your share of the
work. Even when other factors are involved, bid amount is vitally important. Much more
often than not, the low bid wins. Such is the state of the world. People like bargains.
So your goal always will be to bid as low as you can and still make a reasonable profit
when you win. Another even more important goal will be to win often enough to be able
to remain a viable, competitive organization.
The winning formula we advocate in this book is simple. We have spilled a lot of ink
developing the nuances of it, and will spill even more in later chapters, but here is the
basic process:

Get an early start and maintain momentum (Chapter 1).

Be clear about who the customer is and who we are (Chapters 2-3).

Find out what the customer truly wants (Chapters 4-7).

Find out the competitive range of bid amounts (Chapter 8).

Give the customer confidence that we are capable and reliable (Chapter 9).

Find a baseline project design that minimally meets the customers needs and that
the customer can afford (Chapters 10-11).

Look at the competitive situationhow many effective competitors are out there,
which ones are hungry, what they are able to offer in terms of project design
(Chapter 12).

Work the issue of how much to bid (this chapter, with support from the next chapter).

Get your proposal right and keeping the game going (Chapters 15-18).

Page 88 of 199
Our main concern in this chapter is with a concept we call the competitive bid. Shortly
we will provide a definition for it, and discuss underlying principles of a model for
estimating it. Following those principles, you might want to build for yourself a computer
model to help you work through a best bid analysis in a systematic and repeatable
manner. Or, you might wish to contact the authors to obtain such a model, already built
in MS Excel.
A competitive bid, as that term is used in this book, is not a bid that guarantees a win, or
even that promises a high probability of a win. There is no such thing, unless you are in
a probably illegal collusion with your customer. A competitive bid is based on a process
designed to get you your share of the work, provided you are competent in the realm in
which you are bidding. This book will not make you competent in any field if you are
not, but we do provide many suggestions that will help you be more competent (see
Appendix A).
We begin with a question that is not merely rhetorical. It has a widely accepted
mathematical answer: If there are N+1 bidders including you, and all bidders are equal
(an important qualifier!), what is the win probability of each? Based on a pretty much
universally accepted principle called the Principle of Insufficient Reason, it would be
1/(N+1). This principle originated with the famed mathematicians Jacob Bernoulli
(1654-1705) and Pierre Simon Laplace (1749-1827). Basically, the principle says that if
there is insufficient reason to believe otherwise, and if N+1 outcomes of an event are
possible, each outcome has probability 1/(N+1). It is due to this principle that we say
that the probability of heads on a fair coin toss is , and the probability of a five on the
toss of a fair single die is 1/6. Recall that a coin has two faces and a die has six sides.
Accordingly, we can create the following table:
Exhibit 13-1 Competitive Win Probability
# Competitors incl. you Competitive win probability
1
1 (certain win)
2
0.5
3
0.33333
4
0.25
5
0.2
Etc.
Etc.

If in your bidding your win

probability is consistently less
than the competitive win
probability, then you are a bidder
of below average competence
and you are not winning your
share of the work. As a
consequence, you will eventually
have to either subsidize your

losses in the bidding wars, or go bankrupt.

So, a logical starting point in determining your bid amount would be to determine your
competitive win probability, all things being equal. That begins with determining the
value of N, the number of competitive bidders that will enter the competition, other than
you. You can safely exclude bidders who have little or no chance of winning. Such
exclusions, of course, are a judgment call, the first of several you will have to make to
decide on your bid amount. (Sorry, there are few certainties in this process. Some
subjective judgments are inevitable.)

Page 89 of 199

Of course, you and your competitors cant bid any amount you want and expect to win.
In the real world, there is something called the competitive range. If any competitor
bids outside this range, it is reasonable to assume that the customer will throw out that
bid. Therefore we posit that all bidders contained in your assigned value of N are aware
of the competitive range and know that they must bid within it to have any chance at all
of winning.
If the potentially successful bidders are all aware of the competitive range, it follows that
the customer must also be aware of it. But, it is reasonable to ask, will all of the
potentially successful bidders and the customer all have in mind exactly the same
range? The answer is probably not, unless the customer publishes it, which has
probably never happened and probably never will. For one thing, the customer may
not, on any given day, know exactly where the bottom and the top of the range are.
However, it is fair to say that an astute customer and an astute bidder will know the
bottom and top values to a reasonable approximation.11
There is always some uncertainty associated with determining the boundaries of the
competitive range, but nevertheless, a best attempt at nailing down these values is a
very worthwhile exercise for every competitor. The reason why should become clear
shortly.
The parameter N+1 exerts a pressure on all astute competitors to either bid lower, come
up with a technology offering more pleasing to the customer, or both, if they hope to
win. But that is not the only factor that has such an effect. It is convenient to give that
other factor the name competitive pressure. You have more competitive pressure
when, for example, at least one serious bidder is hungry, as when that bidders
management says this is a must win for uspull out all of the stops. You also may
have more competitive pressure when one serious bidder has a known edge, that is,
some perceived advantage which might cause the customer to look with favor on that
competitors bid even if it is a bit higher than some of the others. The edge could be a
number of things, such as excellence of design, a track record of good project results,
or even a political consideration, like being located in Alabama (it happens!).
In addition to N+1 and competitive pressure, another factor which tends to drive bid
amount is cost risk. This is the ever present possibility that your cost estimate missed
something in a fixed price or risk sharing bid, or that you might overrun your estimate in
a cost plus bid and alienate your customer. Depending on circumstances, the effect of
such alienation might range from essentially no effect to contract cancellation and / or a
strong bias against you in future bids. Clearly, the lower you bid, the more your cost
risk.
Given what has been said so far in this chapter, we submit that the following should be
done in every bidding situation, as a minimum:
11

Having less than astute competitors generally will work in your favor. However, a less that astute customer is a
loose cannon and a danger to all serious bidders. See chapter 7.

Page 90 of 199

Determine N and calculate 1/(N+1).

Strive to arrive at a some combination of bid amount and product offering that results
in a win probability of at least 1/(N+1).

If you have concerns about the usefulness of doing this, you might want to conduct a
brief analysis of your own bidding history similar to the following example.
In this math exercise, five project bids are
shown. The column headed N shows the
number of competitors faced in each case.
The column headed 1/(N+1) shows what we
have called the competitive win probability in
each case. The column headed Win M$
shows the amount of the win in millions of
dollars. The final column headed EV M$
shows the expected value of the win in each
case. It is the product of the preceding two columns. The final winnings (overall) were
M$ 17.3, while a barely competitive bidder would have won M$ 6.531.
Exhibit 13-2 Expected Winnings
Bid # N 1/(N+1) Win M$
EV M$
1
1
0.5
1.3
0.650
2
2
0.333
4.1
1.366
3
1
0.5
6.8
3.400
4
3
0.25
1.9
0.475
5
4
0.2
3.2
0.640
Totals
17.3
6.531

If you do this analysis for yourself and your actual winnings were less than the sum of
the EV M$ column, you have work to do! What kind of work? You could have one (or
more) of several kinds of problems. Lets look at a few possibilities.

Risk aversion. You could be so concerned about the possibility of losing money
that you are afraid to lower your bid below what you believe to be a comfortable
value. This may stem from a previous bad project experience. Suggestion: Review
your risk management process. Look ahead to chapter 14.

Waste. You may have a lot of wasteful processes. See Appendix A. If you have
been considering beginning a Six Sigma initiative, this would be a good problem to
start your belts on.

Inexperience. Are you trying to punch above your weight in the technologies you
are bidding? If you are, you will probably keep getting clobbered. Consider either
staying longer in the minor leagues, or hiring the kind of people you need to compete
with the big boys.

Poor cost analysis. Does your cost team understand the kinds of work you are
bidding? Are they competent? See Appendix D.

Assuming that you are free from any of the above problems, it may be that you are just
not keeping your pencil sharp enough when you are trying to determine your bid. Lets
keep firmly in mind that the goal is to create a bid that gives you at least a 1/(N+1) win
probability. Is this easy? Not usually. It can be very hard. The larger the value of N,

Page 91 of 199
the harder it gets. In fact, for any value of N greater than 5, its all but impossible. In
fact, for N > 5, a bidding situation is more like a lottery than a competition. The outcome
is likely to be, or appear to be, essentially random.
For competitions where N 5 there is some hope of profiting from a comparative
analysis, meaning an analysis in which you compare your own state of readiness to the
readiness of you competitors. By your readiness we mean, to what extent have you
created a worthy project management structure and process; to what extent do you
understand what your customer needs; to what extent can you satisfy your customer
that you are meeting those needs; to what extent is your customer happy with you; to
what extent is your design solution balanced and efficient, etc. In other words, to what
extent are you doing the things recommended in chapters 1 through 11 of this book?
The Best Bid model, mentioned earlier in this book, contains a questionnaire that asks
you about such matters. It asks you the very same questions about each competitor.
Other questions pertain to the issue of competitive pressure. One possible answer to
the questions about competitors is Dont know. If you give that answer, the model
assumes that the competitor is just as ready as you are. For competitors that are more
ready, and for high competitive pressure, the model assumes that bids will be clustered
more tightly at the lower end of the competitive range. This makes it harder for you to
win.
The Best Bid model puts a high premium on knowing your competitors and the state of
the market. The better your state of knowledge in these subjects, the lower will be its
recommended bid amount, and the more likely it will be that you will win, assuming that
you can see your way clear to bid that low!
Creative and mathematically adept types among our readers might well profit from
building a model along the lines discussed, and using it to predict a best bid. Others
might want to acquire the Best Bid model your author has already created. Contact the
author if you want to do that.
A caution: The Best Bid model we have built, and any similar model built by a reader will
by definition be an economic model. As most economists will (or should) admit,
economic models have a long history of being wrong. Therefore you should not wholly
trust the Best Bid model, or your substitute for it, until you have ignored its
recommended bid amounts at least five times, and made your own bid amount
assignments instead. After you have done that, you can check the results. An excellent
way to check the model results is the simple expected value calculation demonstrated
earlier in this chapter. If using the model results would have resulted in too many
losses, the Best Model has a calibration adjustment to correct that. If you decide to
build a model, yours should have such a calibration adjustment feature, too.
Your author has worked with proposal managers who would never put their trust in any
model for determining bid amount. Mostly, these are people who have great confidence
in their ability to read a complex situation and come up with a winning solution. To

Page 92 of 199
such people, we offer our congratulations. But we do make one recommendation. After
each bid amount decision, take the time to write a memo to the file explaining exactly
how you came up with the bid amount. After the award has been made, take that
memo out and read it. How accurate were your predictions?
Chapter 13 Review Questions
1. Explain in your own words the concept of a competitive bid, as that concept is
developed in this book.
2. If you are to stay in the contracting business, without subsidy, why must your bids be
at least competitive, on average?
3. On your last major pursuit, did you know who all of your effective competitors were?
How did you find out?
4. For several consecutive days, a researcher gave 20 mice in a cage only an ounce of
cheese. The mice frantically scrambled for the cheese and most of the mice went
hungry. After observing their behavior, the researcher began to give them all the
cheese they wanted. The mice ate in a casual, leisurely way and no mouse went
hungry. Is this situation a good analogy with the notion of varying levels of
competitive pressure in the Best Bid model?
5. Is the Rule of Insufficient Reason reasonable? Explain your answer. (There has
been some controversy about this rule.)
6. Customers of a Cadillac dealer are probably more willing than customers of a
Chevrolet dealer to pay for unnecessary frills and loving care. Are your customers
more like Cadillac customers or Chevrolet customers? If they are more like Cadillac
customers, we recommend you give this book to a friend who needs it and instead
read Customers for Life by Carl Sewell, et al. But even if your customers are more
like Chevrolet customers, Sewells book is still an excellent source for ideas on
pleasing customers.

Page 93 of 199

Chapter 14Analyze and abate project risks

In the pursuit cycle, the most urgent task of project risk analysis is to assist in
determining the best bid amount. While in pursuit, you typically consider lower and
lower bid amounts in the interests of achieving a competitive or better than competitive
bid (see chapter 13). As the proposed bid amount gets lower, the probability of
exceeding the planned cost and schedule will tend to increase. Moreover, the likely
amount of the overrun also typically increases. At some point, the pursuit team will not
want to further lower its bid amount due to fear of losing money and perhaps reputation
and future credibility as well.
This situation pushes the pursuit team to reach a good understanding of just how bad
the risks are for a given proposed bid. A prime question is how can the team know if
the risks are excessive unless it somehow measures them? Gut feel is rarely a reliable
guide!
Consider the insurance industry. Typically, an insurance company will not insure
property against, say, fire damage, unless the property is in an area where there is
considerable experience with the frequency and severity of fire. With a large
experiential database, the insurance industry is confident that it can set rates for fire
insurance that will allow it to pay all valid claims and still achieve a decent profit.
There is little about the kind of advanced projects dealt with in this book that an
insurance company would even consider insuring, aside from its traditional areas of
business. It would probably write key person insurance, fire insurance coverage for
the buildings, and damage and liability insurance for the company cars and other
properties. But it most likely would not touch writing insurance for the projects
maintaining schedule and staying in budget. With respect to those aspects of a project,
the experience base simply is not there for doing the kind of actuarial analysis that
insurance providers feel they must do in order to be assuredly profitable.
For similar reasons, contractors also might not want to take on these risks either. If the
customer is willing to pay all costs, regardless of amount, contractors usually will be
enticed to bid. That is why government agencies (especially for development contracts
in the U.S.) and sometimes private companies sponsoring very risky but also crucial
projects frequently offer a cost plus fixed fee (CPFF) contractual arrangement. In this
arrangement the customer agrees to reimburse all costs, and the contractor pockets a
usually smallish percentage fee that is tied not to the eventual cost outcome but to the
bid amount.
When CPFF is offered, the contractor may be tempted to bid below what his costs will
really be in order to improve his win probability. The contractor calculates that if the
costs go higher, the customer simply will have to pay them. Too bad for the customer!

Page 94 of 199
In past years, this has encouraged a considerable amount of under bidding, with bad
results for customers. But in recent years, customers have gotten smarter. While they
recognize that the risks may be too big for any contractor to bear, and CPFF is therefore
appropriate, customers often cap their risks by telling the contractor the maximum funds
available and refusing to go beyond that amount. Staying under the cap becomes the
duty of the contractor, and if the contractor fails then he or she could wind up with a
cancelled contract and an unhappy customer. This can reflect adversely on being
awarded future contracts.
Also, customers have become more sophisticated at estimating true costs, thus
narrowing the competitive range. Contractors must be similarly sophisticated so they
can bid within it. As mentioned in chapter 8, analogy and parametric estimating have
improved the ability of both contractors and customers to make realistic estimates in
sophisticated projects.
Another way customers control their risks in CPFF situations is to reward the contractor
for controlling costs. In this mode of contracting, contractors are awarded fees for good
cost performance, and often for other good results as well, such as outstanding
technical results, or for maintaining schedules.
If the customer and the contractor both feel confident that the contractor can succeed
when given a fixed amount of money, the usual result is a fixed price contract. In this
type of contract, if the contractor exceeds the planned costs, the contractor must absorb
the loss. Often the contractor will also be penalized monetarily for not making the
planned schedule.
Summarizing all this, it is important for bidders to understand their potential for loss at a
given bid amount whether they are bidding in a cost plus or a fixed price environment,
or somewhere in between.12 The potential for loss is more obvious in the fixed price
situation, but losses can be real and damaging if the CPFF situation as well. For a
given bid amount, the contractor needs to be able to estimate his confidence of
adequate performance within that amount. The contractor also needs to know the
potential losses that can arise. Having that information, the contractor must then decide
whether or not the risks are acceptable.
Projects risks, like project cost estimates, can be approached by analogy or
parametrically, or also using a bottom-up approach. In an analogy approach, what one
typically does is to seek out completed projects of a similar nature and study the
difference between what was bid and what the final outcome was. This can be tricky if
there are numerous customer authorized changes in the course of the contract that
allowed the costs to go up intentionally. The usual outcome of analyses of this sort is a
range of percentage differences. For example, it might be found that cost overruns over
the projects reviewed range from -10% to +40%.

12

In between there are several contracting options that involve sharing in cost overruns.

Page 95 of 199
If you are using a parametric model to estimate project costs, it often is the case that the
model will have features that allow you to estimate a risk range at the same time.
Again, you will wind up with a range of possible percentage overruns or under runs. By
the way, if you use a parametric model, be sure you understand what risks it takes into
account. Some parametric risk models do not account at all for some categories of risk.
Also, depending on its architecture, it may or may not be of much help in management
of risks.
The bottom up approach is much more labor intensive, but it also leads to a much better
understanding of possible risk impacts. And it provides a basis for considering specific
risk abatement approaches.
We recommend using the analogy or parametric approaches early in the pursuit cycle in
the interests of speed of estimating. But before the proposal goes out the door, perhaps
concurrently with doing a final bottom-up cost estimate, risk should be analyzed using
the bottom-up approach, so that a credible risk abatement plan can be written.
(Customers tend to love risk abatement plans when they have the ring of credibility.
They dont care much for them when they are full of clichs and generalities.)
Later in this chapter we will explore a particular approach to developing a bottom-up risk
analysis and show how it can be applied to determining the suitability of a particular bid
amount. But first we will explore doing that with a percentage range provided to us by
either analogy or parametric methods.
Suitability of a given bid based on a percentage risk range.
The analysis presented here assumes a fixed price contract. The potential for loss is
more clearly defined in fixed price than in CPFF contracts. But real losses are also
possible in CPFF contracts, depending on circumstances.
Suppose you have used the Best Bid model (see chapter 13) to determine that to be
competitive you need to bid $91.2 million on a particular project. You have three
competitors (N = 3) and according to the model, a bid of $91.2 million will provide a
competitive win probability of 0.25 (25%) given the competitive pressure in the bidding
environment.
You have estimated the costs (without contingency or profit) of your current baseline
project (product plus programmatic) design at $75 million. You have determined the
competitive bidding range to be $85 t0 $115 million.
The $75 million cost estimate is just that, an estimate. Based on analogies with
completed similar projects, you determine that the actual cost could be anywhere
between $70 million and $100 million. This corresponds to an estimating error ranging
from -6.7% to +33.3%. (Estimating error ranges of this magnitude should never be
realized in routine contracting, such as most construction, but surprisingly they often
are! In high tech or other non-routine contracting they are not at all uncommon.)

Page 96 of 199
The next stage of your analysis assumes that all outcomes between $70 and $100
million are equally likely. This may not be true, but if you lack evidence to the contrary
the Principle of Insufficient Reason (explained in chapter 13) makes it the most
reasonable assumption.13 The situation is shown in Exhibit 14-1.
In the exhibit you see your current cost estimate of $75 million, the competitive range of
$85-100 million, and the competitive bid of $91.5 million, yielding a win probability of
25%. Also in the exhibit is the range of cost uncertainty, $70-100 million, and a plot of
win probability versus bid amount developed from the Best Bid model.

Win Probability %

Exhibit 14-1Hypothetical Bidding Risk Analysis

100

Competitive bid $91.2M

with 3 competitors
win probability 25%

75
50
25

0
Cost Risk Range

100%
75%
Probability that cost will
50% not exceed given amount
25%
Competitive Bidding Range

70

75

80

85

90
95
Bid $ Millions

100

105

110

115

Your current expected cost

estimate (contingency & profit
not included)

The diagonal line rising across the range of cost uncertainty represents the probability
that the cost will not exceed the amount obtained by dropping a vertical line down to the
bid axis. (Technically, it is a cumulative distribution function.) For example, the
probability that the cost will not exceed $78M is 25%; the probability that the cost will
not exceed $85M is 50%, and the probability that the cost will not exceed $92M is 75%.
(Depending on how it is derived, this line will not always be straight. An S-shaped line
is likely if a distribution other than uniform is used.)
If you bid $91.2M you are competitive, but what is your picture with respect to risk? At a
bid of $91.2M, the plot says that the probability of the cost not exceeding that amount is
about 74%. Looking at it from the opposite point of view, it says you have about a 26%
chance of losing some amount of money because costs exceed $91.2M.

13

For the statistically sophisticated: Other evidence could lead you to assign a normal, lognormal, or
other distribution.

Page 97 of 199
Suppose that your company is averse to losing any money on fixed price contracts, and
will accept no more than a 10% probability of this happening. You would go to the 90%
point on the diagonal line and find that you would have to bid on the order of $97M
(reading the curve approximately). Unfortunately, this would reduce your predicted win
probability to almost zero. You would have three options:

Bid $97M and hope the other bidders get it wrong.

Try to cut your costs below the nominal estimate of $75M so you can bid lower.

Withdraw from the bidding.

Lets look at another hypothetical situation. Suppose your company hires a new general
manager a month before the bids are to be submitted and she is less risk averse than
the old one. In her view, a 20% chance of overrun loss is acceptable on this project
because the project will give you access to new technology that you would not
otherwise have. The future benefits of this technology she perceives to be huge.
The exhibit shows that a 20% chance of loss corresponds to a bid of about $94M, and a
win probability of around 10%. On being informed of this, the new general manager
decides that she is willing to accept even larger potential losses to gain the new
technology. She wants a 50% win probability. With the current cost and risk structure,
this corresponds to a bid of about $88M. But she also wisely orders that more studies
be done to try to further reduce both costs and cost uncertainty. In addition, as a
precaution, she orders that the reasonableness of the low cost approach finally adopted
must be carefully explained to the customer against the possibility that the customer
could perceive it as an attempt to buy in.
The above analyses are perhaps a bit overly simplified from what a real analysis would
be like, but are indicative of the general approach.
A point to remember: Costs and cost risk are real and must be considered in bidding,
but profits and contingency amounts to be included in bids are optional! In truth, the
amount of profit realized from a project depends not on how much profit we include in
the bid, but on how well we control project costs and risks. Moreover, sometimes we
are willing to forego immediate profits for the sake of long term objectives, among them
survival and improved competitive position in the future.
Risk drivers and bottom-up risk analysis
Simple assumptions suffice for bid analysis early in the pursuit cycle. But as the time
nears to present the proposal, a more detailed bottom-up risk analysis should be
performed for several reasons. Here are three:

Presumed risk ranges based on histories of other projects are not necessarily
specific to the instant project; the instant project could have risks that are lower or
higher.

Page 98 of 199

A bottom-up analysis is needed for writing an intelligent risk management plan.

Even if your customer and your internal policy do not require a risk management
plan, the project team should have one for their own use.

An important consideration is distribution of risk among project stakeholders. A

bottom-up analysis greatly aids this process.

Many systems have been advocated for doing project risk analysis. The scope of this
book does not allow for inclusion of descriptions of them. Here we will limit the
discussion to one approach that will result in a probability distribution that can be used
in an analysis similar to that portrayed in Exhibit 14-1. The approach shown is limited to
cost risk because that is most germane to the bidding problem. Other types of risk that
are often considered in risk analysis are schedule risk and risks of failure to accomplish
technical objectives.
The method requires that a work breakdown structure (WBS) be defined for the project
(this was discussed in Chapter 9, but see also Appendix D). Only the ultimate children
(leaves or tips) of the WBS tree are considered.14 They should be formed into a list
with their cost estimates stated and summed. The cost estimates should be the honest
most probable costs, as judged by the team. They should be neither fat nor lean.
Obvious contingencies should not be included.
The next step is to identify risk drivers. For purposes of this book, the following
definition applies:
A risk driver is a root cause force or circumstance that may act to change the cost of
one or more tasks in the project.
That it be a root cause rather than merely a symptom or a proximate cause is
important.15 Using symptoms or proximate causes as proxies for risk drivers causes
logical and statistical entanglements that can invalidate the analysis. This is because a
symptom may result from several risk drivers acting concurrently. Also, a risk driver
may produce more than one symptom. Risk drivers are typically identified using
bottom-up processes such as brainstorming and various checklists, followed by cause
and effect analysis.

14

Using the WBS as a framework for a project risk analysis is a very common practice. However, it does have a
serious fault. The typical WBS covers only so-called direct charge work. It may not include overhead functions or
costs such as executive management, depreciation charges, departments such as contracts, human resources,
purchasing, plant security, and others that are classified arbitrarily as overhead functions. Since these functions are
not included in the WBS, their costs must be captured by some other means, the typical means being an unexplained
burden costs against direct labor. The problem with this arrangement from a risk analysis point of view is that risk
that arises from overhead activities tends to be ignored in project risk analysis, yet these activities are a common
source of major project problems. A practical remedy, for the purposes of risk analysis, is to include overhead
activities in the analysis as well as direct charge activities. See also Appendix D.
15
See the section on Ishikawa diagrams in Appendix C for further discussion of root causes.

Page 99 of 199
We must have a project plan before we can assess risk, but do we need a complete
plan? Can we make do with a sketchy plan? The level of detail in a plan that is most
appropriate for assessing risk is generally less than the detail needed to assure that
everybody knows what to do at a particular time. Plans for major projects seldom have
a temporal resolution of less than one week, unless an important activity inherently
requires less than one week. But for analysis and management of risk, we generally
want to use a condensed plan that omits a lot of detail. Such a plan generally will have
100 or preferably fewer activities. It is the kind of high-level summary plan that is
typically presented in management briefings. Bottom up risk analysis in a project plan
showing many hundreds or even thousands of detailed tasks is impossibly tedious.
Each risk driver must be assigned a probability of occurrence. This is a number in the
range 0-1 or equivalently a percentage range 0-100%. This number is assigned
subjectively by the project team or by selected members of the team. The same group
that assigns the probabilities also assigns a cost impact range to each project task due
to each risk driver, given that it happens. This information is then combined with the list
of tasks to form a matrix such as shown in Exhibit 14-2:

Exhibit 14-2Example Risk Analysis

Bid to Win Simplified Risk Analysis
Probabilities of
Occurrence

WBS

Estimated
Probable
Cost $K

1
2
3
4
5
6
7
8
9
10

41.6
12.5
38.7
6
11.9
76.6
18
13.7
44.6
25.8

Total

289.4

0.3

0.7

0.2

Risk Driver #1

Risk Driver #2

Risk Driver #3

Min
Impact
-1
2
-12

Max
Impact
14
6
5

Min
Impact

Max
Impact

1
8
-12

12

12
5

Max
Impact
-1

12

20

10

-2
5
8
-4

3
8
20
1

2
5

21
7

Min
Impact
-6

11

^^ Impacts K$ ^^
Cost risk range (mean 3 standard deviations

302.6877

Risk
Adjusted
Cost K$
42.85
17.55
40.85
7.05
16.2
77.65
18.1
15
52.35
31.8

Risk
Impact
Variance
6.041667
0.925
8.291667
0.058333
1.216667
8.158333
0.416667
0.15
4.425
1.35

319.4

31.03333

319.4

336.1123

Page 100 of 199

In this exhibit, the risk drivers are represented by min and max impact values with
respect to each task, and also by probability of occurrence values. The impacts are
assumed to occur only if the risk drivers occur. The combined effects of each risk driver
are collected in the columns headed Risk Adjusted Cost $K and Risk Driver Impact
Variance. (For readers with a background in statistics, the risk adjusted cost is a
mean or expected value, and the variance is the square of the standard deviation.
For simplicity, each risk driver range is assumed to represent a uniform distribution of
the cost impacts.)
The $289.4K figure represents the total cost the team would have used in its plan in the
absence of risk. The total $319.4K represents a risk adjusted expected cost. The
difference of $30K is the likely overrun if risk is not considered in setting the bid amount.
Two other numbers are produced by the mathematics underlying the table. They are
the cost risk range, namely $302.7K to $336.1K. These are produced respectively by
subtracting three standard deviations from the risk adjusted amount and adding three
standard deviations to it. Readers who have taken Business Statistics 101 will recall
that typically the mean plus and minus three standard deviations includes most possible
outcomes. There is only a very small probability of being outside this range.16
An S-shaped cumulative probability curve for Exhibit 14-1 could be drawn by assuming
that the results from Exhibit 13-2 are normally (or better, lognormally) distributed. See
any decent college level business statistics text for further details.
Risk abatement in bidding
In a pursuit we potentially can talk about three kinds of risk abatement:

The risks you thought about during the pursuit phase and managed to eliminate due
to your relentless pursuit of the best interests of your customer. This allowed you to
lower your bid by some amount.

The risks you thought about during the pursuit phase and will continue to work on
once awarded the contract. You should do a realistic assessment of the potential
impact of these risks drivers and your plans for abating them.

Your plans for dealing with any risks you did not uncover in the pursuit phase to
protect ourselves and other stakeholders.

These three kinds of risk abatement form the basis of your project risk management
plan. If required by the customer, this is submitted with the proposal. If not required by
the customer you should prepare it anyway for your own use. (Sometimes a customer
will be fascinated that you have one and will be pleased to see it even if the customer
did not require it.)
16

Readers who would like to use the Bid to Win Simplified Risk Analysis tool shown in Exhibit 14-2 will find it
included in the CD you will receive if you acquire the Best Bid model. The tool will have capability for handling up
to 25 risk drivers and 100 WBS elements. Please see the last page of this book for instructions.

Page 101 of 199

A recurring issue raised by pursuit managers is the fear that if you submit a realistic risk
management plan and the competition plays down the risks, you will frighten the
customer and lose out in the bidding. This is sometimes a realistic fear. The answer is
to know your customer (chapter 2). If there are real risks in the project that are common
to all competitors, and your customer has failed to see them, they should be discussed
with your customer long before the request for proposal is issued. The customer will
then not be surprised to see them discussed in the proposal. In fact, the customer will
be surprised if they are not discussed.
If the risks are peculiar to your project design, they could be ignored or understated in
the proposal, but the risk in that is that one or more competitors may spot your
vulnerability and use it to flog you in their proposal. This might be more damaging than
a forthright statement of the risks and your means for dealing with them.
Customers today are often quite astute about risks and their potential impacts on the
project. If your customer is astute in this area, one thing worse than honestly admitting
to serious risks in your proposal is to attempt to cover them up. Worse still is not to be
aware of them.
We always advocate that the project team statistically quantify its risks on all large or
complex projects, but this does not necessarily mean that a quantified risk analysis
should be presented to the customer in the proposal. For many customers this is
overkill. For customers ill equipped to deal with statistical analyses, we recommend a
simple high, medium, low approach to risk description. But we do always recommend
the identification and description of root cause risk drivers for customers, and at least a
general, non-quantitative discussion of their possible effects.
Most efforts at risk abatement boil down to one or a combination of the following ten
activities:

Analysis. Analysis includes studies, models, simulations, and research, both

primary and secondary. Analysis usually is the mitigation tool of choice when the
root cause of risk is ignorance, and the desired knowledge is not readily available
from educators or trainers. If knowledge is available from others, education may be
faster and cheaper than analysis.

Insurance. The general idea of insurance is that a third party agrees to pay for an
unfavorable outcome that matches a carefully worded description contained in the
insurance policy document. In return, you pay a fee, called a premium.
Generally, before a third party will agree to do this, there must be a clear pattern of
occurrences of the unfavorable outcome, from which probability and size of loss can
be ascertained with high confidence. The insurer sets premiums at a level that is
expected to cover loss liabilities, internal costs, and profit. Generally, projects
cannot buy insurance for losses other than the ones traditionally covered by
insurers, such as fire, product liability, key person, etc. The reason is that there is

Page 102 of 199

no history. Insurers, unlike most project risk analysts, are seldom willing to assign
probabilities based on intuitive or scant evidence. The phenomenon called selfinsurance occurs when a project is willing to (or must) absorb its own losses. This
amounts to acceptance of the risk, and is not by itself a mitigation technique.

Buy-out. A significant risk in some projects is that a key resource may not be
available when it is needed. The key resource might be anything from an engineer
with a special skill, to a fortuitously sited and equipped warehouse, to a particular
type of application specific integrated circuit (ASIC) that is about to go out of
production. The idea of buy-out is to acquire the critical asset while it is available,
and before it is actually needed. Your author once worked on a project where there
was a major antenna design problem, and none of the engineering staff was
adequately familiar with that body of knowledge. It was still six months before the
project needed the services of an antenna specialist, but the team proceeded to hire
a recent PhD level graduate with the requisite skills. The team thus preempted the
possibility of not having the necessary skills when it needed them, but the team paid
the price of six months salary and benefits for the engineer, who was given other,
fairly trivial work that could have been done by a lower paid engineer.

Transference / sharing. The basic idea here is to spread risk around so that the
impact of an unfavorable event is distributed over more than one project stakeholder
(sharing), or is loaded onto the stakeholder best able to manage it (transference). As
an example of transference, in cost plus contracts the sponsor takes most of the risk
because inherent risk is deemed to be high, and the impact on the project prime
performer might be so severe as to put him out of business. Without the
transference, it might be that no performer could be found to attempt the work. As
an example of sharing, there are arrangements where a cost overrun is shared
between the performer and the sponsor. This creates an incentive for the performer
to avoid an overrun condition, but gives the sponsor some protection if the performer
cant avoid it.

Incentives. An incentive is a conditional payment offered to the performer in the

hope that he or she will work more efficiently than usual. A common use of
incentives is to get a project completed quickly. In an earthquake in California some
years ago, there was severe damage to a major freeway. The result was huge
traffic jams. A construction company was offered an unusual cash incentive if the
repair work could be completed in only three months. The construction company
offered to pass most of the incentive money down to its employees if the very tight
schedule was met. It was. The incentive eliminated an obvious risk driver.
(Naturally, there was much criticism of the contractors obscene profits, and
practically no mention of the huge social costs of the traffic jams.)

Penalties. A penalty is a conditional reduction in the contract price, imposed if the

performer fails to meet certain conditions. Probably the most common use of
penalties is to encourage the performer not to finish later than a critical need date.
But there are other uses as well. For example, penalties can be used to mitigate the

Page 103 of 199

possibility of poor quality, unfair labor practices, environmental damage, and a host
of other perceived ills.

Redundancy. Redundancy is the use of multiple means to ensure a critical

outcome. The idea is that if one or more means fails, there will be backup means to
prevent a complete failure. Many types of redundancy have been used in projects.
Examples are parallel studies to determine the best way to do something, redundant
critical devices in case one fails, and redundant communication channels to assure
that a message gets through.

Cost reductions. Suppose that in the baseline design of a product there is a part
called a gizmo that costs an estimated $100. But no gizmo has ever been built, so
there is some uncertainty in the cost. Assume we believe that the gizmo might cost
as much as $110, i.e., we believe the risk is $10. Now, suppose that an enterprising
engineer says he or she can duplicate the function of the gizmo with a part called the
omzig that is already in production, and that costs $100. If we decide to use the
omzig and not the gizmo, we have mitigated the $10 risk provided that we have not
inadvertently introduced new risks that exceed $10. Cost reduction disciplines, such
as target costing and value engineering, can be powerful risk mitigation tools. But
we must be certain that the lower cost item doesnt introduce new risks that offset
the benefits. So often, what looks like a clever cost reduction idea turns out to be
just another high risk item.

Education. Education is a quick and often inexpensive way for a project team to
acquire needed knowledge that already exists. Education can mitigate ignorance.
Suppose, for example, that a factory wants to start using programmable logic
controllers to automate certain functions. But the factory engineers have never
worked with these devices. A vendor of training offers a well-regarded five-day
course in the subject, and will put a subject matter expert in the factory for a month,
at a reasonable price, to aid the transition. Risk removed, but at a cost.

Avoidance. Avoidance means backing away from project goals that have marginal
value and high cost or risk. The typical situation is that the project performer finds
that to accomplish a certain goal, costs will exceed the budget. The performer
appeals to the sponsor to remove the goal. The sponsor agrees that the goal can be
dispensed with, in the interests of containing costs. Sponsors may not always agree
to an avoidance appeal, especially in fixed price work where the contractor bought
in by bidding too low. This is a major risk for contractors who like to bid too low in
the hope of making it up later with directed change work.

Allocation of risks among stakeholders

We conclude this chapter on analyzing and abating project risks with a question any
project stakeholder should ask: Whose risk is it? Projects can be structured in any
number of ways. Many types of relationships can exist between stakeholders. Some
risk drivers may damage or benefit some stakeholders more than others.

Page 104 of 199

The ideal arrangement in any project is when risk is allocated to the stakeholder best able to
manage it.
Managing it includes having the resources to pay for bad outcomes that happen in
spite of everyones best efforts. Poor allocation of risk is itself potentially a risk driver,
because if a bad thing happens to a project team member (e.g., a subcontractor) who is
vulnerable, the subcontractor may fail, and bring the project down.
There are many devices for distributing risk. A success-oriented project should look for
a win-win selection of these devices. Here are a few:

Indemnification clauses in contracts.

Escalation clauses or other protections against unexpected currency inflation or

exchange rate changes in international projects.

Subcontracting to give some of the work to teams that are better qualified to do it
(but be aware, every subcontract removes some control from the prime contractor;
poorly qualified or unethical subcontractors can create big problems).

Incentive and penalty clauses to encourage good management and discourage bad
management.

Use of fixed price contracts to protect the sponsor (but be aware, this can increase
risk if the executing team might fail due to underbidding or misunderstanding the
work).

Use of cost plus contracts to protect the contractor (but be aware, this can potentially
cause the contractor to manage carelessly, running up the sponsors costs).

Buying insurance for those risks that can be cost-effectively mitigated this way.

Requiring a risk management plan with frequent status reports.

Observing the work in progress first hand, with on-site representatives, not through
intermediaries.

Projects as Complex Systems

In recent years, a discipline called complexity theory has gained currency in academic
circles. It essentially is the study of the behavior and properties of complex systems.
This has relevance to project management to the extent that projects qualify as complex
systems.
The definition of a complex system seems to vary somewhat from authority to authority.
This apparently reflects the status of complexity theory as a discipline still in the

Page 105 of 199

definition phase. Here are some definitions, all from the Wikipedia article Complex
System as it appears at the time of this writing:

A complex system is a system composed of interconnected parts that as a whole

exhibit one or more properties not obvious from the properties of the individual parts.

A complex system is a network of heterogeneous components that interact

nonlinearly, to give rise to emergent behavior.

A complex system is a highly structured system, which shows structure with

variations.

A complex system is one whose evolution is very sensitive to initial conditions or to

small perturbations, one in which the number of interacting components is large, or
one in which there are multiple pathways by which the system can evolve.

A complex system is one that by design or function or both is difficult to understand

and verify.

A complex system is one in which there are multiple interactions between many
different components.

Complex systems are systems in process that constantly evolve and unfold over
time.

In 2009 the Project Management Institute (PMI), a large organization dedicated to the
study and improvement of project management, commissioned a monograph titled
Exploring the Complexity of Projects: Implications of Complexity Theory for Project
Management Practice (Cicmil, et al). The monograph provides this definition:

Complexity theory can be defined broadly as the study of how order, structure,
pattern, and novelty arise from extremely complicated, apparently chaotic systems
and conversely, how complex behavior and structure emerges from simple
underlying rules. As such, it includes those other areas of study that are collectively
known as chaos theory, and nonlinear dynamical theory.

A point strongly made in the monograph is that widely promoted good methods of
project management, such as those promoted by PMI or in this book, are the product of
generations of linear thinking in the mode of Newton, Descartes, and the
Enlightenment, and do not take into proper account the sad fact that complex projects
are highly nonlinear entities, in which, according to the theory, outcomes are radically
unpredictable.
Your authors carefully searched the monograph for recommendations for how to
abandon our errant Newtonian/Cartesian/Enlightenment ways and start managing
consistently with the new understanding about nonlinearity. All we could find was a

Page 106 of 199

recommendation that project manager training should make managers aware of the
phenomena associated with nonlinearity, such as the butterfly effect, strange attractors,
fractals, edge of chaos, dissipative structures, self-organizing systems, emergence, and
the like.
By the way, that word emergence seems to crop up quite frequently in learned
discussions of complexity theory. It seems to have many meanings. The most
traditional meaning seems to be simply coming into existence, but your authors
suspect that what is intended with respect to project management is something like the
following: It is likely that the results of a project will be affected by unknown factors, and
that planning only has a limited effect on the outcome.
Is project planning hopeless? A quote from G.K. Chesterton may be helpful here:
The real trouble with this world of ours is not that it is an unreasonable world, nor even
that it is a reasonable one. The commonest kind of trouble is that it is nearly
reasonable, but not quite. Life is not an illogicality; yet it is a trap for logicians. It looks
just a little more mathematical and regular than it is.
Your authors agree with Chestertons worldview, and also with Dwight Eisenhowers,
who thought that planning was ineffective, yet absolutely necessary. We also agree
with whoever said this: Life is not about waiting for the storm to pass. It is about
learning to dance in the rain.
In this context we must take note of the worlds special forces and SWAT teams, those
groups of rough men and women who handle the really bad guys so that the rest of us
wont have to. These groups are arguably some of the best project managers around.
Most of their projects have to deal with serious unknown unknowns, yet mostly they
succeed. The keys seem to be:

Competence.

Preparation.

The right tools.

As many Plan Bs as they can think of, and the ability to instantly switch from one
plan to another without confusion.

Rapid, unambiguous communications.

Cross-training.

A clear understanding of what success means in every project.

Page 107 of 199

Your author once heard this rather cynical but insightful comment about project risk
management, by a project manager who chooses to remain anonymous:
If you must swim an African river, first shoot all of the crocodiles you can see, then
have one swimmer preceding you, one following you, and one on either side of you.
Swim as fast as you can.
Chapter 14 Review Questions
1. One of the presumed advantages of upgrading project team capabilities in
accordance with published standards such as CMMI (Capability Maturity Model
Integrated, based on work done at the Software Engineering Institute at CarnegieMellon University) is that the more capable teams will not only have lower costs, but
their costs will also be more consistent (less variable). Discuss the possibility that a
team that has reached the highest level of such a standard could have its project
success insured by an insurance company, or would want to.
2. European governments often insist that contractors take fixed price contracts for
both development and production work. U.S. government practice is more often to
let CPFF contracts for development and fixed price for production. Discuss the
relative merits of these two approaches.
3. Sometimes when team leads estimate their costs bottom up, they add two judgmentbased contingency amounts. The first is a just in case amount to cover any missed
items. The second is an amount they dont think they will really need but they add it
anyway to protect themselves from possible arbitrary cuts by the pursuit leader.
Critique this practice. Is there a better paradigm?
4. Think of a possible risk driver on a current or recent project. Is it really a root cause?
If not, what is the real underlying root cause?
5. In drilling down from symptoms to root causes, what is a reasonable stopping rule?

Page 108 of 199

Chapter 15Get all of the right things into your proposal

The initial part of this chapter serves as a foundation for building a proposal checklist.
We leave the details of the checklist to you. To guide the development of a proposal
checklist we present four rules of proposals. These rules, in our opinion, should guide
in a general way all of your actions with regard to proposals. Everything else is an
elaboration and refinement of these rules.
The final part of this chapter discusses critiquing your proposal. A well organized
critique can be the difference between winning and losing a competition.
Proposal rules
Here are the four rules we recommend.

Rule 1. The physical proposal must comply with all customer instructions. This
seems obvious, but sometimes pursuit teams overlook the obvious in their haste to
meet the proposal deadline. This rule is often of critical importance because failure
to comply may result in all or parts of your proposal being thrown out. To be sure
that this rule is observed, the pursuit team should carefully search the customers
written request for proposal and other customer information and locate all direct or
implied instructions that have to do either with the nature of the proposal or the
proposal submittal. These should be organized into a database or checklist.
Someone reliable on the pursuit team should be designated to monitor the proposal
cycle to be sure that all instructions are scrupulously observed. Here are some
frequently encountered customer instructions relating to proposals. This list is not
comprehensive.
o Overall organization. A typical instruction is to provide separate sections or
volumes for management, technical, and cost.
o Size of paper and fonts. The size of paper might be specified, e.g. 8-1/2 x
11. A particular font (such as Arial 10 point) might be prescribed.
o Allowed maximum page counts. Customers often feel they need to restrict
the number of pages in certain areas of the proposal. They do this to avoid
being overwhelmed with the effort required to read and digest the proposal in
the time available. There may also be limitations on the number of foldout
pages, the number of volumes, and other features. Do not exceed any such
limits imposed by your customer.
o Graphics and publishing expense. Many customers sincerely want bidders to
avoid expensive features such as four-color art, leather binders, etc. If your
customer says keep it simple, then keep it simple.
o Distribution. Commonly the customer will specify the number of proposal
copies it needs and where they should be sent. Be sure that everyone on the

Page 109 of 199

list gets the right number of copies. The customer may declare a different
distribution for some of the proposal sections or volumes. Be sure to honor
this.
o Method of transmission. The customer often will specify how the proposal will
be transmitted. Today a common practice is to require transmission
electronically, perhaps even by secure by e-mail. If you send a proposal by
e-mail, be sure to confirm that it was received.
o Due date and time. Generally the customer will specify the latest date and
time it will receive the proposal. In most proposal situations, failure to deliver
by the specified date and time will result in your proposal being thrown out.
o Specific data. The customer may specify particular data from tests or from
other sources that it wants. Review such data requests carefully. If the data
are proprietary or confidential, be sure the proper safeguards are in place. If
you think the customer is asking for the wrong data, ask for clarification.
o Specific commitments. The customer may require specific commitments,
such as using small businesses for some fraction of the work, completion of
parts of the work by a certain date, etc. If you can fulfill the commitment in
your proposal be sure to do so. If not, be sure to explain how you will fulfill it
once under contract.

Rule 2. The physical proposal must clearly show how it complies with all customer
instructions. Of course, the customer will want you to comply with all of his
instructions for the proposal. And if you are at all clever, you will. In a four page
proposal full compliance may be self-evident. But in a 1,000 page proposal, or even
in a 20 page proposal, the customer may find it difficult to locate all of the things he
asked for. To avoid making difficulties for your customer, you must add a useful
feature to every proposal that the customer may not have asked for. Some call it a
compliance matrix. Others call it a proposal directory.
What is it? Its a page, or a few pages as necessary, where everything the customer
asked for is listed in some coherent manner, and adjacent to those listings appears
its location in the proposal, by volume number and page number. If there is an
appropriate exhibit, table or figure number that should also be noted. The
compliance matrix should appear at the beginning of every proposal volume. In an
electronically delivered proposal, it may be possible to arrange things so that the
customer can bring the proposal up on his computer, click with his mouse on the
item wanted and immediately be taken electronically to the material sought. That
kind of thoughtfulness will be appreciated.

Rule 3. The proposal must explain how you will meet each and every project goal.
Compliance with the project goals is distinct from compliance with rules regarding
the physical proposal. Goals are of two types: positive and negative. As elsewhere

Page 110 of 199

explained in this book, a positive goal is something the customer wants the project to
accomplish. It could be to create something new, modify something old, or some
combination of these. A negative goal is a constraint. It is something the customer
is not willing to give up in order to achieve his positive goals. Commonly it is a
limitation on cost or duration, but many other types of constraint are possible.
A widespread failing of proposals is that they say they will meet all of the goals, but
they dont say how. Believe it or not, your author has seen the following type of
unintelligent response in proposals. You may have, too. The phenomenon is not
rare.
Customer goal: The aircraft shall be able to reach 40,000 feet altitude.
Proposal response: The aircraft will be able to reach 40,000 feet altitude.
Imagine that you are the customer reading the above. Later, you pick up a
competitors proposal that has a two page analysis citing wind tunnel test results,
aerodynamic analyses, and other data proving beyond a reasonable doubt that the
aircraft will be able to reach 40,000 feet altitude. Which proposal would you find
more credible?
Of course, not every goal is deserving of a multi-page proof. The more important the
goal, the more necessary it is to provide a thorough, convincing response. This of
course argues for a good understanding of how the customer values his various
goals. See chapter 4 for further discussion. A minor goal, such as painting a
surface a certain shade of white with a paint meeting a certain specification might
simply be acknowledged.
It can be just as important to be convincing about being able to meet negative goals
as about positive ones. If the customer has a constraint on completion date that is
important to him, it is worthwhile for you to provide a detailed schedule risk analysis
that shows a reasonable margin of safety for the critical path.
Your price can be an especially touchy item from a credibility standpoint. If you
know the customers upper limit, you certainly want to be below it. If you dont know
it, you should try to make a best guess as to what the customer will view as
reasonable, and stay below it. The same goes for observing his lower limit. See
also chapter 8.
If you know or believe that the customer has a certain way of estimating what he
thinks the cost should be, you are wise if you try to estimate it the same way, to be
sure you get a result you think the customer will find realistic. For example, if it is
known that the customer is partial to a certain commercial parametric estimating
model, it would be wise to use that model to create a project estimate.
The best way to be credible about cost goals is to write good bases of estimate
(BOEs). See Appendix B for added discussion of this important subject.

Page 111 of 199

You need to pay special attention to areas you think your customer will perceive as
risky. If the customer has reason to believe that you are bidding on a high risk basis,
he or she may go so far as to arbitrarily adjust your bid upward to account for the
risks as they are perceived. This can destroy your chances of winning.

Rule 4. The proposal must counter known or likely competitive threats. Whatever
other meritorious qualities your proposal may have, if you ignore what the
competition is likely to say in its proposals, you might well lose. Clever competitors
will try to find your weak points and your strong points. To the extent that they can,
they will try to exploit your weaknesses and direct attention away from your
strengths. If you do nothing to counter this, if you leave their likely claims
unanswered, your customer could become their customer.
The process of defending against competitor claims is sometimes called ghosting
their proposals. Ghosting arises from a situation where you believe a competitor will
advocate a certain approach, and you believe the customer, when fully informed, will
like yours better. Without naming the competitor, you insert a trade study result
that shows you considered the approach you believe the competitor will use, then
you demolish it point by point, showing how the approach you took is better.
If you cant demolish a competitors claim, you should show that your approach has
at least equal merit. If your approach is weaker, you should first ask yourself why
you are doing what you are doing. If its unavoidable, you need to stay silent and
mark the matter down as something to try to fix if you want to propose in this area of
technology again.

Critiquing the proposal. Many wonderful things can be done electronically nowadays.
A proposal can be stored on a server and accessed by all members of the pursuit team.
Comments can be added and identified as to author. That process can be used to
eliminate typos and other mistakes, and to make needed improvements. But perhaps
because we are old-fashioned we believe that with all the wonderful things that can be
done with the computer there is still no substitute for a wall review. A wall review
permits face to face conversation between reviewers, and that can be a valuable thing.
In a wall review, every page of the proposal is pinned or pasted on a wall at a height
convenient for reading. Members of the team can walk along the wall and read it and
mark it up. Important: every markup must bear the initials of the reviewer.
Unfortunately, a wall review can sometimes degenerate into confusion. Heres how this
can happen. A reviewer perceives that a mistake was made and marks the proposal to
indicate a needed change. The proposal coordinator thinks the change is valid and
makes it, putting the new text up on the wall. A second reviewer sees the new text and
has a different opinion about what is the right way, and again marks for a change,
perhaps back to the original text.

Page 112 of 199

Sometimes this kind of thing will happen in the best organized of pursuit teams, but
there is a way to minimize it. The first step is to recognize that in certain areas of the
proposal there may be differences of opinion as to how things should be done. But
clearly these differences must be resolved before the proposal is submitted. The
pursuit manager must decide which approach is best and promulgate that approach as
the proposal baseline. By the time the proposal goes up on the wall, no member of the
team should have any doubt as to what the baseline is, especially in areas likely to be
controversial.
A good thing for the pursuit manager to do is to post the baseline assumptions and
ground rules on the proposal wall and make them required reading for all reviewers.
Any reviewer who disagrees with any of them should be made to feel free to write his
comments, but not to change the baseline.
Thorough reviews by the pursuit team are good, but they have the built-in disadvantage
that the pursuit team members are intimately close to the problem and may suffer from
cant see the forest for the trees effect. Because of this, it is wise to have the proposal
reviewed by others who may have a useful perspective. Others should include
members of senior management, trusted independent experts in areas of difficult or
unique technology, and people who know the customer or the competitors well.
Chapter 15 Review Questions
1. In your last proposal, did your team designate someone to be sure that the physical
proposal met all customer requirements? If not, why?
2. Have you ever been on a team whose proposal was thrown out or almost got thrown
out because of failure to meet customer requirements? If so, what happened?
What actions would have kept this from happening?
3. In your most recent proposal did your team provide a compliance matrix, proposal
directory, or equivalent? If not, why not?
4. In the rush to get a proposal out the door, there is frequently a lot of rewrite, new
graphics, and other disturbances of the previously established order. This can make
it difficult to maintain the compliance matrix. Has your team ever dealt with this
problem? Did you find a satisfactory solution?
5. A common problem with proposals is that the management volume will crow loudly
about how skilled and experienced the team is with the subject at hand, but when it
comes to writing bases of estimate, the usual response is Engineering judgment.
This leaves the customer wondering why, with all that experience, you have no
better basis of estimate than engineering judgment. If you had this problem, how
would you try to correct it?

Page 113 of 199

Chapter 16Keep the proposal going

Once your proposal is submitted several things can happen. The worst of those is that
your proposal is disqualified for one reason or another. Lets hope you are always
careful enough never to let that happen, but if it does happen you will resolve never to
let it happen again.
Here are some other things that can happen:

You will be thanked for your interest and told that somebody else is the winner. If
this happens you should always ask the customer for a briefing on why you lost.
Assuming the briefing is granted, you should come well prepared to ask and record
the answer to every relevant question. Your customer may not be allowed to answer
some of them, but you should ask them anyway unless you are told not to by the
customer. The idea is to get every available scrap of information about your
customers choices and why they were made, and also about what your competitors
did and why. This kind of information can be extremely valuable for guiding your
internal research and development and your future proposals. Typical questions
are:
o Who bid?
o Who won?
o How much did each bidder bid?
o What was the winning technical approach? Why?
o What was the winning management approach? Why?
o How could you have improved your proposal?

You will be congratulated and told that you won. At some point you will sign a
contract and get your project underway. But you still should ask for a briefing, just
as if you had lost, and for the same reasons. It is important for you to know what
your customer saw as your strengths and weaknesses, and how you stacked up
against various competitors. The knowledge gained can also help you manage the
project better. If your customer liked something a competitor offered better than
what you offered even though you ultimately were the winner, you may want to
incorporate your competitors good ideas into your project.

Your customer may attempt a squeeze play. This goes by various names: bid
shopping, best and final offer, etc. The most egregious form of it is blatant bid
shopping. For example, your customer may say that he likes you or your approach
but he has a bid that is 15% under yours and can you come down 15%?

Page 114 of 199

Or, a bit less blatant, he will plead poverty and ask you to reduce your bid by x%.
The U.S. government typically asks for a best and final offer in the hope that you
will fear for what a competitor might do and offer a price reduction, extra product
features, or whatever.
The possibilities are too numerous for us to prescribe general advice to any
particular squeeze play, except this: If your proposal was carefully thought out, dont
go into a last minute panic and assume that all is lost unless you make a major
concession. That last minute panicky concession could destabilize the project when
you win it and cause you problems that echo down through the canyons of time.
On the other hand, it is wise to have a list of minor concessions ready at hand in
anticipation of a squeeze play. Youve already carefully thought them through and
have convinced yourself they will not adversely impact your performance of the
project.
Chapter 16 Review Questions
1. Have any of your proposals ever been disqualified? If so, what actions did you take
to keep this from happening again?
2. Whatever the outcome of your proposals, do you always try to get a customer
briefing to explore why you won or lost? What is the most frequent major reason
why you won? Why you lost?
3. Have you recently had a customer try a post-proposal squeeze play? What did he
do? What was your response? What was the final outcome?

Page 115 of 199

VI For the Future

Chapter 17Keeping the game going
Review of the nature of advanced contracting
The kind of contracting this book is about is the kind of contracting in which the bidder is
judged on his total proposal package. Bid price is a very important part of the package,
but hardly all of it. Many factors may be considered to determine the winner in a given
case. To distinguish it from the kinds of contracting where low bid is the only
consideration (other than being qualified to bid), we call it advanced contracting. That
label seems justified, because to remain competitive bidders must be up to speed in
their technical discipline, and must stay that way.
Some organizations engaged in advanced contracting are also engaged in a multitude
of other activities. Generally, however, there exists one or more identifiable
components of such an organization whose primary raison detre is the advanced
contracting function. This discussion will be indifferent to any organizational matrix
within which the advanced contracting function may happen to be embedded, since the
focus will be on certain planning and decision problems unique to the advanced
contracting business.
A characteristic of the advanced contracting business which distinguishes it from the
more traditional forms of competitive contracting such as most simple construction,
drayage, provisioning, concessions, etc., is the multiplicity of criteria which the contract
sponsor may apply in determining the winning bidder. In traditional contracting, award
of a contract to other than the low bidder generally requires specific justification, and in
many instances is so exceptional as to be newsworthy.
In advanced contracting each bidder is judged on his total bid package, and on the
basis of other special criteria as well. The bid package typically consists not only of the
traditional letter or form disclosing the bid amount, but a host of other disclosures, such
as:

Demonstration of understanding of the technical nature of the project being bid.

Demonstration of competence in the technologies involved in the project.

Outline of a proposed technical approach.

Identification and qualifications of key personnel who will be involved.

Proposed schedule of performance.

Location of the contractors facilities.

Location of principal subcontractor facilities.

Page 116 of 199

Level of unemployment in contractors locale.

Contractors present workload and work capacity.

Recent similar contract awards.

Contractors technical and managerial reputation.

Size and resources of contractors organization.

Another distinguishing characteristic of advanced contracting might be called high

technological flux. In traditional contracting, new technology tends to be absorbed only
after it has proved convincingly superior to the old way. In advanced contracting, on
the other hand, new technology may develop on an almost daily basis; the advanced
contractor must at least stay abreast of the state of the art of all of the technologies
germane to the contracts he wants to bid.
To be aggressively competitive, he sometimes must even advance the state of the art.
Technological flux influences his ability to win contracts, and it affects his ability to
perform contracts he may have been awarded. This is especially true of contracts
where a new state of the art must be created in the course of performance. Such
contracts may be said to carry a high technical risk.
A third distinguishing characteristic of advanced contracting is the diversity of contract
funding arrangements. In the traditional situation, the qualified contractor submitting the
low bid wins the contract, and he is expected to perform using the amount of the bid as
his sole reimbursement. There may be exception clauses in his contract which afford
some protection in the event of strikes, natural disasters, inflation, etc., and there may
be bonuses for early completion and/or penalties for late completion. All of these
arrangements are used in advanced contracting, too, as well as some others which the
conventional contractor seldom encounters, such as cost-plus-fixed-fee funding, or costplus-fixed-fee with incentives. When a request for proposal specifies one of the costplus-fixed-fee types of funding, the amount of the bid may well be lower than when a
fixed price arrangement is specified, since the risk to the contractor is generally less.
Usually, cost-plus-fixed-fee funding and its variants are used by sponsors in recognition
of the fact that the contract subject matter involves high technical risk. Because of this
risk, the level of performance achievable for a given amount of money is always in
doubt, right up to the time the money is actually spent. Similarly, the amount of money
needed to reach a given level of performance is in doubt, right up to the time the
performance actually is achieved.
Thus, the cost-plus arrangement allows the contractor to pass on some (perhaps most)
of his risk to the contract sponsor, who generally has deeper pockets than the
contractor.

Page 117 of 199

In summary, three major characteristics have been identified which distinguish
advanced contracting from more traditional forms:

Multiplicity of criteria which the sponsor uses to select the winning bidder.

High technological flux.

Diversity of funding arrangements.

In the next section, we will address a set of important planning and decision problems
that are unique to organizations that survive by winning bids in the arena of advanced
contracting.
The advanced contracting annual planning cycle
Advanced contracting organizations, like most other serious firms, usually have an
annual planning cycle, that is, at about the same time each year certain aspects of their
situation are reviewed, and certain decisions are made as to probable future actions. In
general, the decisions will include such matters as approaches to take in obtaining new
business, budgets for business search and proposal activities, including budgets for
internal research and development. Also considered will be management of continuing
work on existing projects (backlog), and profit goals.
The advanced contractors annual planning exercise is often an update of a three-, five-,
or seven-year master plan. Because of the uncertainties in the advanced contracting
business, however, plans which go beyond the forthcoming year tend to contain a lot of
wishful thinking, except for backlogged business which may sometimes extend several
years into the future. Even backlogged business occasionally has a way of drying up
and disappearing for one reason or another, which introduces further uncertainties.
While the annual planning sessions set the tone for the coming years activities, it is a
rare advanced contracting organization which completes a year with its annual plan
intact. There are many reasons for this. For one thing, in many firms the contract
turnover is high, i.e., the gross revenues in a given year may contain only a relatively
small amount of business which was backlogged at the beginning of the year.
Another reason is the high degree of technological flux already mentioned. Sometimes
technological breakthroughs or difficulties affect contracts in such as way that planned
cash flows are suddenly changed, up or down.
Yet another reason is that annual plans tend to make definite assumptions about the
outcomes of pending competitions for new business, about the number and kind of new
business opportunities that will arise as the year progresses, and about the outcomes of
those competitions. While the assumptions may seem very reasonable at the time they
are made, things usually turn out to be different, which means that the annual plan must
be adjusted one or more times during the year.

Page 118 of 199

With all of the uncertainties, it is very common for advanced contracting firms to engage
in a substantial amount of re-planning and revised strategizing as the year progresses.
Indeed, in a great many firms, the re-planning required consumes much more time and
effort than the original annual plan. Going even further, one can say that in many firms
with high contract turnover (usually the smaller firms) one of the principal functions of
first level line supervisors is to re-plan their manpower needs in terms of available
funds, sometimes as often as weekly. Similarly, middle managers are concerned with
re-planning because it is needed to determine realistic departmental and divisional work
force levels and work priorities. Top management also is concerned because, in the
high state of flux characteristic of advanced contracting, potential profits can evaporate
quickly if planning does not keep up with developments.
The advanced contracts business is highly labor intensive, and a large fraction of the
labor force tends to consist of highly paid technical professionals. Thus, cash flows for
labor costs are usually by far the largest component of the negative cash flow for any
contract. Further, adjustments to the labor force (except by natural attrition) are difficult
to make in most instances. Hiring new professionals to fill out a deficient labor force is
time consuming and expensive, and the new people are usually of limited effectiveness
for at least a month or two, while they are learning their new jobs. Unfortunately, a labor
force deficiency today may turn out to be a surplus tomorrow, considering the
uncertainties. Laying off professionals to reduce a surplus labor force is agonizing to
top management because of the human values involved, and also because, after a
certain point, it tends to weaken a firms technical capabilities and overall employee
morale.
Because of the nature of the labor force in the advanced contracts business, a primary
goal of most re-planning is to achieve stabilization of the labor force insofar as possible.
Indeed, many advanced contracts firms treat this stabilization as a goal secondary only
to the overall profitability of the firm. In some cases, immediate profit gains are
sacrificed for the sake of stability, on grounds that stability will enhance longer term
profits. Planned schedules are sometimes modified for the same reason.
With the preceding discussion providing the necessary background, it is now possible to
describe a typical advanced contract firms planning cycle. We let it begin at some
convenient time zero as a point of reference. Beginning at that time, management
undertakes to establish its instantaneous situation as a baseline for the planning. This
baseline typically comprises the following seven elements:

Human resources. The array of technical and managerial talent embodied in the
skills of personnel comprising the firms current work force.

Physical resources. The inventory of equipment and facilities usable by the

technical and management personnel in the performance of their work, including
items such as scientific equipment, computers and computer codes, factory
machines and tooling, test facilities, office buildings, vehicles, etc.

Page 119 of 199

Financial resources. Cash reserves, securities, receivables, lines of credit, etc.,

which are available for use in the course of business.

Inflexible financial commitments. Debts, bond redemptions, contracted services,

leases, pensions, etc., and other factors which act to limit the range of business
operations.

Flexible financial commitments. Payroll, payroll related expenses, rentals, travel,

services, consultants, etc., the level of which can be adjusted by management to
meet changing conditions.

Backlogged business. Business already under contract and the implications of that
business for use of human and physical resources, and the likely effect of that
business over time on financial resources, inflexible financial commitments, and
flexible financial commitments.

New business prospects. New business for which there is a non-zero win probability
of capture in the coming year and the implications of that business for use of human
and physical resources, and the potential effect of that business over time on
financial resources, inflexible financial commitments, and flexible financial
commitments.

The backlogged business represents obligations that must be met over the coming year
and perhaps longer. Normally, these contracts will make possible net positive cash
flows which will be the basis of at least a part of yearly profits. Also, they will require
use of at least part of available resources. Sometimes there is uncertainty about the
continuation of all or part of backlogged business due to sponsors possible desires to
expand or reduce the scope of the work.
If the firm has a large backlog of highly certain business, with low contract turnover, it
may elect to give relatively little consideration to new business prospects. As a rule,
however, advanced contracting firms are highly concerned with seeking out new
business, and with structuring their planning to take it into account.
From this point, it will be helpful to proceed using a numerical example. To that end, let
us imagine a small firm called TEK-R-US that is currently doing its annual plan. We will
focus first on the positive cash flow effects of backlogged business and the prospects
for new business, returning later to other effects that may result.
Suppose that TEK-R-US has three contracts backlogged. Following is the relevant
information:

ABC Project. A certain source of $250,000 per month for the first six months,
$100,000 per month for the next four months, and $50,000 per month for a final two
months of the current year.

DEF Project. A certain source of $50,000 a month for the first eight months. After
that time it is hoped, but not certain, that the sponsor will exercise an option resulting

Page 120 of 199

in an additional $25,000 per month for four more months of the current year. A
probability of 50% has been assigned to exercise of the option.

GHI Project. This project is experiencing severe technical difficulties. It may be

cancelled. If cancelled, it will yield $100,000 per month for the first two months and
nothing thereafter. If not cancelled, it will yield $100,000 for four additional months.
A probability of 50% has been assigned to cancellation.

We assume that TEK-R-US also has identified three projects that it has better than a
zero probability of winning. Suppose that the following describes these potential
projects:

JKL Project. If won, this project is expected to produce no revenue for the first three
months. After that, it is expected to produce revenues of $100,000 per month for the
rest of the year. A win probability of 55% has been assigned to this project using the
Best Bid model.

MNO Project. If won, this project is expected to produce no revenue for the first five
months. After that, it is expected to produce revenues of $50,000 per month for the
rest of the year. A win probability of 38% has been assigned to this project using the
Best Bid model.

PQR Project. If won, this project is expected to produce no revenue for the first
seven months. After that, it is expected to produce revenues of $150,000 per
month. A win probability of 22% has been assigned to this project using the Best
Bid Model.

Readers familiar with the expected value concept of statistics could be tempted to apply
that methodology to this situation. Unfortunately, careful examination of the data will
reveal that outcomes in the vicinity of the expected value have a rather low probability of
occurrence.17 The objective of annual planning is to anticipate what is most likely to
happen, and devote most planning to that, with perhaps some contingency plans for
somewhat less likely outcomes. How,
then, to proceed?
We will proceed using an approach
that underlies the Best Plan model, a
companion of the Best Bid model.
The Best Plan model performs a
Monte Carlo simulation analysis of the
plan inputs. It is available free on a
CD. For the TEK-R-US inputs
previously described, the resulting

17

Note that the average value from the toss of a single die is 3.5. But that value has a probability of zero of
occurring.

Page 121 of 199

histogram is shown nearby. The most likely outcome is revenue between $3.5 and $4.0
million. That has a probability of 30%. There is an almost equal probability of an
additional half million in revenue. The probability of about a half million less is 23%.
TEK-R-US would apparently be wise to focus its planning on revenues of about $3.5
million, with contingency plans for as low as $3 million and as high as $4 million.
In addition to a histogram such as that shown here, Best Plan also discloses the most
likely combinations of wins. In this case, the most likely combination is to fail to get the
project DEF option, project GHI does not get cancelled, and all three competitions for
new work are lost. This combination has revenues of $3.1 million. Almost equally likely,
however, is the outcome where the DEF option is picked up by the customer and TEKR-US wins the project JKL competition. This combination has revenues of $3.7 million.
Strongly suggested by the results is that TEK-R-US should try to find more projects to
bid, else the year following the current planning cycle could be a very bad year.
The Best Plan Model provides additional information as well:

Revenues and costs by month due to project operations.

Staffing profiles by month by skill code for each active and anticipated project.

Material costs by month for each active and anticipated project.

Profit and loss due to project operations by month and cumulatively.

The Best Plan model is a management tool to assist bidding and project management.
It is not intended to be an accounting model for the firm. Its concern is with the effects
of project operations.

Page 122 of 199

Chapter 18The efficient bidding frontier

Unfortunately, life is not always so simple that in competing for new work we will quickly
settle on a single technical baseline, a single programmatic approach, and a single
corresponding bid amount. What frequently happens in practice is that a firm will
generate two, three, or perhaps even more alternative approaches and will want to
compare them in one or more meaningful ways.
There are many ways to compare alternative approaches to the same project. There is,
however, an interesting and useful way most people never consider, and that is to think
of the project as a family of alternative investment opportunities. This requires
application of the principles of time value of money. There is more than one way to do
that, but most economists hold that the best of these is the net present value approach.
That is what we advocate here, but with a twist. The twist is adapted from the work of
Harry Markowitz, a famous economist and winner of the John von Neumann Theory
Prize and the Nobel Memorial Prize in Economics.
The approach is widely used in investment analysis, where risk and return are both
evaluated and used to make investment decisions, such as decisions to buy or sell
stocks. The approach has been little used in product / market decisions, such as
decisions to add or drop product lines, or, as we are interested in here, which of several
options to bid competitively. But it can have value in that context.
If you have analyzed each alternative approach to a particular bidding opportunity with
both the Best Bid and the Best Plan models, you will have, for each of them, a win
probability and series of values of net income (revenues minus costs) for each month of
the project.
Let the net income in month m be Gm. Also, let the firms cost of capital rate be r. Then,
the net present value of the cash flows is given by the usual formula:
NPV = all m Gm * (1 + r) ^ -m
For each alternative, we can convert NPV to an expectation by multiplying it by its win
probability, W:
ENPV = NPV * W
In investment analysis, it is also usual to consider risk. This is not the so-called
private risk associated with a project, such as the probability that the product will fail a
critical test. It is the so-called public risk associated with the investment, typically as
measured by its volatility in trading. The usual measure is the standard deviation of its
price over time.

Page 123 of 199

That type of volatility is not appropriate to a decision as to which of several bidding
options to go with, because there is no time history. But there is another type of
volatility that can be of interest. Recall now the following paragraph from the preceding
chapter:
Because of the nature of the labor force in the advanced contracts business, a primary
goal of most re-planning is to achieve stabilization of the labor force insofar as possible.
Indeed, many advanced contracts firms treat this stabilization as a goal secondary only
to the overall profitability of the firm. In some cases, immediate profit gains are
sacrificed for the sake of stability, on grounds that stability will enhance longer term
profits. Planned schedules are sometimes modified for the same reason.
If we want to pursue stabilization in bidding, we can do so by minimizing the volatility
among the alternatives we are looking at. We can arrive at an expectation of volatility
using the following formula, which is based on the standard deviation.
EVOL = NPV * sqrt(W * (1 W))
At first glance, we can always minimize volatility by bidding the alternative that has the
highest win probability. But this ignores the quality of the projects won and could lead to
poor results over the long run. ENPV is a reasonable proxy for quality, so how do we
choose between values of quality and values of volatility?
Here is where Harry Markowitzs concept of an efficient frontier comes into play. From
here we will proceed with a numerical example to make clear what is being done.
Suppose that a hypothetical firm TEK-R-US is looking to bid a new project and has
developed four alternative approaches with the following results:
Option
1
2
3
4

Bid W% ENPV EVOL

4786 31 55.25 82.43
4929 30 67.63 103.31
5080 27 74.17 121.96
5232 21 68.43 132.72

We proceed now to make a cross-plot of ENPV

versus EVOL. The result is depicted below.
Note that the plot has a fold. The part of the
plot below the fold is called the efficient frontier.
You would not want to make any bid above the
fold because below
the fold there is
another bid of equal
ENPV and lower
volatility.
The bid of 5080 has
the highest ENPV,
but also the highest
volatility of any bid on
the efficient frontier.
This is typical. The
bid of 4786 has the

Page 124 of 199

lowest ENPV, but also the lowest volatility. The efficient frontier approach has two
benefits:

It clearly shows certain options we would most likely never want to pursue.

Of the options we might want to pursue on the efficient frontier, it clearly shows the
tradeoff between risk and return, with risk being understood not as risk associated
with possible problems during performance, but as a risk to bidder financial stability
that is assumed from bidding high in a competitive environment.

A natural question to ask is what is the best point below the fold? The efficient frontier
view does not answer this question. However, the Best Bid model does.

Page 125 of 199

Appendix A--Be all that you can be

Most of this book is about the best things to DO in the pursuit of new projects. This
appendix is about the best things to BE and how to become them. Many observations
are offered about the quality and the capabilities of the pursuit and project teams,
because they are the ones whose performance will largely determine whether the
project is successful. Also offered are example implementations that can be used as
templates for organizing project activities.
These are the major topics covered in this appendix.

Developing better processes.

Robust teams.

Developing better processes

The project plan for a new project typically includes estimates of cost and duration
based on historical experience. If the historical experience includes waste (and it
typically does), then some percentage of waste is automatically built into the estimate
for the new project. More likely than not, the waste built into the estimates will recur in
the current project if steps are not taken to eliminate or reduce it. Waste forces up the
bid amount, reducing win probability if competitors have better processes. That is the
best argument for having efficient processes.
Estimates based on history dont reveal to us the amount of waste they contain. There
is hardly ever a metric of how much waste can be eliminated. A waste reduction effort,
like a risk mitigation effort, must begin with discovery.
Waste elimination may or may not directly reduce risk, but it reduces the base to which
risk is applied. The expected impact of risk may thereby be reduced, and the probability
of project success may be improved.
The modern tool of choice for waste reduction is called process management, process
re-engineering, and various other names. Several schemes for process management
have achieved recent fame, including Six Sigma, and the more recent Capability
Maturity Models Integration (CMMI) developed by Carnegie Mellon Universitys
Software Engineering Institute (with input from others) for the U.S. Department of
Defense.
The modern trend is continuous or at least stepwise improvement of processes.
Process improvement is necessary if your competitors are doing it, and many of them
are. For example, in the software development industry, many companies are in the
process of raising themselves to higher CMMI levels. The CMMI approach calls for
improvement over six levels (0-5) ranging from chaotic, with no processes, or poorly

Page 126 of 199

defined and executed ones, to optimizing, where processes are well established,
documented, rigorously used, and improved at every opportunity.
Process management is a tool for reducing waste in business operations. Waste in
U.S. companies has been estimated to be on the order of at least a trillion dollars a
year, with waste in government perhaps half or more of that. Many advocates of
smaller government would claim it is much higher. Some of this waste can never be
eliminated, but experience shows that with effort much of it can be.
Unfortunately, waste is often blindly accepted until someone notices and points it out.
Some common wasteful situations are:

Scrap and rework.

Poor yield in manufacturing processes.

Excessive span of product design cycles.

Unnecessary, non-value added tasks.

Bureaucratic overstaffing.

Poor communication.

Allowing unnecessary vulnerability to accidents or disasters.

Unnecessary duplication of activities.

Non-competitive salaries, wages, bonuses and benefits.

Lack of discipline in the workplace.

Poor maintenance.

Customer returns.

Can we identify specific root causes of waste? If we could, we might be better prepared
to foreclose wasteful situations before they occurcatch them early, and eliminate them
before they take root and grow. Here are some root causes which have been cited by
various authorities.

Complexity. Any reliability engineer can assure you that the more complex you
make a machine or a system the more likely it is to fail. Failure, of course, is a form
of waste. Complexity almost always adds cost, also. A good design principle to
follow is, make it as complex as it needs to be, but not a bit more.

Page 127 of 199

Precision. Precision is a good thing where it is needed, but a waste where it is not.
A very common form of precision abuse is when we specify or demand tolerances,
finishes, or features which are much more than needed. Sometimes it is difficult to
determine just how much precision is needed. One aspect of that issue is examined
in Appendix C.

Variability. It is generally accepted that a certain amount of variability in a product or

system is acceptable. The alternative would be to demand perfect compliance in all
measures, a state which is not achievable. Past certain boundaries, however,
variability can have a measurable cost. This cost is a waste.

Sensitivity. Sensitivity is the ability to respond to stimuli. Like precision, a certain

level of sensitivity can be a good thing. Too much can be wasteful.

Immaturity. A major source of waste arises in attempts to introduce immature

technologies into products. This has happened quite frequently in military and space
projects, less so in commercial projects.

High skill. Excessive complexity frequently creates a need for high skills that would
vanish if the complexity did. High skill requirements generate a need for training,
which can be expensive.

Danger. Hazards of all kinds are a frequent source of waste due to injuries and
illness.

Waste elimination is not a one-time process. A project completely purged of waste

(even if that were possible) eventually will pick up wasteful habits absent constant
vigilance.
Much of waste is due to that seemingly inevitable product of bureaucracy, i.e., in either
industry or government the development of functions and policies for the benefit or
convenience of incumbent groups, usually associated with erection of barriers or "walls"
that separate various functions from each other. The bureaucracies become isolated
and fail to recognize what happens to a product or service outside their domain. The
result is waste.
Conventionally, a project is viewed as a set of organizations performing certain
functions aimed at particular goals. In this view, the project is the totality of the
organizations and their functions. While it is possible for organizations acting
individually to find and eliminate waste within their own boundaries, waste that occurs
across organizational interfaces is substantial, and is more difficult to find and eliminate.
To attack this waste, it is useful to view the project in a bit different way, namely as a
collection of processes through which the necessary work gets done.
Process definition and characteristics

Page 128 of 199

A process is a set of interrelated work activities having particular inputs and outputs. It
also can be conceived as simply a method for doing things. If a project is to succeed,
the collective, cumulative value of the outputs of its processes must exceed the value of
the inputs. Chaotic processes (muddling through) may by luck lead to success, but
carefully designed and continuously tweaked processes are much more likely to do so.
All processes share three characteristics:

Conversion.

Feedback.

Repeatability.

A process converts the input to create the output. A conversion can be:

Physical (as in manufacturing or construction).

Situational (as in transportation or multi-location processes, or taking place in

different environments).

Transactional (as in banking or contracting).

Informational (as in data processing or training).

A process can contain more than one conversion, and may contain a mixture of the
above types.
Feedback refers to information used to regulate the process to maintain desired
characteristics of the output. It can be verbal information, or it can be an economic
indicator such as revenue. Continuous or frequent feedback is needed to avoid
degradation of the process.
Repeatability implies that a process operates more than once. Some processes repeat
continuously; others are intermittent. Repeated processes should yield consistent
results at each repetition. A plan not intended to ever be repeated is not generally
considered a process. Thus, a project is by definition not a process, but within a project
a number of processes may be needed.
Many processes cross one or more organizational boundaries. These are known as
cross-functional processes. For example, change order management in a large
manufacturing project usually is a cross-functional process. The more complex a
process, the more prone it is to failure or degradation. Any change that simplifies the
critical processes of a project will generally be a good thing, all else being equal. This is
especially true of changes that eliminate organizational boundaries and flatten the
organizational hierarchy.

Page 129 of 199

All processes have some degree of conversion, feedback control, and repeatability, but
only well managed processes will have the following properties:

Clearly defined ownership. The person or team responsible is clearly identified, and
can be judged on performance.

Defined boundaries. Everyone involved understands where the process begins and
ends.

Documented work flow. Everyone involved has access to clear process descriptions
such as flow charts, assembly drawings, or routings (descriptions of operational
steps).

Established measurements. A numerical or statistical basis has been established

for controlling flow of the work and managing variation.

Control of process deviations. Timely corrective action based on measurements will

consistently be used to control variations in process output.

While the concept of process management has made considerable inroads into
manufacturing, many services and support operations are still are not managed from a
process point of view. Exhibit A-1 illustrates typical differences.
Exhibit A-1Typical Differences between Manufacturing and Service Processes
Features
Ownership
Boundaries
Documentation
Measurements
Deviation control

Manufacturing
Clearly defined
Clearly defined
Well documented
Consistent; quantitative
Consistent; based on data

Service & Support Operations

Undefined or unclear
Undefined or unclear
Little or no documentation
None or qualitative
None or infrequent; gut feel

The result of failing to properly manage a process is that it goes out of control. It
becomes unpredictable, costly, and unprofitable. Its effectiveness is unknown.
Reaction replaces management.
We now turn to the creation and improvement of processes. The steps we will examine
are:

Process initiation.

Process definition.

Establishing process control.

Page 130 of 199

Process analysis and evolution.

Process optimization.

Process initiation
The two key actions needed to establish a new process are establishing ownership and
establishing boundaries. Why is it necessary to establish ownership? In today's project
environment, the most critical processes are usually cross-functional. Ownership can
easily be ambiguous. Lack of accountability paralyzes action to correct problems, and
makes for inefficiency, poor morale, and dissension among team members.
Ownership implies responsibility and accountability for a set of operations. A process
owner is accountable for the functioning and performance of a process and should have
the authority needed to change it.
In the case of cross-functional processes, ownership issues are likely to arise unless
they are settled from the beginning. There are no universal rules for resolving such
issues. Each must be resolved on an individual basis. If ambiguity exists, sometimes
the best solution is for a senior or dominant personality to assume ownership until
ownership can be resolved by consensus, or referred to senior management for
resolution. This sometimes less than optimal ad hoc solution is generally better than
leaving a critical process without ownership.
A commonly used rule of thumb in determining ownership of a cross-functional process
is to name the manager who has the most resources invested in the process.
Alternately, name the manager who will feel the most pain if things go wrong, or who is
doing the most work in the process.
The process owner of a cross-functional process should be at a high enough level in the
organization to see the process as part of the larger operational picture, to influence
policy concerning the process, and to commit to a plan for process improvement. The
owner is accountable for the process from end to end.
The most difficult ownership assignments are in complex, decentralized projects, with
several hierarchical levels. To complicate matters, such projects often have duplicate
functions at different locations. The easiest ownership assignments are in simple, flat
organizations. This, by the way, is one of the best reasons to flatten an organization -- it
greatly simplifies the management of cross-functional processes, or may even eliminate
some cross-functional boundaries. As previously noted, cross-functional processes
usually have the most waste.
Process boundaries mark the beginning and the end of the process. For example, the
accounts payable process may start with receipt of an invoice (input) and end with the
mailing of a check (output). Boundaries must be clearly defined to avoid ownership
conflicts.

Page 131 of 199

An interface is an internal transition point where the work leaves one organization and
enters the next. Note that process boundaries can be interfaces where two processes
join.
Interfaces are critical. Many problems relating to work flow occur at interfaces. Most
problems at interfaces are caused by failure of communication across the interface.
The process designers must be especially careful that the design is strongest at
interfaces. Creation of unambiguous channels of communication is critical.
Probably the single best tool for strengthening communication across an interface is a
memorandum of understanding (MOU), jointly signed by the leaders on either side of
the interface, and by the process owner. The MOU should detail the requirements of
the receiving organization ("customer"), and should identify the value-added activities
that will be performed by the receiving organization. It is also wise to state what will be
done in unusual circumstances, such as process failure.
If requirements of the receiving organization are simple, a word description of them is
adequate. If they are complex, other means of communication may be necessary, such
as specifications, attribute lists, or flow charts. In the most complex situations,
responsibility matrices can be used, as illustrated in Exhibit A-2. A situation that often
arises, especially in manufacturing, is that several inputs from different departments
cross an interface and simultaneously enter a particular activity in the receiving
organization. Here, a responsibility matrix is especially useful. An example is shown
below for part of an overhead rate setting process. If desirable for improved
communications, the intersections of a responsibility matrix can be expanded to include
short text rather than just Xs.
Exhibit A-2--Example of Responsibility Matrix
Input Required
Indirect labor hours
Direct labor hours
Absent hours
Sick hours
Capital budget
Maintenance hours
Computer usage hours

Mfg
X
X
X
X
X
X
X

Engrg
X
X
X
X
X

Finance

Process definition
Once a process has been initiated, it must be defined. Process definition should
provide means to understand and communicate its operational aspects to all involved.
It also should provide a baseline, or standard, for evaluating improvement.
When work activity procedures are simply word of mouth, or when they reside in
obsolete or obscure documents, activities tend to be little understood by participants.
Lack of understanding is highly conducive to waste.

Page 132 of 199

How can an understanding of processes be communicated? In manufacturing, routings

and operation sheets are in common use. A word description is adequate for simple
processes. Almost every process can benefit from a flow chart.
Whatever documentation is used to define it, a process must have a baseline. The
baseline fills in the details of how the process works in practice. Subsequent changes
to the baseline establish new baselines, which must be reflected in revised
documentation. Establishing the baseline comprises three activities:

Within the outer boundaries of the process, establish interior boundaries containing
activities. Some interior boundaries may coincide with interfaces, and some may
not. These boundaries are natural breaks in the work flow.

Define inputs and outputs for each activity. To describe these, a simple activity
definition is helpful.

Create the word descriptions, routings, operation sheets, flow charts, or other
documentation needed to clearly communicate the activity.

Establishing process control

Three activities are important in process control:

Establishing control points.

Measuring.

Feedback and corrective action.

Control points are steps in the work flow associated with actions such as checking,
inspection, auditing, physical measurement, or counting. Without control points, a
process becomes reactive, as opposed to controlled. The only feedback is from the
ultimate customer. Waiting for customer feedback in projects can risk damage to the
reputation of the project team. If it involves field recalls or replacements, it can become
very expensive.
Generally, there should be one control point for each activity, but there can be
exceptions. Use good judgment.
Process measurements mostly fall into one of five types:

Conformance.

Response time.

Service level.

Page 133 of 199

Repetition.

Cost.

Conformance measurements involve an inspection or verification as to whether the

work product or service meets a specification or other set of requirements. Implicit in
the measurement is the notion that something of direct or indirect value to the customer
is being measured. Otherwise, the measurement is a waste of time and money. (Note:
Customer in the sense the word is used here does not necessarily mean the overall
project customer. It could refer to the owner of a process that receives work product
from another process.)
Response time is the time (delay) needed to deliver the product, measured from arrival
of the request until completion of the service, or, from start of performance of the
service until completion. For some services (e.g., delivery of material) response time
may be crucial. For product development, a critical time is the overall time used to
complete the development, also called cycle time. Many administrative tasks also can
be measured in terms of cycle time (e.g., patent searches, end-of-period closing of the
books, SEC filings, customer order delivery, etc.).
Service level means the percentage of times a service or facility is available to a user at
the time service is requested. It also means the percentage of times a needed item will
be in stock. If a computer is down for maintenance 10 percent of the time, its service
level is 90 percent. If a certain spare part is unavailable for 5 percent of the requests for
it, its service level is 95 percent. Be aware: it may not be not possible, or even
desirable, to achieve a 100% service level in a process. Unless human safety or life is
at stake, a 100% service level may be prohibitively expensive.
Measures of repetition involve the frequency of occurrence of an activity. Examples are
the number of times a training manual is redone, and the average number of changes to
engineering drawings.
If an item is purchased, cost usually refers to its purchase price plus a fair share of any
other costs required for bringing it to a useful state, so that value can be added to it, or it
can be used to add value to something else. If an item is produced, cost usually refers
to all money paid for direct labor and material, plus a fair share of cost of all activities
related to the production. Both of these costs are important to process analysis, and
both should be measured.
Process management focuses on waste. Costs should be carefully scrutinized for
waste. In the case of manufactured or constructed products, waste can come from
careless specification of materials, processes, finishes, or dimensions. Detection and
correction of this type of waste is the province of value engineering. It is best done by a
value engineering specialist. A more overt and easily detected type of waste is that due

Page 134 of 199

to poor quality. A useful concept for organizing the search for this type of waste is the
cost of quality. Quality costs are traditionally divided into three major elements:

Failure or nonconformance costs.

Appraisal costs.

Prevention costs.

Failure costs are those directly related to not meeting requirements. They can be costs
of correcting defects, costs of scrapped material or wasted labor, or warranty claims.
Appraisal costs are costs related to detecting nonconforming work, including inspections
and audits.
Prevention costs are costs related to preventing future occurrences of nonconformance.
Process improvement costs are usually prevention costs. Typically, investments in
prevention are small relative to costs of appraisal and failure. Often, the project team
will be able to demonstrate convincingly that a preventive measure will have a very fast
payoff in terms of reducing failure or appraisal costs. If such a demonstration is not
possible, often a relatively inexpensive test can be designed to determine
experimentally whether or not a suggested improvement will have a payoff.
Measurements must be meaningful, timely, accurate, and useful. Any proposed
measurement not having all of these attributes should be rejected. In the selection of
measurements, the following steps can be helpful:

Determine what is to be controlled. Begin with the critical success factors of the
process.

Examine existing databases for measures currently available. It is easier (but not
always better) to use existing data or data already being collected rather than
create something new.

If nothing is available now, determine whether a case can be made for new
measurement tools.

For the type of measurement to be made, determine an appropriate sampling

method, sampling size, and measurement frequency. The possibilities range
from measurement of every item or instance to sophisticated sampling
techniques. Most sampling situations are not sophisticated and reasonable
sample sizes can be determined by elementary methods.

An outline is given in Exhibit A-3 for a process measurement chart. This is a useful
accompaniment to a process flow chart (Exhibit A-4).

Page 135 of 199

Exhibit A-3--Process Measurement Chart Outline
Process step
Control parameter(s)
(Activity Name)
A1-Document
Document defects
inspection
-Missing
-Illegible
-Out of sequence
A2...
A3...

Unit of measure

Frequency

Percent of total
errors by category

Every job
(100%
inspection)

Exhibit A-4Example Process Flow Chart

Process Flow for Production of Internal Training

Documents
Certify need for
internal training

Create course
syllabus

Review and
approve syllabus

Rejected

Approved

Publish course
documents

Syllabus

Approved

Documents
Rejected

Inspect course
documents

Draft course
documents

Measurements can usefully be presented in graphical time series format, and the target
or control limits should appear on the graph. A graphical format is easily read and
understood by everyone. See the example in Exhibit A-5.
In keeping with the spirit of continuous process improvement, the technique of
ratcheting targets is highly recommended. Target ratcheting involves periodic
reassessment of actual defect or failure data in comparison with its target or objective
values. When actual results are consistently achieving or bettering targets over a
period of time, the target is adjusted to a more difficult level. In this manner, new goals
are set periodically. Targets may be derived from physical capability studies,
benchmarking, or traditional competitive comparisons.

Page 136 of 199

Exhibit A-5Example Process Output Tracking Chart

Control Chart for Internal Training Document

Production
Total
Defects per
1000 words

Goal

Thousands of words
published

How can feedback and corrective action be accomplished? The process owner is
responsible to see that feedback occurs and that appropriate action is accomplished.
Probably the best feedback is a graphical time series chart as previously noted.
Feedback should be presented constructively, not in a punitive or threatening manner.
If feedback is viewed as a weapon or a punishment it will be resisted.
Determination of corrective action is best done as a consultative group process. The
people closest to the work can see the best changes to make, but their ideas need to be
tempered by the broader view available to the process owner.
Process analysis and evaluation
Process analysis is a systematic examination of a process with a specific objective in
mind, such as reducing cost or cycle time, or otherwise improving the process. To
facilitate the examination, flowcharts should be made if they do not exist.
The process is first assessed and then opportunities for improvement are evaluated. If
the proposed improvements are accepted by management, they are implemented. This
seems straightforward, but it is fraught with opportunities for error, misunderstanding,
and dissatisfaction of all concerned. Change can be a hard thing for people to accept.
The first cardinal sin of process analysis and evaluation is to get too far ahead of your
customer or your management, i.e., to press urgently for changes whose potential
effects they do not yet fully understand and accept, or which appear to go against their
culture or business goals.

Page 137 of 199

Change agents in a project must always be extremely sensitive to clues that a process
assessment is about to tread on sacred ground. Nevertheless it is possible that a
recalcitrant manager, for purely personal reasons, will stand in the way of a change that
cries out to be made. If such a manager cannot be swayed by facts, statistics, or even
experiments, it will be necessary to try to go around or over him or her. However, the
change agent should proceed by "indirection" whenever possible. Pressures on the
obstinate manager should come from colleagues or superiors, not from the change
agent.
In going around or over an uncooperative manager, the change agent must keep in
mind the second cardinal sin of process analysis and evaluation: it is to criticize an
uncooperative manager to his colleagues or superiors. On the contrary, an
uncooperative manager should if at all possible be praised for "help," "useful insights,"
and for making his or her "valuable time available."
The initial stage of process analysis is to ask questions, much as a news reporter
would, but certainly not in the overbearing and aggressive style adopted by some
reporters. Typical questions are:

What is the activity?

What is the purpose of it?

Why is it done?

What would happen if it were not done?

Is every part of it necessary?

Who does the work?

Why does this person or group do it?

Could people of lesser skills do it; could it be automated?

Where is the work done?

Why is it done there?

Could it be done somewhere else faster or at lower cost?

When is the work done?

Could it be done better at another time?

How is the work performed?

Page 138 of 199

Why is it done this way?

Can it be combined with other work or otherwise simplified?

Process optimization
Not surprisingly, there is considerable interest in optimizing processes, that is, making
them as good as they possibly can be. This is a complex issue. Among the many
questions that could arise are:

What processes are needed to get the work done?

How many different ways could we structure these processes?

What would be our criteria for saying a process is the best? Cost? Productivity?
What?

If we optimize one process, could that make others worse?

The week these words were written, a news article appeared explaining how some
companies had inexpensively optimized certain processes using some recently evolved
mathematics called complexity theory. For example, one airline hired some bright
mathematicians headquartered in New Mexico to find a way to optimize certain
baggage handling operations. The claim was made that for a one-time expense of only
$60,000, the mathematicians were able to shave a couple of million dollars off the
annual costs of baggage handling. The article went on to predict a bright future for
complexity theory in process optimization, or at least in process improvement.
The authors tend to agree that complexity theory may eventually be a big help in this
regard, especially in commercial operations where large scale processes work more or
less independently of other processes. We are not so sure about processes in projects.
Some project oriented organizations design processes in accordance with agreed
standards such as CMMI. If this is a customer expectation, they must do so to be
considered in bidding competitions. For example, in certain software development
competitions for U.S. Department of Defense contracts, it is considered de rigueur to
have achieved at least level 3 in the CMMI scheme and to be officially certified at that
level via a formal audit process.
A concern is that there are so many rapidly changing variables in project process
evolution that the human brain will for the foreseeable future be the best tool for sorting
out the best way to structure project processes. Processes often change from one
project to the next, partly because the skills and aptitudes of the pursuit/proposal team
(PPT) are not long-term stable.
Still another concern is the dynamic pursuit and project environment. Whenever you
trade off design options to find the most competitive approach, you necessarily also

Page 139 of 199

trade off some possible processes. One design approach may work poorly within a
certain process but work very well indeed with a different process. Moral to this story:
Before you reject an otherwise seemingly good design for reasons of process difficulty,
look first at the process to see if it can be improved.
Here are some more or less random thoughts on project process optimization:

The best processes we can think of may lose in bidding competition because we
failed to choose a minimal balanced design approach. Efficient processes are only
part of the competitive mix. The same airline that hired the bright mathematicians to
optimize its baggage handling was, a couple of months later, struggling to avoid
bankruptcy.

In estimating project costs, we frequently do not explicitly consider many process

costs. For example, the estimates to develop, say, an aircraft wing may assume that
certain traditional ways of doing things will be observed. When we consider cost
reduction attempts, we want to look at more than just savings in materials and
fabrication machine and assembly time. We also want to consider if the processes
themselves can be simplified.

The best tool for project process optimization today and for the foreseeable future is
probably the brains of the team members who will do the work. They are closest to
the work and if given opportunity and incentive will always be alert for better ways to
do it.

A standard such as CMMI is helpful in promoting process improvement. It also

provides useful guidance for determining where processes are most needed, and
what should be considered when trying to improve them.

A final thought on this subject. The mathematicians who found the baggage handling
improvements for the airline began by interviewing the people involved in baggage
handling to find out what they were actually doing. One of their findings (surprise!) was
that what the people were doing did not match what senior management thought they
were doing. The de facto process was different than the de jure process in several
ways. Some of the changes in the process made at lower levels seemed good to the
people who were doing the work, but were not optimal in a larger sense. That most
likely was because the lower level people did not have 1) an understanding of the whole
system, and 2) an understanding of what the things they used such as labor, buildings,
equipment, etc., truly cost. Those failures to see the bigger picture are perhaps
understandable in an airline, even a very progressive one, where not many people are
able or encouraged to become experts on corporate operations and cost analysis.
Such failures are much less understandable in the bidding and performance of high tech
or complex projects, where most people are highly educated engineering or scientific or
finance professionals, or at least highly skilled technicians. A significant barrier to
process improvement in advanced projects occurs when PPT managers try to build

Page 140 of 199

overly high walls around this kind of information. There are good reasons to keep such
information out of the hands of competitors, but it is folly to protect it from people who
should be trusted members of the core project team. Good decisions come from good
information. Better decisions come from having more than one brain process the
information.
Robust teams
Robust pursuit/project teams (PPT) and excellent processes are a hard combination to
beat. But hiring from among the magna cum laude recent graduates does not
necessarily make a robust team. Neither does a collection of PhDs necessarily make a
robust team. A team must be shaped for proficiency in the PPT environment, and for
the type of work that needs to be done.
A common and recommended practice is to use only the very best available people in
pursuit teams. In some organizations these people are called technology superheroes
or sometimes graybeards, although not everyone with gray hair is a superhero and
vice versa. In many organizations, pretty much the same people pop up over and over
again in pursuit teams. This is mostly to the good, if they have a winning record. The
only downside appears to be that service in pursuit teams can be stressful, and
occasional burnout is a hazard.
Pursuit teams are typically quite small compared to the project teams that are
assembled when the project is won. An excellent practice is to have some members of
the pursuit team move into the project team to maintain organizational memory and get
the project off to a solid start. The other pursuit team members then return to other
project pursuits, internal research and development, or other tasks worthy of their skills.
With the understanding that the pursuit team generally has a higher average level of
competence than the project team, our remaining remarks in this appendix will relate to
both teams under the title PPT.
Much subjectivity and speculation surrounds the subjects of PPT efficiency and
leadership, but we believe that a robust team has and is defined by a high level of each
of these four qualities:

Competence.

Dedication.

Tenacity.

Plan awareness.

Competence

Page 141 of 199

The usual image invoked by the word competence is knowing how to do the job. In a
truly robust team, we can go beyond that simple image. Lets explore just how far we
might go.

Expert status. Most team members are expert and current in at least one discipline
necessary to the success of the project. Those who are not should be mentored by
a team member who is. In a robust team, inexperienced people are not placed in
charge of nor do they play a major part in critical activities without close supervision.

Multi-disciplined. Most team members are significantly competent in more than one
discipline. This parallels the notion, once popular in management circles, of the Tshaped man.18 The T-shaped man was supposed to have great strength in one
discipline, but to also have broad knowledge of other disciplines as well. The multidisciplinary approach is central to the way crews are trained in the U.S. Navys
submarine fleet. Every crewmember, of whatever grade or rank, must have a key
skill, and if that skill is weak, an expert mentors him.19 In addition, he must have
broadly based knowledge, but not necessarily high expertise, in all of the key
systems of the ship and their operation. For example, an electronics technician
must have some knowledge of the torpedo tubes and how they work. A
quartermaster must understand how the ships buoyancy system functions, and so
on. This mode of operation enables submarines to survive in a hostile environment.
Because they operate in a stressful environment, submariners get extra pay, which
is a good idea for all robust project teams that do outstanding work.

Know what they know and what they dont know. The idea here is that team
members live examined lives, following Aristotles dictum that the unexamined life is
not worth living. They have looked within themselves and they know their
capabilities and their limitations. They are realists. They are immune to hubris, yet
they approach their work with confidence. They are balanced and wise. Even if
young and energetic, they are mature yet creative in their thinking, more so than the
average adult.

Know what their teammates can do. In a robust team its crucial that team members
understand the capabilities of their teammates. On a football team, the coach is
expected to have a firm grasp of the capabilities of each team member, and to use
each team member to best effect. But a truly robust team goes furthereach team
member must understand what the other team members can do, and what they
cant. In critical projects, the coach cant be everywhere. When a problem arises
that a team member doesnt know how to handle, he or she should be able to

18

Please forgive our lapse into not-so-gender-neutral writing. When the T-shaped man concept originated,
apparently in the early 1960s, almost all managers were men. Incidentally, the (male) author of this book cant help
but wonder how many women would object to being called T-shaped even in a complimentary sense.
19
Despite appearances, this is not another lapse into not-so-gender-neutral writing. As of this writing, U.S, Navy
submarine crews are strictly male. Most other classes of U.S. naval vessels now have women in their crews.
However, in a recent announcement, the U.S. Navy is studying the possibility of billeting women (officers only for
now) on U.S. submarines. Your authors is a former submarine sailor. In his opinion this will be interesting, to say
the least.

Page 142 of 199

quickly find the needed expertise. This short-circuits the delay of passing
information through the coach that he doesnt need to have, or may not be available
to give.

Fast execution. Have you ever watched a professional baseball team do its warmups? Its like watching a ballet. The motions have a fluid quality as the ball goes
from player to player. With seemingly no effort, the players move the ball around
with blazing speed. Fast execution can also be important in some projects. They
are the projects where schedule is critical, where waiting a day for a memo wont get
the job done, where every day that passes makes life more unpleasant for some of
the stakeholders. Fast execution comes from practice at working together using well
learned and efficient processes.

Dedication
Another name for dedication is team spirit. At its center is the notion that team
members think the project is important to them personally. They are therefore willing to
give it a high priority in their lives, and to work enthusiastically to achieve its ends.
Dedicated team members dont just show up for work and do the minimum expected.
They have a degree of emotional involvement. They have fervor. They struggle to
achieve the best possible outcome for the team, believing that outcome will also be best
for them.
Dedicated team members do not build silos. Silos are artificial organizational barriers
that obstruct the full and open flow of information around and across the team. Creation
of silos is the beginning phase of future turf wars based on ownership of certain
functions, and creation of walls around the information they contain. Silos prevent free
and open communication between team members. They create bureaucratic barriers to
getting things done. Silos inhibit fast execution, while people wait for the paperwork to
get done.
Tenacity
Competence and dedication may get you an assignment on a robust project team, but it
is tenacity that will keep you there. The pursuit and project environments are often
stressful. For example, in the world of software development, getting the product to
market quickly is sometimes deemed to be the only success factor. These rapid
development projects are sometimes called death marches. It is famously said that
you can tell its a death march project by the number of empty pizza boxes you can see
in the project offices at two oclock in the morning. Team members must be tenacious
to survive in this environment. Of course, being well rewarded tends to make them
more tenacious.
Plan awareness
To have any hope of achieving fast execution, it is vital that all team members be fully
aware of the current plan and their role and current situation in it. If they are not, news
of a new plan is likely to result in confusion. Therefore there must at the outset be a

Page 143 of 199

process for making team members aware of the plan and their role and status, and this
process must be sufficiently robust that changes dont fall through a crack.
Plan awareness is more than just being aware of what is going on in the immediate
neighborhood. It is also being aware of the other players in the project, especially the
ones who owe you input (your suppliers), and also the ones to whom you owe output
(your customers). Are your suppliers holding to the plan? Will you be able to hold to
the plan given the situation of your suppliers?
Plan awareness requires demolition of organizational barriers to communication. The
project must be regarded as a mission whose completion is vital to the entire team. The
team attitude must be Its the mission, stupid!
Plan awareness requires full knowledge and understanding of changes in the plan. This
further requires that changes be communicated crisply, much as a drill sergeant
communicates changes in direction to a marching body of troops. Pursuing that
analogy a bit further, we have all seen movies (or perhaps have personally experienced
the situation) where green troops fall all over themselves when being drilled because
they are unpracticed in understanding the meaning of the commands and responding to
them. A few weeks later, after repeated drills, the same troops implement the same
commands crisply, with precision and pride. If the project team is to implement changes
crisply:

The changes must be communicated clearly in a command language that the team
understands.

The team must have experience in responding to changes ordered in the command
language, so that they respond virtually by reflex action.

A PPT is not a body of troops, and the small number of commands that a drill sergeant
needs to move his troops where he wants them is not sufficient to direct changes in
most project teams. In a very complex project, especially a high technology project, the
development and communication of changes in the baseline design might require hours
of meetings, poring over drawings or computer printouts, scribbling on a white board,
and consultation with subject matter experts. In this context, how can there be anything
resembling a crisp command language?
Having attended many such meetings, having pored over drawings and computer
printouts, scribbled on white boards, and consulted with subject matter experts in
stressful environments, we can answer that question in this manner. When all is said
and done and a consensus is reached as to how the plan shall change, the PPT
manager (or if necessary his high level designee), using a consistent process created
for this explicit purpose, records the changes to be made in the plan. This record
should indicate or provide for, as a minimum:

Clear identification of existing tasks that are affected.

Page 144 of 199

Any new tasks created.

Changes in budget for affected tasks.

Changes in planned duration of affected tasks.

Changes in the length of the project critical path.

A description of product design changes with respect to the previous baseline.

Immediate issue of the related documents to the entire team, or at least to the team
leads, using the teams most reliable communications channel, or better yet
redundant channels.

Response from the team that acknowledges both receipt and immediate compliance
(compliance problems, if any, must be cited in the response).

Why is this a responsibility of the PPT manager?

o The process ensures that the PPT manager understands and has sorted out the
full impact of the change, avoiding possible confusion at the top level of the
project when pieces of the change come up from below as possibly conflicting
recommendations. To initiate the process, the PPT manager or designee must
personally explore the logic of the change and all certain and likely
consequences so he can communicate them clearly to the team.
o Universal and immediate acceptance by the team is likely when the changes are
issued directly by the PPT manager or other high level person of recognized
authority. The process becomes a familiar command language that the team has
been trained to understand and respond to quickly.

Why not use standard change board procedures?

o There is nothing inherently wrong with such procedures, but they may be too
slow for critical projects.
o Typically, ordinary change board procedures are more oriented toward technical
or logistical consequences of a proposed change; they may not adequately
address cost and schedule impacts.

What are some other advantages of this process?

o Fast and reliable communication of changes to the team.
o Assurance that compliance is happening.

Page 145 of 199

o Crisp execution of changes of baseline.

Should every change, even minor ones, use this process?

o No. If the change can be made within the scope of a team leads current
schedule and budget, and the lead is reasonably sure that his action will affect
only his area of responsibility, the change could be made without a formal
change notice issued by the project manager.

Page 146 of 199

Appendix B--Maintaining cost discipline

For some teams, creating an environment of cost discipline represents a distinct change
of culture. This appendix organizes and presents material your authors have used in
cost disciplined projects and in training teams for cost discipline over the years.
Cost discipline in design has gone under several names, such as design-to-cost, cost
as independent variable, target cost, etc. There are some differences in emphasis, as
pointed out in chapter 11, but this appendix attempts to capture what is common to
them.
We believe that there are two main issues in achieving cost discipline. The first is
creating an acute awareness among team members of what cost means in the project
context. Many team members have only the vaguest understanding of the concept and
why it is important. The second is an understanding of the many management issues
raised by attempting cost discipline, and how to deal with them. Accordingly, this
appendix has two sections:

Understanding the language of cost.

Management issues in maintaining cost discipline.

Understanding the language of cost

The U.S. Department of Defense (DoD) has taken many hits in recent years over poor
procurement practices. Moreover, there is a long history of cost overruns going back to
the 1950s. Sometimes it has seemed that the DoD couldnt do anything right when it
came to buying military systems.
This problem is not confined to DoD. It has also been a problem at NASA, at the FAA,
Homeland Security, and in many departments of state and local governments.
Design-to-cost (DTC) was one of the actions taken to deflect some of the criticism that
has come from Congress and elsewhere over expensive procurement practices.
Tailored procurements and use of commercial and standard components are others. As
this is written, many DoD procurements are based on little more than a statement of
need. The contractor has wide latitude in coming up with the most cost effective way to
meet the need.
At about the same time that DoD started to get serious about controlling its costs, the
world was in the midst of a quality revolution started by the Japanese. At the time, U.S.
industry as a whole was suffering from some of the same problems that afflicted the
defense industry. Aside from the quality issues, U.S. products often were not priced
competitively. That appears to have been due to a basic difference between the way
U.S. companies approached the market, and the way Japanese companies did it.

Page 147 of 199

Exhibit B-1 shows the typical U.S. approach at the time. Exhibit B-2 shows by contrast
the typical Japanese approach at the same time. Japan was then acknowledged to be
the most competitive country in the world. As this is written, that honor goes to the U.S.
We have learned a lot from those hard lessons in cost management.
Exhibit B-1(Old) U.S. Approach

Market
Research
Product
Characteristics
Design
Engineering
Supplier
Pricing
Cost
Yes

Too
High?

No
Manufacturing

Further Cost
Reductions

Both approaches began with market research to find out what customers want. The
research was used to establish product characteristics. Up to that point the approaches
are essentially the same. What happened after that is as different as black and white.
In the Japanese approach, subtracting the desired profit from the selling price the
market will bear yields a target cost. Thats the cost you have to make the product for if
you want to be in that business. To make it happen, design engineering and suppliers
work together concurrently to arrive at a product that meets both the need and the
target cost. Everybody on the team pitches in to help make it possible. The drive to
meet the target cost continues once the product is in manufacturing, in the form of
continuing cost reductions. Its not uncommon for a Japanese factory to plan routinely
for 5% annual cost reductions.
What a different picture we have in the old U.S. approach, which still lingers in some
product teams. The product is developed with little regard for cost. If it comes out too
expensive, its back to the drawing board until the team gets it right. Compared to the

Page 148 of 199

DTC/target cost approach, this process is wasteful and time consuming. It decreases
competitiveness by making products late to market.
A small clarification: Design-to-cost, target cost, cost as independent variable, etc. all
focus on cost. But what really interests the customer is our price. The customers cost
is our price. Strictly speaking, we should say design-to-price, target price, etc. This
mild ambiguity should cause no problems if we keep it in mind. Price includes the profit
we add to our cost. Cost is always a positive number, but profit can be negative (loss),
positive, or zero.
Exhibit B-2Japanese Approach

Market
Research
Product
Characteristics
Planned Selling
Price Less
Desired Profit
Target
Cost

Design
Engineering
Continuous
Cost
Reductions

Manufacturing

Supplier
Pricing

Target costs for each component force

marketers, designers, and engineers
from all departments and suppliers to
struggle and negotiate trade-offs.

The language of cost. Face it. Projects as discussed in this book are about
technology. The main idea is usually to create something that is faster, higher, or
smarter than what the competition has. In the final decades of the 20th century when
the U.S. was building the national debt at a furious rate and money was no object,
nobody except cost analysts cared about the language of cost. It was mostly boring
stuff, anyway, and there were so many exciting new ideas in technology, like composite
structures, tiny and very smart processors, stealthy airplanes, and exotic sensors.
Unfortunately, you can live beyond your means only so long. When the bills start
coming due a different lifestyle is in order. Well, they came due, and to some extent we
have changed our lifestyle. Cost is now a major factor in almost every project, and
sometimes it is not only as important as performance, it is more important. But not
every team has absorbed the message, and even if they have they dont always know
what to do with it.

Page 149 of 199

To survive in a cost disciplined environment, it is good to know something of the

language. Most readers will have encountered the words and phrases we are about to
survey, and many will have a good understanding of them. But its important for the
remainder of our discussion to insure that we all start marching by extending the same
foot. So we will take a brief tour through the language of cost. When we have
mastered that language we will feel more comfortable with some of the ideas we will
advance for managing projects under cost discipline.
Dollars and other currency units are a convenient way of measuring cost, but they alone
dont express its full meaning. The best understanding may come from the ancient
expression There aint no such thing as a free lunch.
Even if we were invited to a free lunch, ate our fill, paid no money for it, and assumed
no future obligations for it, it still wouldnt be a truly free lunch.
Why not? Somebody had to grow or find the food. Somebody had to prepare it.
Somebody had to make a pot to cook it in. Somebody had to supply the fuel to cook it,
and so on, and so on.
And didnt somebody have to invest time in learning how to grow or find food? And
make or buy the utensils? Didnt somebody have to dig up and transport and refine the
ore to make the metal from which the utensils were made?
The point is that costs at root are not really a matter of dollars, pesos, or euros, but
rather a matter of the use of resources. Costs in currency units are really nothing more
than a clever shorthand way of summarizing the use of resources so that every time we
need to know the cost of something we dont have to go back to square one and dig up
the detailed history of everything that went into the product.
To further support this view, here is a definition of cost published in the fall 1986 edition
of the Dictionary of Cost Estimating Terms and Phrases, published by the National
Estimating Society (now merged into the Society of Cost Estimating and Analysis).
Cost: The amount paid or payable for the acquisition of materials, property, or
services. In contract and proposal usage, denotes dollars and amounts exclusive of fee
or profit. Also with a descriptive adjective such as acquisition cost, product cost,
etc. Although dollars are normally used as a unit of measure, the broad definition of
cost equates to economic resources, i.e., manpower, equipment, real facilities, supplies,
and all other resources necessary for weapon, project, program, or agency support
systems and activities.
Cost inflation. If you won the lottery one day, you would probably thank your lucky stars
for suddenly becoming rich. But if you went out and bought a newspaper and found that
everyone in the country had also won the lottery, you might well go home and cry your
eyes out. Inflation is when everybody wins the lottery. Its when the government hands

Page 150 of 199

out more money to everybody. The problem is that everyone is now equally enriched.
So instead of asking $1 for your old slide rule in a garage sale, you ask $2. Everybody
else raises their prices too, so your newfound wealth is of no value to you.
Inflation is when the money supply increases, but the goods and services available
havent, at least not as much. Deflation is just the opposite, but historically it doesnt
happen nearly as often.
When we do business in projects that last over a year, we must consider the anticipated
effect of inflation in setting our bid. Most customers understand this and will
accommodate it. The U.S. DoD understands it so well that they regularly publish
expected inflation tables for various commodities to help you calculate the effects.
Inflation is also called escalation. The meaning is the same. It is generally measured
with index numbers. These are factors or percentages that measure the change in
price, value, etc. from some period of interest to another. Heres a simple example of
computation of an index number:
1988 hourly earnings / 1980 hourly earnings x 100 = $10.12 / $7.27 x 100 = 139.2
Products differ in their expected inflation rates. To see examples of this refer to the
DoD inflation tables, or to the tables published by the U.S. Department of Commerce.
Theyre available on the Internet.
Prices to customers are virtually always expressed in so-called then year dollars, that
is, the effects of inflation are taken into account. But to keep life simpler and more
manageable, projects under cost discipline frequently keep records in base year
dollars. This means that the effects of inflation are not taken into account. The same
base year will be used for all project costs in any year.
But this does not mean you are totally freed from the curse of index numbers. You still
have to use them if you use historical data in a basis of estimate. You have to bring
them forward to the base year. Also, as the project moves out beyond the base year, all
new bids from subcontractors made in future year dollars must be backed up to the
base year. At the same time that you are maintaining a cost discipline estimate in base
year dollars, you also have to maintain a then year estimate for pricing purposes.
Normally, you also do cost risk analyses based on then year dollars, especially if
inflation is considered to be a risk. This can all get quite confusing if you are not alert or
dont understand what is going on.
Heres an example analysis that illustrates the application of inflation indices. Suppose
you have a total of $1.3 million in base year 2000 dollars. You want to spend this
money in the period 2001, 2002, and 2003, but first you need to determine an escalated
amount that takes inflation into account. The projected index factors for these years are
1.025, 1.031, and 1.033. Suppose that the expected cash flow profile in base year

Page 151 of 199

dollars is $650K, $380K, and $270K. The escalation calculations are shown in Exhibit
B-3:
Exhibit B-3Example Escalation Calculation
Year
2001
2002
2003

Base
Year K$
650
380
270

Calculation

Escalated
Cost K$
666.25
401.57
294.75
1,362.57

(650)(1.025)=
(380)(1.025)(1.031)=
(270)(1.025)(1.031)(1.033)=
Sum

Note: This method is only approximate but is frequently used because of its simplicity.
More accurate methods are available.
Learning curves. A learning curve is a curve that depicts the declining labor hours
required to perform a repeated task. For example, if a worker does a repeated task the
first time in 10 hours, he or she might be able to do it the second time (because of the
so-called learning effect) in only nine hours. The third time, it might take only 8 hours
and six minutes (8.1 hours). The fourth time he or she may be able to do it in 7.3 hours,
and so on. This is an example of a learning curve. We plot it in Exhibit B-4.

Hours of Work

Exhibit B-4Example Learning Curve

11
10
9
8
7
1

Repeats

Virtually all production that involves more than a few units is subject to the learning
effect (unless it is fully automated production and not subject to learning). This has
tremendous economic importance because every unit produced is cheaper than the last
one.
In projects under cost discipline, the correct application of learning curves is of critical
importance if more than a few units are to be produced. This is because the estimation
of first unit production labor hours affects the cost of all subsequent units. The choice of
learning rate (also called learning curve slope) has an even larger effect.

Page 152 of 199

Today, for many products the prime contractor is essentially an integrator and
contributes relatively little labor, perhaps less than 10% in some cases. Most of the
labor is performed by subcontractors. The significance is that the learning curve
calculations of suppliers may be of much more importance than those of the prime
contractor. Yet many prime contractor teams working under cost discipline never
inquire into those calculations and their reasonableness. This is an easily corrected
error.
Unlike inflation, learning effect is seldom ignored in cost discipline situations. Proper
estimation of first unit hours and assignment of learning rate can easily make the
difference between making the numbers and not making them.
Keep in mind that learning rates are typically highest on labor intensive work. For fully
automated work, learning may be zero.
As you delve further into learning curve theory, you soon learn that two distinct theories
compete for the attention of analysts. They are called the unit theory and the
cumulative average theory. Both, properly applied, can give good results. Neither is
inherently better than the other. As its name implies, unit theory applies learning
corrections to each unit produced. Cumulative average theory, on the other hand,
applies it to the cumulative average cost of some number of consecutive units.
Learning curve theory assumes continuous, uninterrupted production. If there is a
break in production for any reason, some learning is typically lost. Techniques are
available to make mathematical adjustments for lost learning.
Cost elements. The traditional elements of cost are labor, material, and other. The
usual definitions of these are as follows:

Labor. Wages, salaries, benefits and employer contributions to payroll taxes. (Note:
in some companies, benefits are called other costs.)

Material. Invoice costs of raw materials, components, subassemblies and

subcontracts

Other. All else, e.g., travel, facilities, utilities, postage, depreciation, consultants, etc.

These elements of cost probably derive from the economists traditional view of the
sources of wealthland, labor, and capital. Another view, now emerging, is that
information is also a source of wealth. At some point, cost analysts may have to
recognize costs of information as a separate category, but that day has not yet arrived
in most companies.
Direct and indirect costs. Generally, direct costs are costs directly associated with a
project. Indirect costs are all other costs. Indirect costs are also known as overhead or
burden costs. Normally, a company will recover its overhead costs by applying them as

Page 153 of 199

burdens on direct costs. The burden applied to direct costs is based on the ratio of
cumulative indirect cost to cumulative direct cost, usually applied equally across all
projects.
There are many exceptions to the general rule. In some companies, a contract
administrator is considered to be overhead even if he spends all his time on one project.
In the same company, a subcontract administrator may be considered direct, and
charge his time to ten different projects in the same day. Project managers are often
indirect even though they work only on one project.
Assignment of costs to direct and indirect categories varies widely from company to
company, and sometimes from division to division in the same company. The
assignments are virtually arbitrary, but once they are done, they may be essentially cast
in concrete, especially if a customer requires that the arrangements and all changes to
them be disclosed in all of their details.
It is important in cost discipline to understand what is regarded as direct, and what is
regarded as overhead. For one thing, there may be opportunities to reduce certain
costs by moving the work to subsidiaries or locations that have lower burden rates. It
may also be possible to organize certain work so that it is done by free overhead
people rather than by expensive direct people.20
Manufacturing overhead is often of high importance to cost discipline situations. It
generally is allocated partly to labor and partly to material. Subcontractors are typically
regarded as material. The labor burden is typically much larger than the material
burden, which tends to drive down the use of labor and increase the use of material,
including subcontractors. This may bias make/buy decisions in favor of buy.
The allocation of large overheads to the steadily decreasing labor content of projects
has brought about much inefficiency. The main cure that has been advocated for this
unfortunate situation is called activity based costing. Activity based costing is a method
of costing that attempts to dispose of most overhead costs by converting them to direct
costs. For example, the purchasing function is often treated as overhead. But if the
cost of writing and following up a purchase order is estimated, the project could be
charged for each purchase order it issues. Activity based costing has had great
success in some companies but many still hold to the old system of overheads, even
with its many inefficiencies.
Depreciation, often a large contributor to overhead cost, is not a real cost in the usual
sense. It is an accounting fiction designed to recapture over time the cost of one-time
major capital investments. Capital investments typically benefit more than one project.
They are amortized over time and get distributed to projects through an overhead
allocation process. Typically (but not always) every project helps pay for them.

20

But note that if one project does this, the additional costs dont just vanish. They are dumped onto all other
current projects.

Page 154 of 199

Profit. Profit is the difference between price and cost. Cost includes all direct and
allocated indirect costs. Profit is known as fee in DoD cost plus type contracts.
Profit outcomes, as opposed to plans, can be either positive or negative.
This is about all most persons involved in cost discipline situations need to know about
profit. There are complexities in certain incentive type contracts that are mostly of
interest to contract administrators and project managers, but need not be discussed
here.
In cost discipline situations, the team often sets its goals with profit stripped off so they
dont have to worry about it. Sometimes the overhead is also stripped off for the same
reason. But this assumes that nothing the team will do can affect overhead, which
generally is not true.
Historical costs. Historical costs are actual costs that have been incurred in the past,
direct or indirect. Examples are:

Records of labor hours expended on projects.

Prices paid to suppliers for various items.

Subtask costs and total project costs.

Expenditure (burn) rates.

In command economies, like the old Soviet communist economy, prices were set by
bureaucrats. We depend on free markets to do the same job, much more efficiently.
When we want to estimate the cost of something, we dont ask a government agency,
we ask the market what its worth. The simplest way to do that is to find out what it sells
for now, or has sold for in the recent past. Thats called a historical cost.
If we cant find exactly what we want on the market, we ask about what similar things
have cost, and sometimes we get pretty fancy and do statistical things like regression
analysis to plot cost versus weight or versus airspeed or against some combination of
factors. We also look at and try to make adjustments for trends if we arent going to buy
right now. Other factors we might consider are possible interventions such as looming
shortages, expiration of patents, and new products coming on the market.
It is hard to overstate the importance of historical costs in cost discipline situations. We
find their influence everywhere.
The first and most obvious application is in setting the cost goals. If the customer sets
the goals, he must have considered historical costs somewhere in his deliberations. It
would make no sense for the customer to say give me fifty Mach 2 high performance
fighter aircraft for $100 a copy, even if that was all he could afford. If you set your own

Page 155 of 199

goals, you will be driven at least to some extent by what customers will pay, but you will
still refer back to what similar things have cost in the past as a reality check.
When the customer sets the goals, you still have two problems. One is to be sure the
goals, while they may be challenging, are still doable. The other is to allocate the goals
down to major components or subsystems. Later in this appendix we will have more to
say about allocation of the goals.
In a cost discipline project it is a first principle and an article of faith that you always
have a current estimate for every subsystem virtually from day one. Its as reasonable
and necessary as turning your lights on when you drive at night. You have to know
where you are going. Until more refined information is available, historical costs of
similar items, adjusted as seems prudent, are often the best early source.
Even after you get what you believe to be better information from other sources, its well
to confirm it by comparison to historical costs. Even if it doesnt check out as closely as
you would have liked, its a confidence builder to go through the mental disciple of
explaining why.
Estimating methods. Estimating methods are discussed in chapter 10, so here we
merely provide a quick summary.
In the larger sense, all estimating is based on historical data. If you wanted to walk to
the corner market to get some junk food before the Super Bowl starts, you might be
interested in estimating how long it will take. If you have walked to that market many
times and have kept records or have a good memory, you should be able to make a
very close estimate. If you have never walked there before, you might try comparing
that journey to other walks you have taken where you did keep records. Or, you might
know your walking speed, and measure the distance to the market on a map. A simple
computation would get the desired number.
When you boil it all down, all estimating is based on historical data or memories. We
cant estimate anything if we know nothing about it. But sometimes even fragmentary
information can result in a pretty good answer.21
While all estimating is at root based on history, there are useful variations that should be
understood. We will look briefly at five of them.

21

Try this exercise: Estimate the height above sea level of the tallest mountain in Australia. Write down the steps
you used to get your estimate (that is, create a basis of estimate). Search your mind for memories about Australia
and about mountains. Dont just guess. Then look in an atlas and get the correct answer. Many who have never
been to Australia and have never climbed a mountain have come up with an answer within 20% of the actual height.
Professional estimators tend to do well in this exercise because they are accustomed to searching for analogies.

Page 156 of 199

Analogy. Analogy is finding a cost for a current good or service by comparing it to
similar goods and services and their historical costs. It can be used only where
analogies exist. It is highly favored by some customers in analyzing your bids.
The better the analogy, the better is the quality of the estimate. Even if the analogy is a
bit weak, it can often be improved by making certain carefully considered adjustments.
Commonly made adjustments are for inflation, complexity (difficulty), inheritance from
other projects, and skill level of the team. Team members not experienced with making
these kinds of adjustments are well advised to leave them to professional estimators or
cost analysts.
Parametric. Parametric estimating is the use of statistical and other sophisticated
methods to create mathematical and logical relationships that predict cost based on
values of certain parameters of the product. Estimators determine the proper values for
the parameters, enter them into the model, and produce a cost estimate. At least some
of the parameters are usually of a technical nature, so estimators typically collaborate
with engineers and other specialists to create parametric estimates.
A great advantage of parametric estimates is that they can be done rapidly and
reproducibly, and are therefore much favored for trade studies, which are typically done
under time pressure.
Bottom-up. Bottom-up estimating is based on personal experience. It often represents
a commitment as well as an estimate, if the person making the estimate will also do the
work. Bottom-up estimating is notably inaccurate when design definition is poor. It is
also expensive and time consuming. Generally, a bottom up estimate should be only
the final estimate made before a proposal is submitted.
Customers are often rightly skeptical of bottom-up estimates because they are
potentially self-serving, especially in a cost plus bidding situation. To the extent
possible, bottom-up estimates should be reinforced with other methods.
Standards. Standards estimating is also known as industrial engineering estimating. It
relies on statistical and empirical treatment of a certain kind of data. The data used are
from factory time and motion studies. The method is successful when standards are
kept up to date and when standards are properly adjusted for known variances.
Standards estimating can be regarded as a sub-type of parametric estimating. It is
generally applied to factory work but also finds application in the construction industry.
Level-of-effort. This is a variation on analogy estimating that is frequently used for very
small tasks when it is not worthwhile to make a more reasoned estimate. A typical
level-of-effort estimate might be 1/4 of a reliability engineer for 8 months. The
estimate proclaims that not much reliability engineering will be needed, and it is hard to
predict exactly when it will be needed. So the assigned reliability engineer(s) can work
on the project when needed for an average of 10 hours per week (1/4 time based on a
40 hour week).

Page 157 of 199

When customers are allowed to study the contractors estimating details, as in cost plus
contracts and even certain fixed price ones, they have a tendency to disallow level of
effort estimates if the amounts are large. If the amounts involved are significant, the
customer may be justified in believing that the contractor doesnt understand the job,
else better justification would have been provided.
Bases of estimate. The basis of estimate (BOE) is one leg of a three-legged structure.
The legs are:

Task description (what is to be done).

Estimate (resources needed to do it).

BOE (how the estimate was arrived at).

A professional estimator does not consider any estimate complete without all three legs.
BOEs are especially vital in cost discipline projects. In these projects the number of
estimates made may be twice or three times the estimates made in ordinary projects.
Not to have a basis for each and every estimate would result in chaos.
We should readily understand the need for task descriptions for work to be done, and
estimates of the cost. What often does not come through to many of us is the
importance of a good basis of estimate. Fact is, an estimate without a good basis is
probably a guess and is likely wide of the mark. It cant command much respect.
A subject we will talk more about shortly is quality of estimates (QOE). This is a useful
concept in any project, but especially when cost discipline is involved. Estimates
without a good BOE must be assigned a low QOE. It is especially important that high
dollar items have a good to excellent QOE, else the credibility of being able to meet the
cost target is suspect. Just because our aggregated estimate is currently lower than the
target does not mean we will meet the target. Like an experienced defense lawyer
evaluating weak prosecution evidence, a skilled cost analyst can quickly punch holes in
a poorly founded cost claim.
Here are ten reasons to have good BOEs:

The law. If we are bidding a U.S. Government project and are required to reveal
cost details, the Federal Acquisition Regulations require BOEs.

Company policy. Many companies that repeatedly bid major contracts have strict
policies that require BOEs for all estimates. Some companies even provide
guidance on how to write them. One of your authors once consulted for a company
and trained people in writing good BOEs. The company did this because it saw that
its BOE quality was generally poor and its bids were being questioned by its
customers.

Page 158 of 199

Helps sell. If you expect your customer to believe that you can meet your cost
target, can there be any doubt that your estimates must be well supported?

Supplements the statement of work. Claim: The BOE supplements the statement of
work and the task description in defining the task. Basis of claim: Just as you never
really understand a subject until you are prepared to teach it to someone else, you
never really understand a project task until you can credibly explain why you need
1,000 hours and $200K to do it.

Used for fact-finding and negotiations. Fact finding and negotiations with a customer
are necessarily arms length, adversarial encounters. A lot of blood can get spilled.
The thicker our armor, the less likely we are to take a damaging hit.

Used by management and by customers to assess the reasonableness of cost.

When we estimate, we dont do it for ourselves alone. Both our management and
our customers have a vested interest in how well we estimate. Management is
mainly interested in Do we have enough? The customer is mainly interested in Do
you want too much? To satisfy both, we need to get it right.

May be the basis for successful post-award claims against the customer. No one
ever thinks about this one until the contract goes sour and you have to make a claim
against the customer. When that happens, everybody dumps out their file cabinets
and cardboard boxes looking for the evidence of what you promised to do, and what
you didnt promise to do. What better situation than to find that information carefully
spelled out in your officially transmitted cost proposal back at the beginning of the
project?

Evidence of an adequate estimating system that consistently produces well

supported prices and that is integrated with the management and financial controls
systems. Having consistently good BOEs means that you have kept good records
and know how to find things in them. Thats a good sign to the customer. It means
you have your act together.

MAKES COSTS CREDIBLE! This speaks for itself. Need we say more?

Following are our guidelines on how to write a first rate BOE. Experience has shown
that it is all but impossible to write a good BOE if the task description is weak. To write
a good BOE, first write a good task description. With a good task description, the BOE
practically writes itself. Here are the steps:

Position the task in the flow of work. The task description should of course clearly
describe the work to be performed. But beyond that, it should also position the task
in the flow of work needed to make the project a success (customers tend to
perceive that what appears to be a standalone task does not add value and
therefore is not needed). What constraints are on the task? What is needed from

Page 159 of 199

others before it can begin? Before it can be completed? Describing the constraints
helps other team members understand how what they do affects other tasks in the
project. It creates linkages that are helpful to project planners and schedulers in
creating the initial schedule, and also in developing workaround plans when there
are problems. If something is needed from the customer that is not forthcoming on
time, that something can be the basis of a claim for additional compensation. It
something is needed from a subcontractor, it flags that fact for subcontract
managers who can then set up a tracking system to be sure that it happens.

Identify the products of the task. The task description should also clearly say what
the task will produce as a deliverable, whether that is a report, a piece of hardware,
some functioning lines of code, or a database. This information serves notice to
other team members of what they can expect from a given task. This expectation
can be integrated into the project schedule, and if not timely, can be a basis for
rescheduling.

Describe the resources needed and why they are needed. Remember what we said
earlier. Cost is just a shorthand way of encoding resource needs. To justify cost,
justify the resources.

Quality of the estimates. We introduce here a concept that we have found to be

extremely useful in managing projects that require cost discipline. It is the concept of
quality of estimates, or QOE. This is a system of objectively scoring estimates with
respect to the likelihood that they will still be valid (accurate) when the time comes to
spend the money. In QOE, a simple numerical scoring system is devised that scores
each estimate for its validity using objective criteria. The method requires some
homework to assure that the quality is there.
Here are examples of objective criteria that might be applied to estimates:

A firm fixed price quote from a qualified and trusted supplier that will be exercised
without modification within the validity period of the quote would be regarded as a
top quality estimate, probably a 5 on a scoring system from 1 to 5.

The same quote with a strong possibility of some minor design changes or delays in
execution might be rated a 4.

A careful estimate based on reasonably good analogies might be rated a 3.

An engineering WAG or guesstimate might be rated a 1 in the same scoring

system.

It takes work to develop quality estimates, and a QOE scoring system can be highly
visible evidence that great attention has been paid to getting the best possible
estimates. A weighted QOE score that is very high is a real asset to a team working

Page 160 of 199

under cost discipline. It asserts a credible claim that there is a good chance of meeting
the cost goal. It asserts a credible claim that the team knows its business.
Risks. A fairly comprehensive discussion of project risks and risk management can be
found in chapter 14 of this book. The only additional point we will make here is that the
concept of QOE, discussed above, and the concept of cost risk are natural allies.
A team that has set up a QOE system, even a fairly primitive one, can move seamlessly
from that to management of cost risk. In chapter 14, we note that management of all
projects risks, not just cost risks, hinges on the identification of risk drivers. We recall
here the definition of a risk driver:
A risk driver is a root cause force or circumstance that might possibly act to change the
cost of one or more tasks in the project.
Very often it will be found that a root cause that can force a change in the plan turns out
to be an estimate of low quality. Or as a minimum, it turns out to be a proximate cause
from which the root cause can be derived with some thought.
Exhibit B-5Example Allocation of Projects Cost Estimates by QOE Level
Allocation of Costs by QOE Level

1
2
3
4
5

Setting up a QOE system is an excellent first step before launching the project risk
management effort. It can make a major contribution to the management of cost risk.
Exhibit B-5 shows a useful metric that is based on QOE. It essentially shows how well
project cost estimates are supported. If level 1 is guesstimates, and it is a large fraction
of total estimated costs, then the project can be presumed to have high cost risk. The
pie chart in Exhibit B-5 is typical of a project that has a pretty good, but probably
improvable, handle on its costs.
High value items. A list of high value items in decreasing order with their estimated
costs is of great value to a team working under cost discipline. Such a list generally
follows at least approximately the 80/20 rule, which basically means that 80% of the
costs will be found in 20% of the items.

Page 161 of 199

A nice benefit of such a list is that it naturally orders the priorities for cost reductions
when they are needed. If such a list is made into a database that also includes the
assigned QOE score for each estimate, you can further refine the priorities for both cost
reduction and for improving our estimates.
Cost discipline implementation. Cost discipline can be implemented in a variety of
ways. Here are explained some commonly used ones.
Variations in what is controlled. Among government agencies and private sector
companies there is considerable variability in cost control structure in projects under
cost discipline. To some extent this is due to ambiguities in guidelines and policies, but
it also may reflect a culture that has long prized performance over cost. Getting this
culture to at least put cost equal to performance is a process that is still going on. But
the level of budgets we now see in many areas of endeavor indicates that more and
more we will see projects where cost is more important that performance.
The variations seem to assume two main forms. One is based on which costs are
controlled. The other is the level of rigor of the control that is applied. We will examine
several real-life possibilities for each situation.
Cost discipline based on which costs are controlled. Here are some common modes of
control that are based on which costs are controlled.

Total life cycle cost. This sometimes is not defined to include development costs for
a product that is already under development. However, it is generally applied to all
costs after the development phase. When LCC discipline is applied, it is necessary
for estimating ground rules and assumptions to be carefully defined and controlled;
else the estimates will not be useful. Without careful controls it is all too easy to
seriously misestimate operations and support, which are often by far the largest
components of LCC. LCC control can be usefully applied to the operational phase
for products that have already been developed. For example, it could be applied as
a competitive criterion for the procurement of aircraft tires. The competition would
be based on the cost per landing of the tires. Thus a tire that costs $500 and can do
100 landings ($5/landing) would beat out a tire that costs $450 and can only do 75
landings ($6/landing). (Of course such an analysis would include more than just the
purchase cost of the tire. It would also include the cost of changing the tire. This
would make the $500 tire look even better if the per change costs are equal.)

Average unit flyaway cost. This concept apparently originated with the U.S. Air
Force, but it is also applied in army, navy and commercial cost discipline situations.
For navy ships, flyaway becomes sailaway, and for the army it becomes driveaway.
In commercial situations, the name will depend on the nature of the product. The
basic idea is to include both non-recurring (development) costs and recurring
(production costs), allocated in some reasonable manner to each unit produced. In
some situations it may be a good control to use because it reduces the temptation
for excessive run-up of the non-recurring costs in order to get the recurring costs

Page 162 of 199

down. However, it should be noted that for large production runs reasonable extra
effort in development will usually pay dividends in production.
It is fruitless to use flyaway cost as a control if the budget for development has
already been set and the costs will almost surely be incurred. At that point, the
development part of the cost becomes sunk, or at least committed. Decisions based
on sunk or committed costs are generally poor decisions.
If a decision is made to use average flyaway or one of its equivalents as a control, it
is important to have a fairly high degree of certainty about production quantity.
Thats because production quantity has a heavy influence on both the recurring and
the non-recurring components. For the non-recurring part, the usual method of
allocation to individual products is to divide total non-recurring cost by total
production quantity. For the recurring part, the total production quantity has a very
large impact on the effect of the learning curve.

Average recurring unit production cost. This is a frequently used control. It is

especially useful for products that have small costs after the implementation phase,
or products where the team can do little to influence the costs after implementation.
One example of this situation is the procurement of systems that are put into storage
until they are needed. While in storage they need little or no maintenance, and have
no operations costs.

Cost discipline based on level of rigor. Here are some common modes of control that
are based on level of rigor.

Most severe. Probably the most rigorous situation is the absolute constraint on cost.
One of your authors once worked on a project where a $10 million average unit
production cost limit was set for a sophisticated unmanned reconnaissance aircraft.
It was the only truly hard and fast project goal. Virtually all of the other goals were
tradable. The competition for this project was based on which contractor could get
the most system performance for $10 million a copy, a novel and ground breaking
approach.

Cost threshold. Some projects have used a cost threshold approach. The basic
idea is that the project is allowed to proceed only as long as it is deemed to be
affordable. The usual mechanism is a cost threshold that if exceeded will trigger an
affordability review. Such reviews might have a variety of outcomes. Among them
could be cancellation of the project, modification of the project goals, or an intensive
cost reduction program.

As a goal Sometimes expressions such as As a goal, the average unit

production cost should not exceed X are used to establish cost discipline.
Unfortunately, such expressions tend to be destructive of real cost discipline. Most
people think of a goal as something having a degree of flexibility, as in As a goal,
we will do so-and so, meaning we will give it a shot, but we will make no

Page 163 of 199

guarantees. We recommend against this approach if you are serious about cost
discipline.

Informal. A common manifestation of this approach is when the customer says

something like This project is in danger of cancellation if the cost exceeds X.
Unfortunately, these warnings often come when the cumulative cost is already 80%
of X and still trending rapidly upward. This approach is a poor excuse for cost rigor.

Management versus level of rigor. If the customer sets a soft goal, should cost
discipline be more relaxed? Why should the team watch costs if the customer isnt
watching all that closely?
In many organizations, existing policies tend to favor a relaxed approach to cost
management when the customers outlook is similarly relaxed. In certain projects, like
studies or research projects, this may be quite reasonable, but for major projects of any
kind, we believe this is a very bad idea. Here are our reasons why:

To maintain cost discipline. On projects with good cost discipline, it often happens
that a lot of effort has been put into developing and maintaining that discipline. If
team members who complete such a project then move on to a project with poor
cost discipline, they are likely to develop bad habits. When they next go to a project
with high cost discipline, they will have to unlearn those habits.

Company reputation. If your company establishes a reputation for being uniformly

cost effective on all of your projects, it is likely that customers will take notice. It
could lead to getting a bigger share of the work, especially when you have strong
competitors who are your equals in technology.

Better products. An interesting side effect of cost discipline is that, odd as it may
seem, better products seem to result. Maybe its because teams that are sloppy
about costs also tend to be sloppy about quality.

Management issues in maintaining cost discipline. Successful management of cost

discipline projects is extremely challenging. Part of the reason is that almost everything
you do affects costs, and small mistakes can lead to big problems.
In this section we explore some of the many concerns that managers and team
members will have to deal with. We would like to claim that all of what we have to say
is based on experience with projects where cost discipline was successfully applied.
But the truth is that much of it is based on projects where it was not well applied, and is
therefore in the category of lessons learned.
We make no claim that the approaches advocated here are the only paths to cost
discipline. But we do claim that they are workable and helpful.

Page 164 of 199

Commitment from the start. If cost discipline is to work, there must be management
commitment from the start, plus continuing reinforcement and encouragement
throughout the project. Here are some things management needs to do:

Conduct a project kickoff meeting for all hands and emphasize cost discipline.
Explain the rewards to the team and individually for maintaining cost discipline.

Write internal project directives that establish the processes for cost discipline. Be
sure that every existing and every new team member is briefed on these.

Write the cost discipline processes into supplier contracts on all but routine purchase
orders. Invite major suppliers to internal cost discipline meetings so they become
truly a part of the team.

Encourage trade studies, as many as time and budget will allow. Engineers (and
others) sometimes tend to think that if the concept they have will work, why look at
other approaches? The reason to look at other ideas is to find the minimal design
that will help meet the cost target.

Senior project personnel attend weekly cost status meetings. Their presence makes
it clear that they support cost discipline.

Prominently display results of trade studies, cost reduction efforts, and other positive
accomplishments.

Praise team accomplishments to upper management and provide feedback to the

team from upper management.

Reward team success, at least in small ways. No team member expects to receive
prepaid retirement benefits at age 45 as a reward, but recognition in team meetings
and small rewards like gift certificates can work wonders.

Recognition and avoidance of limits to success. It is important to recognize and avoid

potential limits to the success of cost discipline. Here are a few:

No management commitment or vague and intermittent commitment. This is the

most disastrous limit to success. It is largely engineers or other technical experts
who determine project costs, and typically they are trained to be rewarded for
product performance. They will not ordinarily pursue cost discipline unless they are
strongly motivated by management to do so.

Institutional resistance to change that thwarts cost discipline. This can include
reluctance to setting up the tracking processes vital to cost discipline, failure to
supply the cost analytical support needed to determine cost rapidly as designs
evolve, and animosity toward the notion of rewarding people for making
improvements.

Page 165 of 199

Habitual lack of up front planning. A poorly planned project is a project that is

unlikely to meet its cost targets.

Emphasis on beyond state-of-the-art performance. Performance beyond state-ofthe-art is likely to be much more expensive and harder to estimate accurately than
performance that is well established and mature. The urge to use the latest
technology, especially when it is barely out of the laboratory, can kill cost discipline.
The exception is when the project plan and its funding have been set up to work with
immature technology. Today, that does not often happen on major projects.

Integrated product teams. The first major organization to embrace the concept of
integrated product teams (IPTs) was the U.S. Air Force. Since they adopted it, the
concept has spread far and wide, even to staid and conservative commercial
companies, who often are not early adopters of new management ideas. Many project
bid opportunities require the establishment of IPTs because customers believe they are
necessary for effective performance of the project. Even those projects that dont
require IPTs will generally benefit from employment of the concept.
Here are some notions underlying the IPT concept:

The team is set up to provide a specific product or service.

The team is multidisciplinary. All (or virtually all) of the skills needed to do the work
are represented on the team. The team members work together toward a common
goalsuccess of the project. Often all members of the team work in a common
work area. This contrasts with the organizational silos that have been built in many
organizations. Silos tend to slow and distort project communications.

Team members have both mutual and individual accountability. While they may
receive some assignments related only to their specific skills, they will receive other
assignments involving mutual support of team objectives, such as serving on a
design-to-cost steering committee.

Because communications are tight and not burdened with organizational barriers,
decision making is tightly integrated, and can occur rapidly.

Within their product area, teams are empowered to make almost all decisions.

Here are some practical issues related to team composition and activation:

Team composition. A prevailing image of the IPT is the abolition of the wall over
which the engineers used to throw their designs to the manufacturing folks.
Another image is that of engineers and manufacturing people on the factory floor,
working together to fix problems and make production run smoothly. Those images
are certainly valid and welcome. But to them we should add a few others if the IPT

Page 166 of 199

concept is to be fully operational. Here are some other images that would be
welcome. They may be seen in some teams, but the evidence shows they are not
seen in others, even in teams that supposedly have a mastery of the IPT concept.
o

Visualize the project manager sitting in weekly on the cost assessment

meeting, helping to generate what-ifs and contributing to risk assessments.
Or visualize the project manager dropping in from time to time on those
meetings between engineers and manufacturing people to see just what
problems they are dealing with and to lend his weight to helping solve them.

Imagine the purchasing people joining in on a conference call or a meeting

between their teams engineers and the subcontractors engineers to help
resolve a problem, thus gaining first hand information about the problem and
getting an early start on the paperwork needed to support its resolution. This
would be especially welcome because on the order of 60% or more of project
budgets may go to subcontractors. Yet in many teams the people who
manage subcontracts remain in their offices much of the time and wait for a
problem to be brought to them. They are not always full participants in the
IPT process.

Consider the possibility that the contracts department will always have a
member present at meetings between customer representatives and
members of their own team. Failure to do this is a known and common cause
of expensive and unfunded requirements creep that kills chances of meeting
cost targets.

Finally, consider the possibility that cost analysts, engineers, factory people,
and subcontracts managers all work closely and continuously together to
maintain a high level of cost awareness. Cost awareness would comprise not
merely knowledge of the current cost estimates and the high value items, but
also knowledge of which estimates are weak and subject to cost risk.
Of course, the ultimate disrespect of the essential work of the cost analysts is
to ignore their findings. On far too many projects, management will decide
that it doesnt like the professionally prepared cost estimates, and will
arbitrarily cut them. This is a recipe for cost overruns and failed projects. It
has happened many times, and the result is usually the same.

Responsible engineers. Some teams call them responsible engineers; other teams
call them lead engineers or perhaps other names. In projects that are not design
oriented they might not even be called engineers. Regardless of name, what we
have in mind are those senior technical people who manage particular areas of
expertise and who make sure that their expertise is properly and adequately applied
to the product.

Page 167 of 199

These people are key players whose decisions can make or break cost discipline.
Their enthusiastic cooperation is absolutely necessary. To ensure it, they must be
given respect and a key role in allocation of cost targets to subsystems. There is an
ever present danger that they will become discouraged if cost targets are so tight
they cannot possibly be reached, and there is no flexibility to modify goals. These
are also key players who should always attend or be represented at weekly cost
status meetings.

Specialty groups. Most projects require the services of one or more specialty groups
such as logistics, reliability, maintainability, safety, MIS and so forth. Often the
project will not need any of these people full time to do the needed work. Because
they are not needed full time they often miss out on participation in some team
activities. Realistically, they may have little or nothing to contribute during certain
phases of the project, but at other times the absence of their contribution might have
a major impact on costs. For example, in a drive to minimize costs, it is possible that
a design will become unsafe or unreliable. If the appropriate specialty people are
not there to catch the error, the result might be schedule delays and added costs
while the design is being reworked.
To remove the possibility that specialty groups will not be involved at critical times
when their input is needed, someone who understands their role and their potential
contribution needs to be sure they are there. Our thought is that this should be
assigned to the chief project engineer, or to that new breed of engineers called
systems engineers, whose responsibility it is to guide the whole engineering effort in
the right direction.

Motivating with rewards. Perhaps in ten years from when this is written cost
discipline in major projects will be commonplace, and rewards for doing it well will
not be necessary. But in the present state of affairs, many team members perceive
themselves to be rewarded for behavior that is not necessarily consistent with cost
discipline. To counter that perception, specific rewards are needed for behavior that
is consistent with cost discipline.
The problem is particularly acute in the engineering or other technical professions,
which in reality control the project costs. Very little in the training of the average
technical person inclines him or her to think much about cost discipline. Thinking in
that arena is more prevalent in people with finance backgrounds. Most engineers
perceive that they are rewarded for achieving high performance designs that work,
and often for meeting drawing release schedules. Without urging and rewards, not
much thought will be given to trying to find minimal, balanced and efficient designs
that also work but that will be much less expensive.
Sometimes engineers and others feel pushed by project schedules and momentum
to stifle their own creativity. They are concerned that if they take time to work on or
try to push a creative idea they may wind up being criticized. A tool that some
organizations have found useful to counter such failures of initiative is the

Page 168 of 199

forgiveness voucher. A forgiveness voucher might be issued once every few
months to all project personnel who are in creative roles. The wording of such a
voucher might be as follows:
If it meets the goals of this project, if its ethical, if its good for my customers, if I
believe I am using my time wisely, and Im willing to be personally accountable for it,
dont ask for permission. Just do it. If I screw up, I will ask forgiveness later and it shall
be given.
The window of opportunity. With respect to cost discipline, the window of opportunity
refers to a period of time, mostly in the early design phase, where significant
opportunities exist to modify design concepts in the direction of lowest cost, without
incurring large expenses for design rework. In certain projects, the window of
opportunity may open more than once.
The main concern with the window of opportunity is to keep it open as long as possible.
This means allowing as much time as possible for doing wide explorations of the trade
space, making high quality estimates and fixing errors in design concepts. It means
having enough time to stimulate competition among suppliers. It means taking the time
to be sure you have the right suppliers and that they are aware of and fully cooperative
with your cost management approach. It means not crowding out the natural
progression of the learning curve through which all projects must pass.
Keeping the window of opportunity open typically increases development costs, but up
to a point, it is worth the extra cost because significant savings typically result in
production and in operations and support. Increases in development costs may be on
the order of 20%. But the savings later on may be much larger.
Here are some potentially bad results that can happen from closing the window of
opportunity too early:

Make vs. buy decisions are forced.

Quantities required have not stabilized.

Design concepts are too sketchy for suppliers to make realistic estimates.

Acceptance of supplier estimates is forced due to inadequate time to evaluate costs

and bases of estimates.

Locks in designs that otherwise would be considered for trades.

Weekly cost and design reviews. Weekly cost and design reviews often are different in
cost discipline projects than they are in ordinary projects. In ordinary projects, such
reviews are often peer reviews in which each discipline individually and in isolation
reviews the state of its part of the design effort. Little or no attention is paid to cost. In

Page 169 of 199

projects subject to cost discipline, weekly reviews take on a whole new dimension. The
new dimension results from elevating cost targets to the same level as performance
targets in discussions relating to corrective actions or alternative approaches. The new
dimension ensures that progress toward meeting cost targets must progress
satisfactorily before progress toward meeting performance targets can be deemed
satisfactory. Insufficient progress toward meeting cost targets can force additional trade
studies and even changes in the design baseline.
Here are typical agenda items for these reviews:

Review of current baseline design approach. Chief project engineer reviews the
current baseline design approach, and notes any changes that have been made in
the previous week.

Design trades. Chief project engineer reviews trades studies in progress and
reports any interim or final results. If trade studies indicate that a change in baseline
is needed, it is proposed. Generally, action items will be assigned to do follow up in
configuration management, cost analysis, and other impacted areas.

Current point estimates. Cost analysis presents its current best estimates for each
subsystem and rolls them up into a potential price. The derivation of the estimates is
explained. Any differences between these estimates and estimates of suppliers are
explained. Relationships of estimates with subsystem and overall cost targets are
discussed. Reallocation of subsystem cost targets may be discussed and agreed to.

Cost trends. Cost analysis presents cost trends for each subsystem and indicates
where costs appear to be stable and areas where they are still volatile. Estimate
quality (QOE) assessments are presented.

Responsible engineer inputs. Individual responsible engineers present activities in

the past week both in design and in cost compliance. A useful idea is to have them
present their own assessments of what they think their final (end of development)
cost estimates most likely will be plus their assessments of risks in those costs as
measured by minimum and maximum values. Any changes from the previous week
must be explained. Any inconsistencies with current results reported by cost
analysts are discussed.

Action items. The chief project engineer or his designee assigns action items as
appropriate, such as expansion of trade studies, additional cost analyses, etc.

These reviews are typically done weekly. Attendees at all of them normally comprise:

Chief project engineer or designee.

All responsible engineers.

Page 170 of 199

Manufacturing representative.

Lead cost analyst.

Subcontracts management representative.

Contracts management representative.

Representative from each resident subcontractor (often non-resident subcontractors

are tied in via telephone, Internet, or video conferencing).

Customer representatives (if available).

Project tracking system. For the convenience of all concerned, cost analysts (or
possibly others) should maintain a project tracking system. Its contents should
correspond to the technical and cost information presented at the weekly cost and
design meetings described above. The information should be available to all interested
team members, preferably by installing it on a server. However, it must be available on
a read only basis to prevent tampering.
Each weeks results should be archived for several reasons. Among them is the
possibility that a responsible engineer may want to revert to a previous design, supplier
or cost. These saved results are also useful in writing future bases of estimates, and
also in writing project lessons learned.
Setting cost targets. Setting cost targets is possibly the most important single activity in
a project under cost discipline. It can also be a very challenging activity. It has two
aspects: setting the overall target, then allocating that target downward to the various
subsystems.
We discuss each of these aspects in turn.
Setting the overall target. The customer in some sense always sets the overall target for
us. In the commercial target cost scenario, focus groups are used to determine a price
that is acceptable to likely buyers. The desired profit is subtracted from this number; the
result is a target cost.
In the situation encountered by most contractors, the customer reveals the target. It
may be based on affordability considerations, or it may be based on a should cost
analysis. Such an analysis typically refers back to what was paid for other, similar
systems. But it may also be influenced by affordability or even political considerations.
It is not unheard of for the target to be based on the amount of money available, with
little or no consideration of cost realismthis is a dangerous practice!

Page 171 of 199

Even though the customer creates the target cost, the team responsible for building the
product, or hoping to be responsible, must determine whether it is realistic. For more on
this, see chapter 5.
Allocating the target downward. A reasonable question to ask is, why allocate the target
downward? Why not just let the team work to the top level target?
In a project to develop a hand tool or a toaster, this might work very well. But in a major
project to develop an aircraft, or a ship, or other large and complex system, its
impractical. Chaos would result.
Another good question is: At what level should the cost be allocated down? There is no
one best answer to this question, but a good general guideline is that the level should
be such that five to ten subsystems can be defined. Consider what would likely happen
if twenty major subsystems were defined. The weekly cost and design review meeting
discussed above probably would become unwieldy. It could not be done in a morning
or even in a day.
How do you set these subsystem allocation amounts? An excellent way to start is to
look at subsystem cost ratios from similar historical projects. These ratios can either be
used as is initially, or can be judgmentally adjusted for perceived differences in
complexity or risk. As the project progresses inequities may appear and they should be
fixed by negotiation among the team members.
For some projects it may be difficult to find useful precedents from which to derive
ratios. In this case initial ratios can be taken from the parametric or other estimates
done by the cost analysts. Subsystems deemed to have higher than average risk
generally should have their allocations increased.
Project management is well advised to remove a small contingency amount from the
target amount and use it to fix problems or correct inequities. On the order of 10% is
recommended.

Page 172 of 199

Appendix C -- Miscellaneous tools

Here we present several tools that can be helpful in bidding to win. These are tools of
wide application. As they are described, we will point out possible uses.

Brainstorming. A tool for developing information based on hidden knowledge and

intuition.

Multivoting. Brainstorming frequently generates a long list of possibilities.

Multivoting provides a means for prioritizing them.

Ishikawa diagrams. Ishikawa diagram were invented by Kaouru Ishikawa. They are
also known as fishbone diagrams or cause-and-effect diagrams. They are useful in
determining underlying or root cause of risks and problems.

Pareto principle. This is also known as the 80-20 rule, or the law of the vital few. It
is widely used in many areas of life and work.

Analytic Hierarchy Process. Invented by Dr. Thomas L. Saaty at the University of

Pittsburgh, this is a powerful tool for quantifying the relative importance of a number
of alternatives as ratios.

Variation analysis. This a mathematical method for dealing with a frequently arising
problem: what is the cost of accuracy? What premium do we have to pay to
increase accuracy? What can we save by loosening up quantitative tolerance
requirements on products? We speak here not just of dimensional tolerances but
accuracy requirements of any type.

Brainstorming
Brainstorming is a group method for generating ideas, which can be inputs to other
methods for screening, grouping, prioritizing, or evaluating. It is particularly valuable for
identifying risk or cost drivers, design alternatives and other information which lies
hidden beneath our conscious thoughts.
Here are some characteristics of brainstorming:

Often used for identification, but can also be useful for analysis, tracking, controlling,
etc.

Participants verbally identify ideas; participants may build on each others ideas
(chaining)

Best used in a small group (<10 people)

Requires a tactful facilitator to deal with conflict and to encourage shy people to
participate

Page 173 of 199

Does not require participant training

Is an enjoyable exercise

Generates a lot of ideas in a short time

Here are suggestions on conducting a brainstorming exercise:

Facilitator explains subject matter, process, and the rules:

o
o
o
o

Do not judge or criticize ideas of the speaker.

Encourage wild ideas and out of the box thinking.
Build on ideas of others (chaining).
Go for quantity of ideas; dont try to develop ideas into plans or root causes (do
that later).

Participants generate ideas using one of two processes:

o Unstructured: call out ideas spontaneously.
o Round-robin: each participant takes a turn, in order, to state an idea (forces shy
people to contribute).

Record ideasfacilitator writes on a visual medium in sight of all participants

Review listall review for clarity and understanding; revise as needed.

As an alternative to free-form brainstorming, it is sometimes helpful to do a more

structured version. In structured brainstorming, the group starts with a short memoryjogging checklist. They begin at the top of the list, and generate ideas about each item
in the list, in turn, until no more ideas seem to be forthcoming. At that point, the
facilitator moves on to the next item on the list.
Multivoting
The output of a brainstorming session more often than not is a rather long list of
possibilities. Generally, the list will be too long to consider all of them in detail. It is
necessary to screen the list and determine which items in it are possible winners and
which are likely to be losers. Multivoting is a method for prioritizing and shortening a
long list.
In the literature you can find more than one definition of multivoting. The description
given here is a popular one, but not the only one. If you are interested in looking at
other versions, you can find them on the Internet.
Here are the steps for the version we prefer:

Page 174 of 199

Using brainstorming (or some other method), form a list of possibilities. The order
they are in is not important at this stage.

Create a multivoting caucus, a group of people that has high interest in and
familiarity with the subject matter. A practical limit to the number of people in the
group is about ten. Three is a good minimum. A disinterested facilitator should lead
the group.

Have the items displayed visibly, perhaps on a chalk board. Sequentially number all
of the items in the list of possibilities beginning at 1.

The facilitator should go over every item in the list with the group to make sure
everyone has the same understanding of it.

Determine the number of items each person in the group will be allowed to vote for.
A good choice is approximately one-third of the number of items in the list. For
example, if the list contains 23 items, seven would be a good choice. Whatever that
number is, lets henceforth call it N for convenience.

Have each person in the group vote for the N items in the list he or she considers
best. The most convenient way to do this is to have each person write down on a
piece of paper the N numbers that identify their choices. The facilitator shall collect
these initial votes.

The facilitator shall put a checkmark in front of each item for each vote it receives.

Reduce the length of the list to a length desired by the group. A convenient way to
do this is to first cross out all items that got no votes. If that isnt short enough, cross
out all items that got just one vote, and so forth.

If agreeable with the group, the remaining items can be prioritized by how many
votes they got. Ties can be broken by a show of hands. If any issues remain, the
multivoting can be repeated, perhaps with the number of votes per person reduced.

Ishikawa diagram
An Ishikawa diagram, also known as a fishbone diagram, or as a cause and effect
diagram, is a useful tool for finding root causes. When do we usually want to do this?
Two situations: 1) problems, and 2) risks.

Page 175 of 199

Exhibit C-1--Typical Cause and Effect Diagram

Process / Policy

Personnel

Original
estimate
exceeded

Too high
learning
curve
Poor
estimating

Less reuse of
old designs
than planned

Inadequate
support system

Inadequate
test system

Cost
containment

Cost
containment

Hardware

Key personnel
not available

Training
inadequate

On other
program

Leave when
trained

Equipment
problems

Potential
ABC
Subsystem
Schedule
Slip

Supplier labor
difficulties

Tools / Environment

191

For both problems

and risks, it is
usually profitable to
look beyond mere
symptoms, or even
proximate causes,
and search for
deeper causes,
commonly called
root causes.22
The diagram was
conceived by Kaoru
Ishikawa in Japan
in the 1960s. It is
widely regarded as
one of the premiere
tools for quality
management.

Obviously, the name fishbone diagram comes from its resemblance to the pattern of
bones of a fish. The architecture of a fishbone diagram is as follows:

On the right, a box is drawn. Into this box is put a brief statement of the problem or
risk of concern. The example above concerns a risk. A risk can be distinguished for
a problem by the presence of a conditional word, such as may, might, could,
possible, or potential.

A main bone is drawn on the left, terminating at the box.

Two or more rib bones are drawn diagonally, leading into the main bone. Above we
have drawn four. Each of these is labeled with the name of an area from which
proximate causes are believed to originate. There is considerable flexibility in
naming these. Above, the ribs are labeled
o Process/Policy
o Hardware

22

The definition of a root cause is the subject of some debate. According to Wikipedia, a root cause is an initiating
cause of a causal chain which leads to an outcome or effect of interest. To find a root cause for any outcome or
effect, it is only necessary to do what four year olds often do keep asking why? Unfortunately, as every parent
knows, that process eventually leads to a blank wall. The only answer that can be given is thats just the way it is,
or perhaps Thats the way God wants it. Pursuing the why question that far back is generally not helpful. There
needs to be a stopping place. The place to stop usually is the point in the causal chain where an intervention could
best be implemented to change performance and prevent an undesirable outcome. Clearly, this stopping place is a
judgment call. Note that there often are multiple root causes. That is, at some point in tracing the chain of
causation, branches will be found. The diagram on this page has examples.

Page 176 of 199

o Personnel
o Tools/Environment

By some method, usually brainstorming, first assign the most obvious proximate
cause. Add branches off the proximate causes until an agreeable root cause is
identified agreeable in the sense that something might be done to fix it and thereby
mitigate the risk.

Pareto Principle
The Pareto principle, named after the Italian economist Vilfredo Pareto, is also known
as the 80/20 rule. It states that in many situations, 80% of the outcomes stem from 20%
of the causes. For example, it is frequently held to be true that 80% of a products cost
is determined by the first 20% of the design decisions.
What led Pareto to announce his principle was his observation that 80% of the wealth of
Italy was held by 20% of the population.
The rule is a useful approximation to reality for many situations, and can be an aid to
analysis. However, it is not true for every situation and one must be careful not to
misuse it.
Analytic Hierarchy Process (AHP)
AHP, an invention of Dr. Thomas L. Saaty of the University of Pittsburgh, is a process
widely used in planning, priority setting, and resource allocation. A virtue of the process
is that it can reduce very complex decision making situations to a relatively simple pairwise comparison of options.
Our description of it here will not even touch on the full range of its capability. We will
describe its use in fairly simple situations. Readers interested in learning more about it
are referred to the text The Analytic Hierarchy Process, by Thomas L. Saaty (RWS
Publications, Pittsburgh, PA).
AHP is a mathematically reasonable and robust way to handle human judgments in
complex decision situations. For example, suppose we are not able to get direct and
decisive information about a customers relative preferences for various project goals.
But we are able to get testimony from various people who have been in close contact
with the customer. One simple thing they could do is to agree on how the customer
would rank the goals in an ordinal sense, which is just a fancy way of saying that they
can make a list of the goals in order of the customers preference. That of course is
valuable knowledge, but even better would be to know the customers preferences in
the ratio or quantitative sense.
Suppose for example, that the product is an aircraft and the major goals are only three
in number: airspeed, altitude and payload. Further suppose that the ordinal ranking is:

Payload.

Page 177 of 199

Airspeed.

Altitude.

But we want to know more. Is payload twice as important as airspeed? Is airspeed

only marginally preferable to altitude? AHP helps us find these answers.
The technique is based on making pair-wise comparisons and forming them into a
specific kind on matrix called a reciprocal matrix. That part is easily explained and we
will do so shortly. Its the part beyond that which is harder to explain because it involves
some mathematics that most people never encounter, even some engineers and
scientists. But for the mathematically sophisticated among our readers, the process
involves finding the dominant eigenvalue of the matrix and also its corresponding
eigenvector. Fortunately, you dont need to be able to actually do this sophisticated
math to use AHP. If your problem involves finding the ratio ranking of only three, four,
or as many as five parameters, you can use an AHP spreadsheet program that is
included in our CD that can be ordered by readers of this book (see the final page of the
book). If you are even a bit sophisticated with spreadsheets you can easily expand the
method on this spreadsheet to six, seven, eight or more parameters you want to rank.
Beyond about ten parameters, AHP becomes difficult because of the mental challenge
of keeping all of the comparisons straight.
Now that we have ducked the hard part of the problem by referring you to software, we
can comfortably and rather painlessly talk about the process of forming the requisite
reciprocal matrix. Suppose we have four parameters to rank, call them A, B, C, and D.
We form a 4x4 matrix like this (Exhibit C-2) with 1s in the main diagonal:
Exhibit C-2AHP Matrix Example (Initial Condition)

A
B
C
D

A
1

1
1
1

Then we proceed to make all possible pair-wise comparisons, preferably in a random

fashion.
Suppose our first comparison is between A and C. If we (an individual or a group)
believe that (say) A is more important than C, we have to decide approximately how
much better. We express that preference on a scale of 1 to 9, defined as follows.

If A and C are equally important, enter 1 into the cell that is the intersection of the A
row and the C column. (Note that this is the reason all the cells in the main diagonal
have entries of 1. For example, A is as important as itself.)

Page 178 of 199

If A is weakly more important than C then insert 3.

If A is strongly more important than C then insert 5.

If A is very strongly more important than C then insert 7.

If A is absolutely more important than C then insert 9.

If you have trouble deciding which of the above odd numbers to insert, then insert
the intermediate even number. As an example, if you are undecided between 3 and
5, then insert 4.

The above explains what you do if the row parameter is more important than the column
parameter. If the reverse is true, for example if C (row) is less important than D
(column). then insert the reciprocal of 3, 5, etc.
You only need to fill in the empty white cells in Exhibit C-3. The main diagonal cells
already are filled with 1s. To fill the remaining cells, the spreadsheet software will
automatically insert the reciprocals of the corresponding cells across the diagonal.
Exhibit C-3 is an example of what a filled in matrix might look like.
Exhibit C-3Example AHP Matrix (Filled In)

A
B
C
D

A
1
3
1/5
1/4

B
1/3
1
1/7
1/9

C
5
7
1
1/2

D
4
9
2
1

Obviously, in filling in such a matrix, one must be careful to be as consistent as possible

For example, if one were to say that A is more important than B, and B is more
important than C, then it wouldnt do to say that C is more important than A.
Its hard to be perfectly consistent, and it gets even harder as the size of the matrix
increases. Fortunately the AHP mathematics provides you a method for determining
whether or not inconsistencies are in reasonable bounds. It calculates a value called
the consistency ratio (CR). If CR<0.1 then consistency is acceptable, according to Dr.
Saaty. If the consistency ratio is too high, its generally easy to go back to the matrix
and find the problem then correct it. Some commercially available AHP software (but
not our free spreadsheet!) helps you find inconsistencies.
Plugging the matrix above into the spreadsheet yields CR = 0.04 (consistent enough)
and the following quantitative rankings:

Page 179 of 199

A = 4.76
B = 10.75
C = 1.44
D=1
Thus, A is 4.76 times as important as D, B is 10.75 times as important, and C is 1.44
times as important. Likewise, A is 4.67/1.44 = 4.24 times as important as C.
This method is powerful and widely accepted. We recommend it for any situation where
it is necessary to rank a small number of parameters quantitatively based on human
judgment.
Variation analysis
We must give warning. This is the most mathematically sophisticated section of this
book. You may not want to tackle it unless you have a background in mathematics up
to and including calculus and statistics. We assume that this subject is of most interest
to engineers and scientists and that they will have the mathematical skills to understand
the development.
This is a book about bidding to win. Much of the discussion is about product cost and
keeping it low. There is also emphasis on minimal design, that is, design that just
meets customer goals without adding gold plating. The present discussion further
promotes that emphasis.
To introduce the method called variation analysis, we present a simple example. Once
you understand this example, you may find the method useful in more complex
problems. It has been used by several project teams in problems far more complex
than the simple example shown here.
Consider a situation where an orifice will be used to closely control the amount of flow of
a liquid in a machine. Hundreds of the machines will be built and sold. We want the
cost to be as low as possible. The rate of flow through the orifice Q is governed by the
following equation which has been derived from accepted principles of fluid mechanics:
Q = 0.05 * d2 * P1/2
Here Q is the rate of flow in cubic feet per second (cfs), d is the diameter of the (round)
orifice in inches and P is the upstream pressure in pounds per square inch (psi). Note
that only d and P control Q. If Q must be controlled accurately, then the accuracy of Q
will in some sense depend on the accuracy of d and P.
Shortly we will explore how this can be evaluated. But first we take note of a well
known phenomenon in industryaccuracy costs money. Following the principle of
minimal design enunciated in chapter 10, we dont want any more accuracy than we
need to satisfy customer goals. This notion goes against the grain with many design
engineers, who are culturally prone to putting expensive accuracy requirements into

Page 180 of 199

drawings and specifications, apparently out of habit. Some even think this is good
engineering.
If the accuracy of more than one parameter must be considered in determining the
accuracy of the product (as is the case with the orifice discharge problem we are
considering), then a tradeoff may exist as to which parameters can most beneficially
have looser tolerances in order to keep costs down. Such will turn out to be the case
with our simple orifice example.
The relationship between cost and accuracy can take several forms, anywhere from a
simple straight line relationship to a curve with a knee as illustrated in Exhibit C-4.
Exhibit C-4Typical Curve with Knee
Cost
120
100
80
60
40
20
0
0

0.2

0.4

0.6

0.8

Permitted Error

(Note: the numbers on the axes in Exhibit C-4 have no significance. They are for
illustration only.) When the cost vs. permitted error relationship has a pronounced knee
as in Exhibit C-4, its important to try to stay to the right of the knee if at all possible. In
this example, note that if we allow permitted error to be greater than about 0.23 (note
the short vertical line in the exhibit), costs remain below 20 (arbitrary cost units). And
they change only gradually as tolerance of error changes. Theres not much difference
in cost between a permitted error of 0.5 and 0.6. But if permitted error is forced to go
below 0.23, costs rise sharply. There is a huge difference in cost between a permitted
error of 0.2 and 0.1. This is illustrative of the knee of the curve phenomenon that occurs
in many tradeoffs of cost versus accuracy.
Let us suppose that the nominal pressure we will work with is 10 pounds per square
inch and that the nominal diameter of the orifice is 2 inches. The pressure will be
controlled by a purchased pressure regulator and the orifice will be shaped by internal
grinding of a hole in a steel plate. Based on the above formula the flow we will achieve
with this diameter and this pressure will be:
Q = (0.05)(22)(101/2) = 0.63 cfs

Page 181 of 199

Let us further suppose that we need to keep the flow within 0.0945 cfs (15%) of this
value in order to meet customer goals. This requirement clearly will drive the tolerances
we must impose on d and on P, and will also drive the cost we must pay because
accuracy is expensive. But we will want to keep the cost as low as possible.
Suppose we find that tolerances as tight as 0.002 inches for the orifice are readily
obtained for $100 an orifice (this is hypothetical, of course).23 We assume that looser
tolerances do not significantly decrease cost. But for tolerances tighter than 0.002
inches costs increase significantly. We find after a bit of research that the following
linear equation closely approximates the cost effect for tighter tolerances.
Orifice cost $ = 310 105*(tolerance in thousandths of an inch)
The tightest practical tolerance is 0.0001 inches, so our range of interest is from
0.0001 inches to 0.002 inches. Cost per orifice over this range of interest is plotted in
Exhibit C-5.
Exhibit C-5Cost of Orifice vs. Tolerance
Cost $ per orifice
300
250
200
150
100
0

0.5

1.5

Tolerance in thousandths of an inch

We next consider pressure regulators. Let us (hypothetically) suppose that a survey of

vendors turns up suitable regulators with accuracy of regulation ranging from 0.1% to
10% of the desired pressure. After obtaining several vendor quotes and doing a
regression analysis on the resulting data we determine that the following equation is a
good fit to the data:
Regulator cost $ = 100*(10*regulation error in psi)-0.3
Exhibit C-6 plots the regulator cost versus the error in psi.
Exhibit C-5Cost of Regulator vs. Tolerance

23

The American Society of Mechanical Engineers (ASME) and other organizations publish research into
machining costs and the cost effects of tighter tolerances.

Page 182 of 199

Cost $ per regulator

200
150
100
50
0
0

0.2

0.4

0.6

0.8

Tolerance in psi

Now we introduce the means for connecting the errors in the orifice and in the pressure
regulator to the errors in the flow quantity. It is known to statisticians as the propagation
of error formula. Although it probably is of most interest to engineers and scientists, it is
not discussed in many statistics texts written specifically for engineers and scientists.
Readers interested in further pursuing it may have to look in several books to find it.
Our source is Basic Statistical Methods for Engineers and Scientists by Neville and
Kennedy, second printing, published in 1966 by International Textbook Company,
Scranton, PA.
Readers having some familiarity with statistical methods may recall that if two random
variables are independent, then the variance of their sum is equal to the sum of their
variances, thus:
x+y2 = x2 + y2
This is a special case of the more general propagation of error formula that is not limited
to sums. It can cope with many types of continuous functional relationships and can
deal with two or more variables that contribute to error. The expression of this
relationship we will use is:
Q2 = (Q/d)2 d2 + (Q/P)2 P2
The propagation of error formula as applied to our flow control example states that the
variance in flow [Q2] is equal to the variance in orifice diameter [d2] multiplied by the
square of the partial derivative of Q with respect to d [(Q/d)2] plus the variance of P
[P2] multiplied by the square of the partial derivative of Q with respect to P.
As previously noted, we have a formula relating Q to d and P, namely:
Q = 0.05 * d2 * P1/2
Taking partial derivatives, evaluating at the nominal diameter and pressure and
squaring the results leads to:
Q2 = 0.4 d2 + 0.001 P2

Page 183 of 199

Note the coefficients of the variance terms on the right hand side of this equation. The
coefficient 0.4 is 4,000 times the size of the coefficient 0.001. This is a clue that the
error in diameter of the orifice will be of much more significance than the error in
regulated pressure. Mostly this is due to the fact that diameter is squared in the
underlying equation, while the influence of pressure varies only as the square root. In
general, the error effects of variables that are raised to higher powers or that are
exponential in nature will have more impact than linear variables or variables that are
raised to lower powers. This intuitively makes sense.
How do we evaluate the variances on the right hand side of the formula? We can
consider both d and P to be normally distributed with means 2 inches and 10 psi
respectively, and consider their variances to be related to the tolerances we impose.
For example, suppose we impose a tolerance of 0.001 inches on the orifice diameter.
Because of the assumption of a normal distribution, we can conveniently consider 0.001
inches to be equivalent to three standard deviations (see any decent introductory text
on statistics). One standard deviation is therefore 0.001/3 = 0.00033 in. The variance
is defined as the square of the standard deviation, therefore assigning a tolerance of
0.001 in results in a variance of (0.00033)2 or 1.111E-7 in2.
We can easily construct a simple formula for what we just demonstrated.
d2 = (T/3)2
Here T is the one-sided tolerance we have imposed. By one-sided we mean that if we
have imposed 0.001 inches, then T = 0.001. This formula is perfectly general and is
valid for the assumption of a normally distributed error. It is reasonably accurate for
many non-normal distributions that occur in practice.
We can now rewrite our previous equation in terms of assigned tolerances:
Q2 = 0.4 (Td/3)2 + 0.001 (TP/3)2
We are ultimately interested not in the variance of Q, but in its standard deviation. We
can obtain that by taking the square root of the above. At the same time, we convert Q
to its tolerance equivalent using Q = TQ/3:
TQ = 3[0.4 (Td/3)2 + 0.001 (TP/3)2]1/2
Lets define two additional variables:
Cd = cost of one orifice of diameter d
CP = cost of one pressure regulator

Page 184 of 199

We can now write two previously developed equations in terms of our newly defined
variables, and create yet another useful equation, this time for the total cost, Ctot:
Cd = 310 105Td
CP = 100(10TP)-0.3
Ctot = Cd + CP = 310 105Td + 100(10TP)-0.3
Lets summarize what we have done to this point. We have developed the following two
equations that we will use to minimize total cost:
TQ = 3[0.4 (Td/3)2 + 0.001 (TP/3)2]1/2
Ctot = 310 105Td + 100(10TP)-0.3
We have also established the following constraint:
0 TQ 0.0945 cfs
Additionally we have established the following practical ranges that are effectively
constraints:
0.1 Td 2 thousandths of an inch
0.01 TP 1 psi
What we now have is a rather complicated constrained non-linear optimization problem
in which we want to minimize Ctot subject to constraints on TQ, Td, and TP. Elegant
techniques exist for solving such problems, and in a more complex problem than this
one their use may be warranted. Here we will use a very inelegant approach. We will
create a spreadsheet containing both the TQ equation and the Ctot equation and proceed
by trial and error by entering various values of Td and TP within their allowable ranges.
There is no guarantee that this method will find an absolute minimum but it can come
very close with a few minutes of exploration of the trade space.
In the particular problem we are dealing with, the cost is much more sensitive to orifice
diameter than to pressure control. Our intuitive trial and error search strategy begins by
using the cheapest regulator then tightening the diameter tolerance until the constraint
on Q is met. Then we explore that vicinity until the constraint is satisfied and we get the
lowest cost we can find. Exhibit C-7 shows the simple spreadsheet we used in this
search, and the solution we quickly found.
A second approach was to use Monte Carlo simulation in a spreadsheet to rapidly try
many combinations of tolerances. This approach is essentially computer-aided trial and
error. The best solution we found in 5,000 simulations was less than a dollar away from

Page 185 of 199

our intuitive solution, but when a problem gets more complicated than this simple
example Monte Carlo will be far more reliable and faster than an intuitive search.
The simulations ran in less than a minute. We did have to spend about an hour
programming a macro in the VBA language to automate the Monte Carlo.
Exhibit C-7Manual Search Spreadsheet
Minimization of total cost
0.14
1

=Td (0.1-2 thousandths in)

=TP (0.01-1 psi)

0.094021 =TQ (0.0945 cfm)

=Ctot $
$345

In closing, we should note that engineers generally do a good job of developing the
basic design solution. Where they are most likely to go wrong is in developing a
solution that is too good. This can raise costs and damage chances of having the
winning bid. The method of variation analysis can make a unique contribution to
avoiding that unfortunate situation.

Page 186 of 199

Appendix D -- Cost estimating checklist

This book is about pursuit, capture, and management of complex and/or high
technology projects, in which the low bidder is not necessarily the winner. These
projects are much more prone to cost and schedule overruns than other types of
projects.
There appear to be two reasons for this: 1) the projects are inherently risky because of
their subject matter and 2) the cost and schedule estimating efforts are too casual. By
the latter we mean they either do not have sufficient rigor, or they have insufficient
management controls, or both. Because they frequently are very important projects,
cost and schedule estimating management is often impeded by political considerations
that interfere with proper management controls.
While no checklist is guaranteed to withstand a full frontal assault by a pursuit team that
already knows the answer it wants before it starts to estimate, the checklist here
discussed does make an effort to do just that. If its conditions and strictures are strongly
upheld by management, realistic estimates are likely to emerge.
For readers used to simply slapping on some percentage of direct cost provided by the
accounting department and calling that an estimate of overhead costs, this checklist will
surprise. It requires explicit consideration of the need for overhead resources, and an
estimate of their costs. This estimate is compared to the percentage estimate normally
made as a check of its deficiency or its surplus. It is also useful in risk analysis (see
chapter 14).
This checklist may surprise in other ways as well. It calls for a degree of rigor in several
areas that may not be customary to some readers. In particular, it calls for tight
management of the supporting documentation and deep consideration of project risks
and their potential for creating cost and schedule overruns.
All project cost estimates are essentially estimates of the underlying resources needed
to perform the project, which are then converted to units of currency, e.g., dollars.
Resources commonly used to complete a project include land, labor, material, services,
equipment, buildings, infrastructure, and time. One reason for project overruns is that
one or more of these resource needs is overlooked or misunderstood and its cost is
totally or partially left out of the estimate, or is estimated inappropriately. As a prelude
to forming the checklist, lets briefly consider each one of these resources.

Land
Land is essentially space on our planet for which there are competing interests or
uses. We may be at liberty to use a space on the Antarctic continent cost free, because
nobody else wants to use it. The same may apply to vast regions of the ocean floor, or
of the ocean itself. But if the land we contemplate using has some kind of prior claim of
use or ownership, we may have to pay to use it. In some projects, the land used is

Page 187 of 199

provided by or its use is arranged by the customer, nominally free to the project
performer. Nevertheless, there could be costs to the performer if use of the land must
be scheduled at inconvenient times, or if there are other restrictions on use.
Generally, if the project contemplates any significant modification of the land belonging
to others, such as mining it, or building a road across it, reshaping it, or planting trees or
crops on it, there will be use costs of some kind. For some types of use, there could be
taxes.
These days, a not infrequent restriction on the use of land is due to environmental
considerations, such as preservation of wildlife habitat or special scenic beauty.
Another type of restriction is when land is already environmentally damaged, and further
use is limited or denied because of hazards, or to prevent additional damage.

Labor
The largest single cost in an advanced project is usually labor cost. Ordinarily, cost of
labor is deemed to include wages and salaries, fringe benefits, and employer paid
payroll taxes such as Social Security and unemployment or disability benefits or
insurance.
In many organizations, labor is divided into direct and indirect. Direct labor is deemed
to be labor that is directly involved with the product, while indirect labor is all other labor
that supports the product. In and of itself, this bifurcation is not harmful. What can be
harmful, at least from a cost estimating standpoint, is the accounting treatment typically
applied to indirect labor. According to commonly applied accounting rules its costs,
company-wide, are collected and applied to direct labor as a burden percentage. This
practice frequently distorts the true cost of a project. We will have more to say about
this later in this appendix.
Typically, project labor is grouped into certain skill codes, depending on intended use.
When this done, an average labor rate may be determined for each skill code, and that
average is applied to each individual person having that code working on the project.
This practice too can introduce errors in an estimate if the project team is not average
in its composition.
Most commonly, labor costs are expressed as dollars (or other currency units) per hour,
although for certain situations units of time other than hours may be preferred.

Material
Material is any good purchased for use on the project. Two types are usually
recognized: 1) expendables, and 2) material that becomes part of the product. The
assigned cost virtually always includes the full purchase cost, and may also include
freight, sales taxes, value added taxes, and various kinds of customs duties, handling,
quality inspection, or inventory charges.

Page 188 of 199

Expendables typically include items such as office supplies, cleaning supplies,
lubricants, process chemicals, and supplies for minor repairs. Material that becomes
part of the product may include raw material, finished products such as forgings or
castings, or assemblies or components of various kinds, such as fasteners and
electronic components or mechanisms. It may also include paint and other finishing
material, and material to create shipping containers. Sometimes, purchased software is
regarded as material.
Commonly, the entire cost of a subcontract will be regarded as a material cost,
regardless of the amount of labor the supplier puts into it. Here there is need for
caution, however, because in certain teaming arrangements, it may be desirable to
consider a subcontractors labor to be part of your labor cost, especially if the
subcontractor works on your premises. Similarly, while consultants are often classified
as a service, some companies treat them as material costs, and others treat them as
part of their own labor force.

Services
The dominant services cost in advanced contracts is usually travel, or items related to
travel. Sometimes freight costs are treated as a service, and sometimes so are
consultants. Miscellaneous items related to travel are frequently treated as a service,
such as employee relocation costs, costs of medical examinations prior to hiring, going
to a foreign country, and so forth. Foreign currency exchanges could be a service. So
could legal fees, aircraft landing fees, ships harbor fees, import and export duties, etc.
Costs of utilities, such as electricity, natural gas, fuel oil, etc., are often regarded as a
service. Maintenance costs of equipment, buildings, and infrastructure are also often
regarded as a service.

Equipment
A distinction often made with regard to equipment is capital equipment versus noncapital equipment. The term capital equipment is generally reserved for equipment
with a life of at least one year that is used to assist in producing or selling a product, or
performing a service. It should also have a cost in excess of a stated amount,
commonly $5,000, although this varies from firm to firm. This cost generally includes
the purchase cost and all other costs of acquisition.
Non-capital equipment is every other kind of equipment.
Accountants generally depreciate capital equipment over a period of years, and
immediately expense non-capital equipment.
Generally, expensed equipment is charged directly to a project. Capital equipment
depreciation is often charged directly to a project for the period of time it is used by the
project. Alternately, all capital equipment could be put into a pool, and allocated to
individual projects in some manner.

Page 189 of 199

Buildings
Generally, a building is any man-made structure intended for human occupation or as a
work place or for storage. Like capital equipment, accountants typically depreciate the
cost of a building over a period of years. The cost of the land supporting a building is
not depreciated.
Generally, depreciation of a building is charged to a project for the part of the building
and the period of time it is used by the project.

Infrastructure
Infrastructure is the physical systems and structures, other than buildings, needed for a
project to perform its work. It includes roads, water supply, sewers, electrical power
grids, telecommunications, and the like.
Generally, if infrastructure is built for the use of a project, the contract will specify
ownership and disposition of it when the project ends. If a project makes use of existing
infrastructure, there may be depreciation charges or other fees charged for that use.

Time
The simple passage of time generally creates charges to a project only if resources are
being used which have costs that are based on the passage of time. Thus labor is
generally charged, even if unproductive, if the people must be present and available but
cannot work. Real estate rents and leases are also based on time. So are equipment
rentals.
Sometimes project contracts contain penalty clauses such that payments to the
performer are reduced if too much time is consumed. Alternately, there may be
incentive payments if less than the planned time is used.
In some multi-year projects, the time value of money plays a role, as does the
phenomenon of inflation. To the extent that either of these is important, estimators must
account for them.
Project estimates must take all of these costs, or related cost affecting factors into
account. Given competent estimating staff, they generally they do, but not always in a
manner which minimizes projects costs, thus increasing win probability. For that
reason, the checklist provided here contains some requirements that may at first seem
unusual.

Page 190 of 199

Estimating Checklist
The Cost Proposal Book
1. Documentation of the entire process described in this checklist shall be maintained
in an electronic Cost Proposal Book, which shall serve as a permanent, complete
history of the development of the bid amount. The book shall include a roster of
pursuit team members and the roles they played.
Cost discipline process
1. At the beginning of the pursuit process, the pursuit leader shall decide upon and
shall establish in writing a cost discipline process to be applied to the pursuit and to
the project if captured. It may be a variant of design to cost, cost as independent
variable or other recognized process. The defining document shall state the goals of
the process and shall assign responsibilities and specific actions to be taken. It shall
describe in detail how bases of estimates and quality of estimate assessments are to
be done.
Estimating team composition and prerogatives
1. The estimating team shall have a lead estimator who has led, or has assisted in
leading, at least one similar estimate.
2. There must be an estimating team of sufficient size to accomplish the estimate
without resorting to compression of the estimating schedule. The lead estimator
shall be the judge of the size of the team and the skills required to be on the team.
3. The time made available to the team to create and check the estimate must take into
consideration both the size and complexity of the project, and the variety of cost
details and reports required by the customer and by management. The lead
estimator shall be the judge of the time required.
4. The estimating team shall have available to it all tools that have been used in the
past to prepare successful estimates, including computers, parametric estimating
models, historical data for completed similar projects, spreadsheets, word
processors, presentation tools, well lit, comfortable work spaces where all estimating
team members can be co-located, telephones, a fax machine, and a copier.
5. The lead estimator shall have at least a bachelors degree from a properly
accredited school in a business subject, or an engineering subject, or mathematics,
or a physical science.
6. In addition to the lead estimator, there shall also be an assistant lead estimator who
has at least a bachelors degree from a properly accredited school in a business
subject, or an engineering subject, or mathematics, or a physical science, as well as
at least five years of experience in estimating similar projects.
7. The lead estimator and the assistant lead estimator both shall have been thoroughly
briefed on the cost definition and allocation methods approved for use in their
organization by their organizations accounting staff.

Page 191 of 199

8. The lead estimator and the assistant lead estimator both shall have been thoroughly
briefed on the human and other resources available for use in the project being
estimated.
9. An experienced systems engineer or other senior technical person in the proposal
technical team shall be designated to assist the lead estimator in interpretation of
technical information related to the project, and in creating bases of estimates. This
shall be the highest priority of this technical person, who shall put no other duties
ahead of this obligation.
10. If manufacturing is to be estimated, a senior manufacturing engineer in the
manufacturing team shall be designated to assist the lead estimator in the
interpretation of manufacturing information related to the project and in creating
bases of estimates. This shall be the highest priority of this engineer, who shall put
no other duties ahead of this obligation.
11. If there are to be subcontracts, or significant material purchases, a senior purchasing
agent shall be designated to assist the lead estimator in acquisition of vendor cost
data related to the project and in creation of bases of estimates. This shall be the
highest priority of this agent, who shall put no other duties ahead of this obligation.
12. For each parametric cost estimating model or accounting style cost model used by
the team, the team must include at least one estimator with at least three years of
estimating experience, who has at least a week of formal training in the model, to
assure that model entries are made correctly, and model results are properly
interpreted.
13. The lead estimator and the estimating team are members of the pursuit team but
shall report directly to an executive who is senior to the pursuit leader, and who has
final authority as to the amount to be bid. This person is the Bid Executive and his
or her decisions relative to bid amount shall be final.
Project scope determination
1. The pursuit leader shall within one month of the beginning of the pursuit cycle create
or cause to be created and shall make available to the pursuit team and to the lead
estimator a document to be called the Project Scope Dictionary (PSD). This
document shall be updated weekly throughout the pursuit cycle to keep it current. A
brief summary of the nature of each update shall promptly be sent to members of the
pursuit team and to the lead estimator. Each update shall be given a unique revision
number and date, and it shall always be possible at a future time to readily establish
the exact contents of a previous update. The PSD shall contain or shall refer to the
location of each of the following ancillary documents:
a. Customer Goals Database (CGD), a database which collects all known
customer goals, and which indicates how each one was confirmed as being
valid. It shall also describe all goal ambiguities, possible mistakes in goal
statements, and goal conflicts not yet resolved with the customer, plus
statements of how problems with ambiguous or conflicting goals were
resolved.

Page 192 of 199

b. Proof of Compliance Matrix (PCM), a document that describes how in the
proposal the pursuit team will credibly defend compliance with each entry in
the CGD.
c. Product Work Breakdown Structure (PWBS), which shall contain a
hierarchical listing not fewer than three or more than six levels deep of every
item of hardware, software, and documentation required to be delivered under
the contract.
d. PWBS Dictionary, which shall describe the nature of the contents of each
element of the PWBS in sufficient detail that a member of the pursuit team or
the estimating team can readily determine to which system or subsystem any
element of project hardware or software belongs, once its function is stated.
e. Project Master Schedule (PMS), which shall as a minimum contain the
planned start and finish dates of every development and production task in
the PWBS. The PMS shall also identify the points in time when completion of
defense of each element of the PCM is expected to be complete.
f. Current Product Design Baseline (CPDB), which shall be that set of drawings,
specifications, trade study reports, and other documentation that defines and
justifies the current product design baseline. The CPDB shall identify any
design feature about which there is significant lack of certainty as to how it will
be designed or procured, and further will set forth the design issues involved
and the planned actions to resolve them.
2. Not later than five days after initial issuance of the PSD, the pursuit leader shall
identify for the lead estimator all buy items of the PWBS, the names of the
proposed vendors, and the proposed terms and conditions of the purchase to the
extent they are known, including when during the project the purchase is expected to
be made. As additional information about each buy item becomes available, it shall
be promptly passed to the lead estimator.
3. The pursuit leader shall within one month of the beginning of the pursuit cycle create
or cause to be created and shall make available to the pursuit team and to the lead
estimator the Project Indirect Scope Dictionary (PISD). The PISD shall be updated
monthly throughout the pursuit cycle to keep it current. A brief summary of the
nature of each update shall promptly be sent to members of the pursuit team and to
the lead estimator. The PISD shall contain or shall refer to the location of each of
the following ancillary documents:
a. Indirect Customer Goals Database (ICGD), a database which collects that
subset of all known customer goals expected to have a material effect on the
amount or kind of indirect support required by the project, and which indicates
how each one was confirmed as being valid. It shall also indicate and
describe the presence of any goal ambiguities, possible mistakes in goal
statements, or goal conflicts not yet resolved with the customer.
b. Indirect Support Functional Breakdown Structure (ISFBS), which shall contain
a hierarchical listing not fewer than two nor more than four levels deep of
every activity customarily charged to indirect cost (overhead) that will be
needed to support the project, including but not necessarily limited to:
i. Land
ii. Labor (by function)

Page 193 of 199

iii.
iv.
v.
vi.
vii.
viii.

Material (by type)

Services
Capital equipment
Expensed equipment
Buildings
Infrastructure

Competitive bid range analysis and profit goal

1. As early as possible in the pursuit cycle, but not later than one month into the cycle,
the pursuit leader shall determine and disclose to the lead estimator his or her
assessment of the lower and upper limits of the competitive bid range, together with
the entire analysis (in writing) used to determine these values.
2. As early as possible in the pursuit cycle, but not later than one month into the cycle,
the pursuit leader shall determine and disclose to the lead estimator his or her
assessment of the profit goal for the project expressed as a currency amount, e.g.,
dollars.
3. If circumstances are such that the assessments of the competitive bid range or of
the profit goal change during the pursuit cycle, the pursuit leader shall immediately
notify the lead estimator, and shall supply in writing the analysis leading to the
change.
Resource estimating, risk analysis, and Best Bid analysis
1. The initial Project Direct Cost Estimate (PDCE), to be known as the PDCE1
estimate, shall be prepared by the estimating team not later than three weeks into
the pursuit cycle. It shall use parametric and/or analogy methods, and vendor
submittals, to the extent possible, and shall include fully burdened direct cost values
for every WBS element. It shall be based on the current project baseline, i.e., the
current PDSD as previously defined. Portions of the estimate made at the lowest
level of the WBS shall be rolled up, and portions made at higher levels of the WBS
shall be allocated down using rational methods.
2. A quantitative risk analysis shall be applied to the PDCE1 using the Bid to Win
Simplified Risk Analysis method or equivalent (See Exhibit 14-2). Inputs to the risk
analysis shall be approved by both the pursuit leader and the lead cost analyst. Any
disagreements shall be resolved by the Bid Executive.
3. The PDCE1 estimate was made at an essentially unknown confidence level. The
risk analysis shall be used to adjust it to the 50% confidence level.
4. A Best Bid analysis shall be performed using the Best Bid model or equivalent and
the results of the BDCE and the quantitative risk analysis.
5. The results from PDCE1 and its associated risk analysis and Best Bid analysis shall
be updated and compared to the prevailing DTC standard each time the PDSD is
revised. These updates shall be designated PDCE2, PDCE3, etc. For each new
estimate steps 2, 3, and 4 above shall be repeated.
Indirect support analysis

Page 194 of 199

1. Determine from each of the estimates PDCE1, PDCE2, etc. the amount of overhead
allocated cost included.
2. Based on the current PISD separately estimate the cost of all overhead activity
planned for the project, and compare it to the current allocation.
3. Consider possible corrective action if the discrepancy is large.

Final review
1. When the sequence of estimates PDCE1, PDCE2, etc. has stabilized at values
acceptable to the Bid Executive, there shall be a final bottom up review.
2. In the bottom up review, the lead persons (e.g., lead engineers, managers,
subcontracts specialists, etc.) who contributed to the estimate shall all independently
review the Cost Proposal Book, and shall either sign off on it as being acceptable, or
shall create written objections. All written objections shall be disposed of by the Bid
Executive, whose decisions shall be final.