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

1. A Guide to Pursuit, Capture, and Management of Unprecedented or High Technology Projects By Evin Stump.

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

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

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

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

6. Page 1 of 199 Preface This book is aimed at people involved in what I choose to call “advanced contracting.” Who are they? They certainly include all of the teams involved in bidding defense contracts in North and South America, Europe, and elsewhere, as well as those who bid contracts involved in launch and operation of systems in space. Also included are many who bid a variety of contracts with federal or local governments, other than routine procurements and smaller or traditional construction 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

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

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

9. Page 4 of 199 Moreover, you must be willing to: Reject traditional “gold-plated” design solutions in favor of balanced, minimal solutions — this may be a cultural change for your creative people.  Carefully estimate and manage project risk and consistently bid near the bottom of the competitive range — this may be a cultural change for your business people. The book discusses all of these subjects in detail. It is organized into six major sections with a total of 18 chapters, plus five appendices. Most businesses are cyclic in some sense. Retailers regularly have a big push at Christmas and smaller flurries of activity at other times. The demand for gasoline slows in winter months, but the demand for fuel oil picks up. Machine tool manufacture typically follows a larger business cycle related to economic booms and recessions. Some types of projects are affected by these various cycles, but companies that have substantial “propose / bid” activity have a unique type of cycle of their own. We might call it the “project cycle.” It may not be tied to the calendar at all, but it is nevertheless a cycle of repeated activities. It begins with learning of a project opportunity. If the project is ultimately lost in competition, it ends with the 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.

10. Page 5 of 199 Exhibit P-1 illustrates the pursuit cycle. In this preface we will convey only an elementary notion of what each sub-activity is about. Later chapters will discuss them in much more detail. The pursuit cycle activities are not necessarily repeated in precisely the order shown in Exhibit P-1. Typically, the order is adapted to the flow of information and the necessities of the proposal situation. Frequently, more than one of the activities will be ongoing at a particular point in time. Here are brief descriptions of the activities shown in Exhibit P-1. They will be the main focus of this book, each in its own section. I. Get Off to the Right 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.

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

12. Page 7 of 199 Acknowledgements The authors would like to express gratitude to the people who helped make this book possible or who helped improve it. Evin Stump gratefully acknowledges:  My wife of 49 years, Evelyn Helen Stump without whose forbearance and loyalty this book would not have been possible.  Our sons John, Michael, and Mark. John provided comments on the book from his perspective as a CPA and financial consultant. Michael reviewed the book from his perspective as a manager of plant maintenance working in a highly regulated industry. Mark is an attorney in private practice who studied the manuscript for lack of clarity, logical disconnects, or prolix language.  And our five grandchildren Rachel, Sarah, twins Isabel and Claire, and Getty, all of whom (still children as this is written!) helped just by being their sweet selves.  My faculty advisors at the University of Texas at Austin in the 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.

13. Page 8 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 2The 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.

14. Page 9 of 199 poor understanding of the competitive bidding range. They may have an even poorer understanding of what their efficient competitors can offer. Between Scenario 1 and Scenario 2 lies a continuum of other possibilities. For example, there might be a Scenario 3: Scenario 3. Your business development people hear rumblings that one of your customers or potential customers is getting interested in a particular idea. An internal champion may have proposed it, or a competitor may have. But there is definitely interest. As it happens, the interest is closely related to an area where your company has expertise and has been doing internally funded research and development. Your management believes this to be a growth area, and that a major project will develop and be funded in a year or so. You form a small pursuit team to go after it. The team visits the customer, learns about (and helps define) what the customer wants, and has the proposal half written when the RFP becomes available. The team has studied the competition, and has a good understanding of what it has to offer. It also has a good handle on the competitive bidding range, and is convinced it corresponds to reality. While the Scenario 1 team has the advantage of being first, and will probably overwhelm the Scenario 2 team, it will not necessarily overwhelm the Scenario 3 team. Many examples exist of come from behind wins by aggressive and powerful competitors. But always to start from far behind is a sign of poor business development practices. In the kind of advanced contracting this book discusses, business development is much more than simply going down to the lobby every day to see if a customer happens to have dropped by, or waiting for 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 Exhibit 1-1— Integrated Project Team for Business Development Top Mgmt Potential and existing customers Contracts Bus Dev Key Tech

15. Page 10 of 199 people are only loosely coupled. An organizational wall divides them. There is little or no internal research and development. This approach will surely lead to a declining business base. Today, ten years is a long life for many products; two years is long for many others. The ones that manage to live longer are usually the ones that are frequently upgraded to meet new needs. An excellent remedy for such a stagnant state of affairs is to extend the concept of integrated project teams to business development.3 In this approach, historical skills and achievements are merely the foundation for leveraging new ideas that may attract customers. They are not the entire business. Exhibit 1-1 suggests a business development team and process that stresses a “full frontal attack” emphasizing new ideas and giving customers maximum exposure to your company. The team comprises four major skills: top management, business development, contracts, and key technical innovators. The circle and arrows in the exhibit indicate that team members are in frequent communication and work closely together, even though they may “belong” to separate organizations. The mission of the business development team (BDT) is to:  Assist pursuit and project teams in maintaining good customer relations and close ties with key customer decision makers.4  Work with pursuit teams to obtain from customers (and other sources) information about what customers want and what they can afford to pay.  Analyze competitors ethically to obtain as much information as possible about what they are likely to offer, and provide that information to pursuit and project teams.  Continuously analyze the market for current or similar products and identify opportunities for pursuit.  Continuously innovate, leveraging from existing products into new and sustainable technologies that will interest current and new customers.  Convey needed information to customers and potential customers to help them make better decisions about acquisitions. 3In 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.

16. Page 11 of 199  Assist in the formation of new pursuit teams. Here are typical roles within that mission: Top management. A single senior executive should be appointed to the BDT. His presence gives the team cachet and access to the highest levels of the company. His network of contacts will frequently lead to opportunities to be explored. He or she can expedite the flow of information and the mustering of resources. Contracts.The traditional role of contracts people is to negotiate and administer projects contractually. A problem that sometimes arises is that they do this without adequate input from others. As members of the BDT, contracts people will have better insights into what drives costs and schedule, and what is important and what is not. They will be better prepared to develop a negotiating floor position and to trade off scope versus cost. Business Development. As members of the BDT, the sales people will be more aware of current and developing technologies, and the status of current work. They will be better able to identify the right customer people to approach with new ideas. And they will have a better understanding of where and how to look for clues as to burgeoning customer interests that have barely begun to surface. Key technical people.These are sometimes called “technology superheroes.” Sometimes, but not always, they are also “gray beards.” They are senior technical people who have a demonstrated capability to imagine and follow through with viable product ideas, especially those that “push the envelope.” Theirs is a central role in the BDT. They maintain awareness of the current technological capabilities of their company, their competitors, and their customers and potential customers. They acquire information about competitor products and use it to analyze product performance. They go to trade shows, attend meetings of professional societies, and otherwise stay abreast of developments in the world at large. They are either directly involved in their 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.

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

18. Page 13 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.

19. Page 14 of 199 Parsing the definition, it seems that the words or phrases most in need of elucidation are “group of people,” “collective goals,” and “satisfy.” 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?

20. Page 15 of 199  When certain people talk, does everyone else listen respectfully?  Who conducts the meeting?  Who prepared the agenda?  Who hands out action items?  Who takes on which action items and why?  Is anyone consistently called Mister or Sir or Ms. or 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.

21. Page 16 of 199  No organization is static. Watch for people whose power is on the wane. Also, watch for people who are “comers” and who may soon be elevated in status if not in formal rank.  At a personal level, always treat Passives well. If you 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!

22. Page 17 of 199 [As an aside, please note that in this book we carefully segregate goals from what are often called requirements. In this book, goals are what the customer wants, positive or negative, while requirements are needful things that arise out a particular project plan or design solution. If the plan or the design changes, so may the requirements, but the goals are still the goals. This is not to say that goals are always stable. Customers 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.

23. Page 18 of 199 Goals have many issues; we will not attempt to discuss all of them in this chapter. For example, there are issues of clarity, conflict, precedence, realism, and visibility, to name a few. Chapter 6 has a comprehensive discussion of this topic. Satisfying the goals Are goals satisfied only when the customer says they are? That may be the case in certain projects where the customer pays or reimburses all costs, no matter how high. But in most projects, the notion that the customer is always right must be tempered by reality. Satisfaction of a goal should be something that is easily and immediately recognizable by both contractor and customer. That will be the case only when the goals are truly clear. The notion of a clear goal is important. In this book, we define a “clear goal” as follows: A clear goal is one whose criteria for satisfaction are obvious. If all goals are clear, then the only issue of satisfaction is when we fail to meet the goal. Then we must pay whatever price or penalty the contract calls for. Unclear goals lead to arguments and dissatisfaction. We have observed that unfortunately many project goals are not clearly expressed. That is a major reason why we have lawsuits, mediations, and unhappy customers. Unclear goals are such a detriment to both customers and contractors that both sides should always go to great lengths to keep them from happening. Here are some examples of goals that may be unclear, depending on the context:  The software shall be user friendly. (What does “friendly” mean?)  The pipes shall be painted white. (Which pipes? What kind of paint?)  Contractor shall report status monthly. (Status of what? When in the month?)  The preliminary analysis shall be completed as soon as possible. (Who decides when as soon as possible is?)  Contractor shall use computers supplied by us. (For all purposes? When will they be supplied? Will they have the right software?)  Access to Bldg. 34 is limited. (Limited to whom? Do we need access? How can we get access?) Sorting out the true goals in a project is similar to what a communications engineer would call a signal versus noise problem. The stronger the signal, and the weaker the noise, the easier it is. The need for a strong signal versus noise ratio becomes even

24. Page 19 of 199 more imperative when you consider that you need to do more than just figure out what the goals are. You also need to figure out how important they are relative to one another. Sometimes a customer will volunteer that information for a few top-level goals, but more often it will not be disclosed unless you ask. Not too surprisingly, when you do ask, your customer will sometimes have to stop and think before giving an answer. In the rush to get his projects organized, a customer will often not be too clear on his priorities or his value system. Why is it important for the customer to know the relative importance of goals and to share that information with bidders? Here are three reasons:  The customer, having more certain knowledge of what is wanted, will be able to judge proposals more realistically, consistently, and fairly. Goals are more likely to remain stable throughout the project.  Bidders will be able to focus their efforts and costs on that which is essential, avoiding unbalanced proposals that overemphasize the relatively unimportant, often because it is simply something the bidder happens to like to do, or can do very well.  Potential project instabilities are likely to be avoided, as for example when the low and winning bidder has heavily discounted the importance of certain goals that are highly valued by the customer (this often happens when goals are less than clear). If this happens, the customer is damaged, and so are the bidders who guessed right about what was important and what was not. The winning contractor is likely to be damaged also. What is “relative importance” in this context? It comes in two “flavors,” ordinal scale and ratio scale. If we are asked our order of preference for three particular movies, we might rank them like this: 1. Star Wars 2. Matrix 3. Die Another Day This is an ordinal statement of preference. Such a statement might be perfectly adequate for certain decisions, but possibly not for others. In certain situations, we might want to know how much more we like Star Wars than Matrix, and how much more we like Matrix than Die Another Day. This type of information can be key to a decision process. Merely to know the order of preference is to know a lot less than knowing that with Star Wars at a ten on a ten-point scale, we would place Matrix at a 6 and Die Another Day at a 3.5. This is ratio scale knowledge and it can be precious in making decisions about levels of resources or degrees of application. A practical method for obtaining subjective ratio scale rankings is discussed in Appendix C. A very useful way to view goals is to classify them as either tradable or non-tradable. A tradable goal is one for which options exist as to how to satisfy it. A non-tradable goal is

25. Page 20 of 199 one which can be satisfied in just one way. Tradable goals are desirable because they give the contractor an opportunity to flex his imagination and find more cost effective solutions. Non-tradable goals may be necessary in some cases to fulfill the 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?

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

27. Page 22 of 199 specifications, statements of work, schedules, test procedures, quality requirements, shipping instructions, and numerous other documents, plus mechanisms for reliably and quickly accomplishing changes in design baseline. Therefore a prime has, or should have, considerable interest in the details of the capability of a subcontractor and the 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?

28. Page 23 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.

29. Page 24 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.

30. Page 25 of 199 tug of war over what the goals should be. Your competitors may have better solutions than you can offer. But it is beneficial for you to be a player if your approach even comes close to being the best solution for the customer. Here are some reasons why: o Your unique capabilities are made visible to the customer, who may have need for them on other projects o The customer will be pleased that you are interested in helping solve his problems, even though you 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.

31. Page 26 of 199 Because this is likely to happen from time to time, we believe it is best to follow a formal process for doing this. The reason is that 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 Understand who the customer is Compile goals Classify goals Establish customer goal values Resolve goal conflicts Critique goal problems Exhibit 4-1— Goal Development Process Manage goals 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

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

33. Page 28 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. Exhibit 4-2 Goal Management 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.

34. Page 29 of 199  Top management visits demonstrate your commitment to helping the customer solve his problems. If problems need to be resolved, top managers by virtue of their authority can most often find fast and effective solutions.  Visits by senior contract administrators to their counterparts in the customer organization are an excellent way to minimize problems due to poor contract structure, unclear or oppressive reporting requirements, and the like. Such visits may also result in more favorable terms of payment, e.g., faster payment, lower withholds, etc., that increase return on investment. They may also help minimize risks due to late delivery of customer materials or facilities, or risks that these may not be well suited to the work or may be defective. A further useful service contract that administrators can provide is to help better define who the customer is and what is affordable for the customer.  Business development people must visit to detect possible beneficial expansion of the scope of work, or new bidding opportunities. Their visits also serve to make the customer more aware of what you have to offer and how the customer can best profit from it. Visits from key technical people are vital to proper understanding of the 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

35. Page 30 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% Weight Processor speed Storage Display Battery life Price Warranty Options for growth Availability 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. Goal 20 9 9 5 5 20 5 13 14 5.9 pounds 800 mhz 300 mb RAM 25" 6 hours <$1,000 3 years Options #1, #2 1 year

36. Page 31 of 199 To further illustrate, suppose you add to the above table your estimates of relative cost, with the following result (Exhibit 5-2): Exhibit 5-2—Example Customer Relative Value/Cost Assessment Features Weight Processor speed Storage Display Battery life Price Warranty Options for growth Availability Relative Value% Relative Cost 20 9 9 5 5 20 5 13 14 Goal 35 7 6 5 5 18 5 11 8 5.9 pounds 800 mhz 300 mb RAM 25" 6 hours <$1,500 3 years Options #1, #2 1 Year An interesting way to present this data for internal review is a radar chart such as the following: 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 5 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.

37. Page 32 of 199 Aside from possibly helping your customer re-order his priorities to be more in line with costs, what other reasons are there to do the type of analysis shown above? Here are some thoughts on that subject.  Is the customer asking for expensive, unaffordable features? This is a critical issue. If the customer wants a $100 million product and you know that only $75 million is affordable, how do you best influence him or her in the direction of affordability? A many-sided question, but probably you would start by suggesting elimination or scale down less important items. To do that you have to know what they are. If you don't succeed in that you may not be the winning bidder, because you normally don't want to bid below what you believe to be your true costs. Moreover, the winning bidder may well fail in project execution. That bidder probably knew or guessed that affordability was only $75 million and bid that amount, either not understanding the true costs or hoping to make it up on changes. You lose because you lost the contract. The customer loses because his project seriously overruns its cost goals. Unrealistic expectations make a project unstable. Many outcomes are possible in an unstable project, and failure certainly is one of them.  Suppose that the customer says that a certain feature has 20% of the value but your analyses say it has 50% of the cost. Two possibilities present themselves. One is that you need to be sure you have a truly minimal design and have squeezed out all of the costs that you can. The other is that if things go along in this state, the customer will wind up paying a higher than reasonable price, given the low importance of the high cost feature. Again, two possibilities. One is that the customer says, “Yes, I know it's expensive, but I have to have it because of ___ (fill in the blank) even if I don't like it all that much.” The other is that the customer says, “Am I glad you noticed that and pointed it out to me. Let's get rid of that goal. That will really cut my costs.”  The customer wants a feature that has 50% of the value and only 10% of the cost. Provide it, and make a big fuss about how wonderful it is that you can meet stated needs so economically.  If your ratios are significantly different than your customer's preferences, you introduce what we call an unbalanced design. (Later in this chapter we show a simple metric for design balance that can be used to track it.) Is there any risk in having an unbalanced design? Yes. One risk is that your customer will sense that you are not paying enough attention to needs. Another is that your competition may have a more balanced design and can convince your customer it is more like stated needs than your design. This is subtle but can be quite real. How do you go about finding your 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

38. Page 33 of 199 responsive, credible answers sometimes can be had from consultants, especially those who are former customer employees or advisors. Exhibit 5-3 below shows a hypothetical example of a values survey. Exhibit 5-3—Using Weighted Survey Data to Assess Importance to Customer Parameter FACS Weight Value Speed 0.6 x 0.4 + Altitude 0.6 x 0.1 + Payload 0.6 x 0.5 + 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 Weight Value Speed 0.7 x 0.5 + Altitude 0.7 x 0.2 + Payload 0.7 x 0.3 + 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 Speed 36% Altitude 14% Payload 50% 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 Xanadu Customer Importance 36% 14% 50% Weight 0.4 x 0.4 x 0.4 x Value 0.3 = 0.2 = 0.5 = Project Management Weight 0.3 x 0.3 x 0.3 x PDI Value 0.4 = 0.3 = 0.3 = 47% 23% 30% PDI 47% 23% 30%

39. Page 34 of 199 spending too much time and money in areas that are not that important to your customer. Then again, you may not be. The metric is not infallible. 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.

40. Page 35 of 199 Earlier in this book the phrase “project design” was used. We explained that it referred to both product design and programmatic design. Up until now in this chapter, we have focused on matching product efforts with what the customer regards as important. We need to go beyond that to be sure our customer understands that our programmatic efforts also are appropriate. Customers usually spell out in considerable detail what they expect the product performance to be like. They often are a bit less explicit as to their programmatic goals. Programmatic goals, like product goals, can be either positive or negative, and either tradable or non-tradable. They can also be ranked, just as we discussed above for product goals. An obvious question arises: should they be ranked in the same list with the product goals, or separately? Separately is probably best in most cases. Separating them avoids the “apples vs. oranges” sense that arises when they are combined. (But see Appendix C for an approach known as the Analytic Hierarchy Process that can make sense out of many “apples vs. oranges” situations.) The important thing is not to focus exclusively on product goals to the detriment of programmatic goals. Keep in mind that your customer may be much more sensitive to certain programmatic issues than to some product issues. For example, if it has been made clear that a $50 million spending cap is not tradable, you need to be sure that you can do the project for less than $50 million. If you are pretty sure you 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?

41. Page 36 of 199 4. If “difficulty” is to be a proxy for cost, what definition needs to be assigned to “difficulty” that is reasonably consistent with typical dictionary definitions? 5. Name five typical elements of programmatic design other than schedule and budget. Hint: Look in Chapter 8 if you 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?

42. Page 37 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.

43. Page 38 of 199 The theory behind TCB is that dissatisfaction is most likely to arise or to become evident at a time when members of the project team are in contact with members of the customer organization. Therefore at every significant contact or transaction with the customer, the project team elicits specific feedback from the customer and promptly reacts to it in a “closed loop” manner. The principle is best illustrated with a couple of simple examples. TCB example 1 A few days ago, the same day it was requested, you mailed your customer counterpart a report of some tests that you supervised. Just after dropping the report off at your mail room, you called your counterpart to say that the report had been mailed and that it should arrive in three or four days. This is a transaction in which dissatisfaction can arise in at least two ways. One way is to have the report get lost or delayed in the mail. Another is that the report may not provide the information your customer needs (even though you may think it does!). To avoid the first problem, you make a note to yourself to call your customer in four days to be sure the report arrived. If it 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

44. Page 39 of 199 be wrong. Entropy exists in human affairs as well as in thermodynamics. Murphy and his Law lurk everywhere. Therefore meticulous follow-up is necessary to be sure things 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:

45. Page 40 of 199  If it becomes clear that anyone on your team has offended someone on the customer side, the offending person must make a sincere apology, in person if possible, and directly to those offended. Hiring interviews 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?

46. Page 41 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

47. Page 42 of 199 statements like “We really need this project, so just go do it,” or “Go ahead and start, we may be able to get more money next fiscal year.” (Or not.) The other way is when the people who will do Project Y 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:

48. Page 43 of 199 Stability. One of the most difficult risks a project team can face is instability of the project goals. Conscientious as a project team may be, it is hard (and expensive) to satisfy a customer who keeps revising the goals. Of course, in the fixed price contract project environment where the work content is tightly defined, the project team can handle this rather neatly by recording all of the changes and presenting the customer with the bill. This may or may not result in an unhappy customer. In other situations, goal instability can be a difficult problem for the project team in controlling the 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

49. Page 44 of 199 countered, causing goals to increase in scope. But all too frequently, goals creep represents nothing more than a hidden agenda that is gradually revealed. When this is the case, it is just a form of bait and switch. Hidden agendas and bait and switch are discussed later in this section. Basis in reality. Aside from goal instability, little can make a project more risky than to have goals not based in reality. We have all likely had the experience of working on a project where the goals were poorly grounded. Even though the plan may have been thorough and the project team may have performed as well as could be expected, the problem 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

50. Page 45 of 199 world countries, where it significantly raised crop yields. Yet only a few years after it was introduced, it was condemned as an environmental disaster. A post-project excuse commonly heard when goals are not based in reality is “We 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.