Bid to Win: A Guide to Pursuit, Capture, and Management of Unprecedented or High Technology Projects

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.

http://www.galorath.com/

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, non-exclusive, 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 1—Use early start business development practices .................................................. 8 Chapter 2—Understand 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 5—Measure customer value judgments .................................................................. 30 Chapter 6—Create customer satisfaction.............................................................................. 37

Chapter 7—Persuade your customer away from mistakes ................................................... 41 III Know What Your Customer Is Willing to Spend ................................................................... 49

Chapter 8—Find the upper and lower bid limits .................................................................. 49 IV Design Your Project ............................................................................................................... 54

Chapter 9—Use modern programmatic design techniques .................................................. 54 Chapter 10—Find minimal balanced and efficient product design solutions ....................... 67 Chapter 11—Apply cost containment discipline .................................................................. 73

V Bulletproof Your Proposal ...................................................................................................... 84 Chapter 12—Analyze your competitors ............................................................................... 84

Chapter 13—Work the toughest issue: how much to bid? ................................................... 87 Chapter 14—Analyze and abate project risks ....................................................................... 93 Chapter 15—Get all of the right things into your proposal ................................................ 108

Chapter 16—Keep the proposal going ................................................................................ 113

VI For the Future ....................................................................................................................... 115 Chapter 17—Keeping the game going ................................................................................ 115 Chapter 18—The 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

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 contracts. Larger service contracts of various kinds may also come under this umbrella. Excluded are all contracts where the low bidder automatically wins. Some bidding situations where this book may be useful are shown nearby. As a member of an advanced contracting project team, to survive you must win projects in open competition. Your work is “high tech” or unique in that what your customers want is not routine, either for you or for them. In bidding competitions that you enter, the low bidder generally wins the contract, but not if the bid is so low that the customer believes it to be reckless and non-responsive, or if the low bid is based on a concept the customer views as not meeting perceived needs. You can’t win every job you bid, but you must win your “share,” or risk having to go out of the contracting business. A long dry spell with no wins could be fatal. In the bidding competitions you enter, “project design” is important in many ways. Project design comprises both the design of the deliverable product and the means you choose to develop and implement it. It drives cost and therefore the amount you must bid in order to be profitable. 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 customer’s needs, and fully provide for them, and you must do it in a way that is highly visible and cost effective.

Exhibit P-1 Bidding Situations Where This Book

May Be Useful

Aerospace

Agency

Catering

Communications

Concessions

Construction

Defense

Environment

Housing

Insurance

Legal Services

Maintenance

Outfitting

Security

Special Analyses

Testing

Training

Transportation

Upgrades

Anywhere factors other than

cost influence the award

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.

of 199

Regardless of your strategy you can’t expect to win it all, all of the time. The world doesn’t 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 can’t 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 customer’s ability to pay. Persuade the customer away from mistakes1. Exhibit P-2—Pursuit Cycle

1 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, don’t 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.

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 customer’s rejection of the contractor’s 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 contractor’s 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.

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 Start—this 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 Wants—customers 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 Spend—the better you understand your customer’s 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 Project—in 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 Proposal—your proposal will be “shot at” in your competitor’s proposals and may be criticized by members of your customer’s 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 Future—Thoughts on planning between proposals. More thoughts on balancing profitability and stability.

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 don’t have just one set answer. The best answer may depend on your particular circumstances.

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 1960’s, 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.

http://www.galorath.com/

of 199

I Get Off to the Right Start

Chapter 1—Use 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 bidder’s 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 haven’t nearly the detailed understanding of what the customer wants and what his priorities are. They may have a

2 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.

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 bidder’s 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. 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

Potential and

existing

customersContracts

Top

Mgmt

Bus Dev

Key

Tech

Exhibit 1-1—

Integrated Project

Team for Business

Development

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.

3 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.

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 company’s 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 company’s 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 competitor’s 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.

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.)

of 199

Chapter 2—Understand who the customer is

Why it is necessary to have a chapter such as this? Surely we know who the customer is. Everybody knows it’s the Federal Aeronautical Commission on Safety. Or is it Xanadu Incorporated? Could it be both? Maybe it’s 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 it’s 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 it’s the legislature because of certain language in the authorizing legislation? Or, maybe it’s the airline industry because they lobbied hard for the robotic runway cleaner and will be watching its development closely. Or maybe in some ways it’s all of the above. The point emerging here is that you shouldn’t 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.

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.” Let’s 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. It’s 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 people’s

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 Decider’s 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. It’s 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?

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 Ma’m? 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.

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 don’t, 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 CEO’s 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 everyone’s 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. It’s 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!

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 don’t always have a clear and stable view of what they want. Let’s 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. Here’s 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.

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

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

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 customer’s 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 project’s 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?

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

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 subcontractor’s supply chain, and in the stability and reliability of the processes the subcontractor has in place. The skills and experience of the subcontractor’s 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?

of 199

II Know what your customer wants

Chapter 4 – Learn about and influence customer goals5

Customers don’t 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. That’s why you don’t 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 doesn’t 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 can’t 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. It’s the customer’s problem, after all. More importantly, it’s the customer’s 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 company’s 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 customer’s

5 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.

of 199

computers and doing a lot of damage. One of your researchers notices that a “healthyl” computer’s 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 don’t have to inquire into your customer’s 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 can’t always win a

6 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.

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 don’t 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 customer’s 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 can’t 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.

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 it’s 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.

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 dispersed among several organizations, and that these people may not speak entirely with one voice. Sorting out the most authoritative voices often requires considerable analysis of the available

evidence. Chapter 4 points out the importance of understanding the customer’s 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

Understand

who the

customer is

Compile

goals

Classify

goals

Resolve goal

conflicts

Critique goal

problems

Establish

customer goal

values

Manage goals

Exhibit 4-1—

Goal

Development

Process

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 non-responsive 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 customer’s 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 don’t 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

o Goals will be internally consistent—no conflicts between positive goals and no conflicts between negative goals

o 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.

of 199

If the customer does not manage goals well, you will not observe one or more of the above. Let’s 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.

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 don’t 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 contractor’s organization: top management, contracts, business development, and key technical people. All four areas should participate in customer visits. Here are some reasons why.

Exhibit 4-2 Goal Management

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 customer’s 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

of 199

Chapter 5—Measure 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-1—Example Customer Relative Value Assessment

Features Relative Value% Goal

Weight 20 5.9 pounds

Processor speed 9 800 mhz

Storage 9 300 mb RAM

Display 5 25"

Battery life 5 6 hours

Price 20 <$1,000

Warranty 5 3 years

Options for growth 13 Options #1, #2

Availability 14 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.

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-2—Example Customer Relative Value/Cost Assessment

Features Relative Value% Relative Cost Goal

Weight 20 35 5.9 pounds

Processor speed 9 7 800 mhz

Storage 9 6 300 mb RAM

Display 5 5 25"

Battery life 5 5 6 hours

Price 20 18 <$1,500

Warranty 5 5 3 years

Options for growth 13 11 Options #1, #2

Availability 14 8 1 Year

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

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 re-examine 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.

5 -- -----

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 customer’s scheme of values? You may find little information about this in your customer’s 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

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-3—Using Weighted Survey Data to Assess Importance to Customer

Parameter FACS Xanadu Customer Importance Weight Value Weight Value

Speed 0.6 x 0.4 + 0.4 x 0.3 = 36%

Altitude 0.6 x 0.1 + 0.4 x 0.2 = 14%

Payload 0.6 x 0.5 + 0.4 x 0.5 = 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-4—Using Weighted Survey Data to Assess the PDI

Parameter Engineering Project Management PDI

Weight Value Weight Value

Speed 0.7 x 0.5 + 0.3 x 0.4 = 47%

Altitude 0.7 x 0.2 + 0.3 x 0.3 = 23%

Payload 0.7 x 0.3 + 0.3 x 0.3 = 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-5—Combining Customer Importance and PDI

Parameter Customer Importance

PDI

Speed 36% 47%

Altitude 14% 23%

Payload 50% 30%

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

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. It’s 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? That’s 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 team’s 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 customer’s best interests. Cost and “difficulty” are just two possible comparisons you might want to make with the customer’s 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 team’s skills can be applied to assuring that the customer’s 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.

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 can’t 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?

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 can’t 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 doesn’t say so explicitly?

of 199

Chapter 6—Create 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. That’s 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.

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 didn’t, 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 hasn’t 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 can’t find the needed information, you should help find it. If it doesn’t 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 customer’s 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

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 don’t 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 meeting’s 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:

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 don’t 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 customer’s 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 doesn’t 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?

of 199

Chapter 7—Persuade 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, it’s necessary to do some rigorous self-examination to be reasonably sure it’s 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 it’s 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.

Don’t 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 that’s all there is, followed by strong

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 don’t 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 doesn’t have enough money and knows it, or a customer who doesn’t have enough money and doesn’t 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 customer’s 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 don’t 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:

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 customer’s risk. Failure to control the customer’s 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 customer’s 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, “I’m not sure what I want, but I’ll 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

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 didn’t 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. Here’s 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

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 didn’t 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 today’s 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 micromanagement—a 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.

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 design-specific 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. It’s a bit like having a snake sleeping under a sheet. You can’t see the snake, but you can tell there’s something under the sheet that doesn’t 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 project’s product. Whenever a specification is written in a confusing way, you should strongly suspect that whoever wrote it doesn’t 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)

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 don’t 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.

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 weren’t 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?

of 199

III Know What Your Customer Is Willing to Spend

Chapter 8—Find 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 customer’s 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.

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 customer’s 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 customer’s 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.

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 can’t 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 software’s 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.

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 ain’t 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 don’t 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.

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?

of 199

IV Design Your Project

Chapter 9—Use 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 Webster’s 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

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 don’t 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 project’s 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.

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 completed—only 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 today’s 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

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 accordingly—that 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.

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 customer’s 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.

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 # WBS Element Name 0 Total Aircraft 1 Fuselage 1.1 Nose Section 1.2 Center Section 1.3 Aft Section 2 Empennage 2.1 Vertical Fin 2.2 Left Horizontal Fin 2.3 Right Horizontal Fin 3 Wing 3.1 Primary Structure and Wing Box 3.2 Skins and Secondary Structure 3.3 Pylons 3.4 Nacelles 4 Propulsion 4.1 Engines 4.2 Fuel System 4.3 Fire Suppression System 5 Control System 5.1 Cockpit Controls 5.2 Autopilot 5.3 Actuators and Sensors 6 Landing Gear 7 Avionics

of 199

8 Environmental System 9 Fittings and Furnishings 10 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-2—Simple Sequential Schedule

Prepare kickoff briefing Jun 1

Present kickoff briefing Jun 8

Prepare list of subject matter experts Jun 9

Contact subject matter experts (SMEs) Jun 15

Prepare SME statements of work Aug 3

Negotiate SME statements of work Aug 12

Contract with SMEs Aug 22

SMEs prepare course materials Aug 30

Review and approve course materials Oct 15

Issue course materials Oct 28-Nov 5

8 See Appendix E for a discussion of the shortcomings of typical work breakdown structures, and what might be

done about them.

of 199

Exhibit 9-3—Simple Sequential Schedule Expressed as a Gantt Chart

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.

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

Start

Order Air Compressor

6 weeks, $20K

Construct Foundation

3 weeks, $5k

Order Piping

1 week, $15K

Order Controls

5 weeks, $15K

Install Air Compressor

1 week, $15K

Install Piping

4 weeks, $50K

Install Controls

4 weeks, $25K

Integrate & Test System

1 week, $15k Finish

Exhibit 9-4 Schedule—Tank Purging System Schedule

Manage Project

10 weeks, $60k

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 won’t 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

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 have—live 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 today’s computer dependent word a server or data line failure can put a project out of business, at least for a time.

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 on—project 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,

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 long-lead 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

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 team’s project planning is as thorough as it should be? What would you do to improve it?

of 199

Chapter 10—Find minimal balanced and efficient product design solutions

In chapter 4 we discussed how our product’s cost or difficulty distribution should reasonably reflect our customer’s 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 customer’s 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. It’s 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 customer’s 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 customer’s team may be risking sanctions.

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 don’t 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 doesn’t literally mean that the designer requires plating with precious yellow metals for items that don’t 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.

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 customer’s 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 customer’s 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 competing design will often meet them at lower cost. The other approach we will call “evolutionary” (see Exhibit 10-1 nearby). It begins with rank ordering the customer’s goals as was discussed in chapter 5. Create a design that focuses on meeting the top goal as minimally and efficiently as possible, just as 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

Exhibit 10-1 – Evolutionary versus typical design

Cost

Functionality

Functionality adequate for

customer

Evolutionary design

Typical design

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 competitor’s 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).

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 customer’s goals to the various elements of the product. Such allocations are commonly referred to as the product’s 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

of 199

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

of 199

Chapter 11—Apply 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 1970’s 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.

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 customer’s 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 don’t 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.)

of 199

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 (LCC—also called Total Ownership Cost or TOC) discipline concerns the total cost of a system from its earliest development through its ultimate retirement.

A 5 hours

B 2 hours

C 9 hours

Assembly 4 hours

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

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.

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: Concept.

Business (or threat) development.

Preliminary design.

Detail design.

Implementation.

Operations and support.

Retirement.

Time

Cost

Pro

file

Preliminary

Design

Detail

Design

Implementation

Operations and

Support Retirement

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 1980’s 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 can’t 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.

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 can’t, 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

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 don’t 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

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

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

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 don’t 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?

of 199

V Bulletproof Your Proposal

Chapter 12—Analyze 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 wouldn’t 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 competitor’s 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 competitor’s 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.

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, it’s 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 bidder’s lists, lists of attendees at bidder’s 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, it’s 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?

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.

of 199

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

The simple-minded, obvious approach to bidding is to read your customer’s 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 customer’s needs and that

the customer can afford (Chapters 10-11). Look at the competitive situation—how 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).

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:

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.)

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.

of 199

Of course, you and your competitors can’t 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 bidder’s management says “this is a must win for us—pull 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 competitor’s 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.

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. 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. Let’s 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. Let’s 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,

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

of 199

the harder it gets. In fact, for any value of N greater than 5, it’s 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 “Don’t 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

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, Sewell’s book is still an excellent source for ideas on pleasing customers.

of 199

Chapter 14—Analyze 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 project’s 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!

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.

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 don’t care much for them when they are full of clichés 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.)

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.

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.

Exhibit 14-1—Hypothetical Bidding Risk Analysis

Probability that cost will

not exceed given amount

Bid $ Millions

80 85 90 95 100 105 11511070

Competitive Bidding Range

Your current expected cost

estimate (contingency & profit

not included)

Win

Pro

babili

ty %

0

25

50

75

100 Competitive bid $91.2M

with 3 competitors—

win probability 25%

75

100%

50%

75%

25%

Cost Risk Range

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. Let’s 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.

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.

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-2—Example Risk Analysis

Bid to Win Simplified Risk Analysis

Probabilities of

Occurrence

Risk Adjusted Cost K$

Risk Impact

Variance

0.3 0.7 0.2

WBS Estimated Probable Cost $K

Risk Driver #1 Risk Driver #2 Risk Driver #3

Min Impact

Max Impact

Min Impact

Max Impact

Min Impact

Max Impact

1 41.6 -1 14 -6 -1 42.85 6.041667

2 12.5 2 6 4 7 17.55 0.925

3 38.7 -12 5 12 20 40.85 8.291667

4 6 1 2 7.05 0.058333

5 11.9 8 12 3 10 16.2 1.216667

6 76.6 -12 5 1 5 77.65 8.158333

7 18 -2 3 18.1 0.416667

8 13.7 5 8 15 0.15

9 44.6 12 21 8 20 52.35 4.425

10 25.8 7 11 -4 1 31.8 1.35

Total 289.4 ^^ Impacts K$ ^^ 319.4 31.03333

Cost risk range (mean ± 3 standard deviations 302.6877 319.4 336.1123

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.

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

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 “self-insurance” 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 month’s 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 can’t 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 contractor’s “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

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 doesn’t 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.

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 everyone’s 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 sponsor’s 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

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

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 Chesterton’s worldview, and also with Dwight Eisenhower’s, 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 world’s “special forces” and SWAT teams, those groups of rough men and women who handle the really bad guys so that the rest of us won’t 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 B’s 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.

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 Carnegie-Mellon 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 judgment-based contingency amounts. The first is a “just in case” amount to cover any missed items. The second is an amount they don’t 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?

of 199

Chapter 15—Get 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 customer’s 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

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? It’s 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

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 don’t 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 competitor’s 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 customer’s upper limit, you certainly want to be below it. If you don’t 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.

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 can’t demolish a competitor’s 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 it’s 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. Here’s 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.

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 “can’t 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?

of 199

Chapter 16—Keep 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. Let’s 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 customer’s 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 competitor’s 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%?

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, don’t 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. You’ve 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?

of 199

VI For the Future

Chapter 17—Keeping 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 d’etre 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 contractor’s facilities.

Location of principal subcontractor facilities.

of 199

Level of unemployment in contractor’s locale.

Contractor’s present workload and work capacity.

Recent similar contract awards.

Contractor’s technical and managerial reputation.

Size and resources of contractor’s 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 cost-plus-fixed-fee with incentives. When a request for proposal specifies one of the cost-plus-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.

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 contractor’s 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 year’s 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.

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 firm’s 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 firm’s 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 firm’s 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.

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

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.

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 TEK-R-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.

of 199

Chapter 18—The 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 firm’s 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.

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 Markowitz’s 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:

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

Option Bid W% ENPV EVOL

1 4786 31 55.25 82.43

2 4929 30 67.63 103.31

3 5080 27 74.17 121.96

4 5232 21 68.43 132.72

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.

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 don’t 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 University’s 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

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 occur—catch 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.

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

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.

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-1—Typical Differences between Manufacturing and Service Processes

Features Manufacturing Service & Support Operations

Ownership Clearly defined Undefined or unclear

Boundaries Clearly defined Undefined or unclear

Documentation Well documented Little or no documentation

Measurements Consistent; quantitative None or qualitative

Deviation control Consistent; based on data 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.

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.

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 X’s.

Exhibit A-2--Example of Responsibility Matrix

Input Required Mfg Engrg Finance

Indirect labor hours X X

Direct labor hours X X

Absent hours X X

Sick hours X X

Capital budget X X X

Maintenance hours X

Computer usage hours X X X

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.

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.

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

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).

of 199

Exhibit A-3--Process Measurement Chart Outline

Process step (Activity Name)

Control parameter(s) Unit of measure Frequency

A1-Document inspection

Document defects -Missing -Illegible -Out of sequence

Percent of total errors by category

Every job (100% inspection)

A2...

A3...

Exhibit A-4—Example Process Flow Chart

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.

Process Flow for Production of Internal Training

Documents

Certify need for

internal training

Create course

syllabus

Review and

approve syllabus

Draft course

documents

Inspect course

documents

Publish course

documents

Syllabus

Approved

Rejected

DocumentsRejectedApproved

of 199

Exhibit A-5—Example Process Output Tracking Chart

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.

Control Chart for Internal Training Document

Production

Total

Defects per

1000 words

Goal

Thousands of words

published

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?

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

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

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 PhD’s 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

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. Let’s 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 T-shaped 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 multi-disciplinary approach is central to the way crews are trained in the U.S. Navy’s 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 ship’s 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 don’t know. The idea here is that team

members live examined lives, following Aristotle’s 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 it’s 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 further—each team member must understand what the other team members can do, and what they can’t. In critical projects, the coach can’t be everywhere. When a problem arises that a team member doesn’t 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 can’t 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.

of 199

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

Fast execution. Have you ever watched a professional baseball team do its warm-

ups? It’s 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 won’t 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 don’t 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 it’s a death march project by the number of empty pizza boxes you can see in the project offices at two o’clock 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

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 don’t 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 “It’s 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.

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 team’s 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.

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 lead’s 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.

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 couldn’t 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.

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

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. That’s 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. It’s 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, it’s back to the drawing board until the team gets it right. Compared to the

Market

Research

Product

Characteristics

Design

Engineering

Supplier

Pricing

Cost

Too

High? Manufacturing

Yes No

Further Cost

Reductions

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 customer’s 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-2—Japanese Approach 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 don’t always know what to do with it.

Market

Research

Product

Characteristics

Planned Selling

Price Less

Desired Profit

Target

Cost

Manufacturing

Design

Engineering

Supplier

Pricing

Target costs for each component force

marketers, designers, and engineers

from all departments and suppliers to

struggle and negotiate trade-offs.

Continuous

Cost

Reductions

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 it’s 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 don’t express its full meaning. The best understanding may come from the ancient expression “There ain’t 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 wouldn’t 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 didn’t somebody have to invest time in learning how to grow or find food? And make or buy the utensils? Didn’t 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 don’t 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. It’s when the government hands

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 haven’t, at least not as much. Deflation is just the opposite, but historically it doesn’t 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. Here’s 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. They’re 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 don’t understand what is going on. Here’s 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

of 199

dollars is $650K, $380K, and $270K. The escalation calculations are shown in Exhibit B-3:

Exhibit B-3—Example Escalation Calculation

Year Base Year K$

Calculation Escalated Cost K$

2001 650 (650)(1.025)= 666.25

2002 380 (380)(1.025)(1.031)= 401.57

2003 270 (270)(1.025)(1.031)(1.033)= 294.75

Sum 1,362.57

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.

Exhibit B-4—Example Learning Curve

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.

7

8

9

10

11

1 2 3 4

Repeats

Ho

urs

of

Wo

rk

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 wealth—land, 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

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 don’t just vanish. They are dumped onto all other

current projects.

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 don’t 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 don’t ask a government agency, we ask the market what it’s worth. The simplest way to do that is to find out what it sells for now, or has sold for in the recent past. That’s called a historical cost. If we can’t 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 aren’t 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

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. It’s 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, it’s well to confirm it by comparison to historical costs. Even if it doesn’t check out as closely as you would have liked, it’s 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 can’t 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. Don’t 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.

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).

of 199

When customers are allowed to study the contractor’s 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 doesn’t 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 can’t 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.

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 arm’s 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 don’t 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 didn’t 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. That’s 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

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

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-5—Example 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.

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

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. That’s 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

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 isn’t watching all that closely?

In many organizations, existing policies tend to favor a relaxed approach to cost management when the customer’s 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 it’s 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.

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.

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-of-

the-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 don’t 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 goal—success 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

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.

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

between their team’s engineers and the subcontractor’s 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.

o 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.

o 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 doesn’t 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.

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

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 it’s ethical, if it’s good for my customers, if I believe I am using my time wisely, and I’m willing to be personally accountable for it, don’t 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

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.

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 week’s 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 realism—this is a dangerous practice!

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, it’s 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.

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 other’s 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

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 Do not judge or criticize ideas of the speaker. o Encourage wild ideas and out of the box thinking. o Build on ideas of others (“chaining”). o Go for quantity of ideas; don’t 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 ideas—facilitator writes on a visual medium in sight of all participants Review list—all 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 memory-jogging 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:

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, let’s 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 isn’t 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.

of 199

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 1960’s. 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 “that’s just the way it is,”

or perhaps “That’s 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.

191

Process / Policy

Hardware

Personnel

Tools / Environment

Original

estimate

exceeded

Inadequate

test system

Cost

containment

Training

inadequate

Too high

learning

curve

Less reuse of

old designs

than planned

Key personnel

not available

Leave when

trained

On other

program

Poor

estimating Inadequate

support system

Cost

containment

Equipment

problems

Supplier labor

difficulties

Potential

ABC

Subsystem

Schedule

Slip

Exhibit C-1--Typical Cause and Effect Diagram

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 product’s 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 pair-wise 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 customer’s 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 customer’s preference. That of course is valuable knowledge, but even better would be to know the customer’s 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.

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. It’s 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 don’t 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 1’s in the main diagonal:

Exhibit C-2—AHP Matrix Example (Initial Condition)

A B C D

A 1

B 1

C 1

D 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.)

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 1’s. 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-3—Example AHP Matrix (Filled In)

A B C D

A 1 1/3 5 4

B 3 1 7 9

C 1/5 1/7 1 2

D 1/4 1/9 1/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 wouldn’t do to say that C is more important than A. It’s 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, it’s 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:

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 industry—accuracy costs money. Following the principle of minimal design enunciated in chapter 10, we don’t 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

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-4—Typical Curve with Knee

Cost

0

20

40

60

80

100

120

0 0.2 0.4 0.6 0.8 1

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, it’s 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. There’s 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

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-5—Cost of Orifice vs. Tolerance

Cost $ per orif ice

100

150

200

250

300

0 0.5 1 1.5 2

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-5—Cost 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.

of 199

Cost $ per regulator

0

50

100

150

200

0 0.2 0.4 0.6 0.8 1

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 = σx

2 + σ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 σd

2 + (∂Q/∂P)2 σP2

The propagation of error formula as applied to our flow control example states that the variance in flow [σQ

2] 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 [σP

2] 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 σd

2 + 0.001 σP2

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

Let’s define two additional variables:

Cd = cost of one orifice of diameter d

CP = cost of one pressure regulator

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

Let’s 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

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-7—Manual Search Spreadsheet

Minimization of total cost

0.14 =Td (0.1-2 thousandths in)

1 =TP (0.01-1 psi)

0.094021 =TQ (≤0.0945 cfm)

$345 =Ctot $

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.

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, let’s 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

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.

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 subcontractor’s 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, ship’s 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 non-capital 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.

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.

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 bachelor’s 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 bachelor’s 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 organization’s accounting staff.

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.

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)

of 199

iii. Material (by type) iv. Services v. Capital equipment vi. Expensed equipment vii. Buildings viii. 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

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.

Bid to Win: A Guide to Pursuit, Capture, and Management of Unprecedented or High Technology Projects

Documents

Transcript of Bid to Win: A Guide to Pursuit, Capture, and Management of Unprecedented or High Technology Projects