In chapter 4 we discussed how our product’s cost or difficulty distribution should reasonably reflect our customer’s perception of what is important. This is the issue of design balance. If the customer perceives that the product we want to design overemphasizes some features at the expense of others, the customer may become uncomfortable, even dissatisfied, as discussed in chapter 5. A customer in this state will be less inclined to award us the contract we seek. There is, of course, the possibility that the customer’s wants are poorly conceived, and it may be to our benefit to try to lead him away from mistakes, as discussed in chapter 7. Having done (or at least considered) all of that, we need to understand what the customer can afford to pay, and what the customer perceives as the minimum responsive bid, as discussed in chapter 8. Then, as discussed in chapter 9, we need to design a project process that will encourage the customer to believe that we are not likely to mismanage the project.
That brings us logically to this chapter.
It is of course unwise to offer the customer a product that is seriously unbalanced with respect to his goals. It can lead to losing the bidding competition. Oddly, another easy way to lose a bidding competition is to offer the customer more than has been asked for.
It’s easy to demonstrate how this works. The customer asks for X and we offer X+Y. X costs $100 and Y costs $10. Our bid is $110 plus contingency and profit. Our competitor offers X and assuming equal efficiency as a bidder, he or she bids $100 plus contingency and profit. That bid is probably more than 10% less than ours. (Offering Y likely increases not only our costs, but also our contingency allocation and our profit expectation.) Do we lose?
Generally, we do. There can be special circumstances where we do not. Here are two of them.
- Based on our intimate understanding of the customer’s wants, we KNOW that the customer secretly wants Y and is willing to pay extra for it. Our competitor has failed to reach this same understanding because Y was not listed as a goal in the written request for proposal.
- The customer has a special place in his heart for us and is willing to accept our bid even though it is higher than the lean but adequate bid of our competitor.
In the first of the above two situations, we would be wiser to include Y as an option, not as part of our primary bid. That way, our bid can be more competitive and if our customer really wants Y, the option is available. In the second situation, we must be careful. Someone in our team and/or someone in our customer’s team may be risking sanctions.
From this point on we will accept it as a given that it is best not to add into our bid any features beyond what our customer has asked for, with one exception, as described in the next paragraph. If we think our customer might want them, we add them to the proposal as options.
The exception is when the added features or advantages have no additional cost or the cost is so low as to be immaterial to the customer. Then we can add them gleefully and brag about them in our proposal.
Adding features beyond what the customer has requested in his goals statements is in principle a simple thing to avoid. We simply don’t add them. Would it were so simple in the real world. Many project teams add unnecessary features without even thinking. They often do it in many small and subtle ways. And they do it not to satisfy the customer but to satisfy themselves. They map their perceptions of what the product should be on top of what the customer has asked for without even realizing it. This practice is quite common; there is even a vernacular expression for it. The expression is “gold plating” the design.
Of course, gold plating doesn’t literally mean that the designer requires plating with precious yellow metals for items that don’t need it. It refers to any practice that adds features that are not needed. It also refers to levels of quality and reliability that are not needed, and to poorly conceived extras that may be irrelevant in practice. It refers to unnecessarily tight tolerances and to costly finishes beyond what the customer expects. It could refer to requirements to use products from a certain high cost vendor, with no options allowed, or to requirements to use favored old methods and processes that have been replaced with better, cheaper processes. Or, it could refer to a product capability that the contractor perceives to be “nice,” but the customer perceives as being useless.
We will use the expression “minimal balanced design” to refer to a design that is balanced in the sense described in chapter 5 and minimal in the sense that it is free of gold plating. A minimal balanced design is what we must strive for in our proposal.
Any additional features we think the customer might like to have (other than those that are essentially free) should be proposed and priced as options the customer is free to choose or to reject.
In some teams the tendency to gold plate is so strong that a culture change is necessary to overcome it. Some teams that attempt such a change go about it in a way that could lead to failure. They begin by building a typical gold plated design. Then they attack it by doing cost reduction studies to see where costs can be taken out. They generally succeed in getting some of them out but eventually they may find that their competition is still below them in cost.
Please recall the following statement from an earlier chapter: “Comparisons between relative cost and relative value should be based on minimal efficient designs.” What exactly does that mean, and how do we arrive at such a design?
A minimal design is easy enough to define. It is a design that satisfies the customer’s goals and little or nothing more. It is not burdened with features that were not requested. It is not built to unnecessarily tight tolerances, which increase costs. It does not have expensive surface finishes that are functionally unnecessary. It does not have features not requested by the customer.
An efficient design, for our purposes, is one arranged such that the cost of implementation is minimized, given that the required functionality is retained. This means use of the lowest cost materials that will do the job, and fabrication and assembly made as simple as possible to minimize the labor hours, and to avoid unnecessary special, expensive labor skills, tooling, and processes.
It follows that a minimal efficient design combines both of these characteristics. It further follows that such a design should be the one that wins a bidding competition, based on price.
There are two main approaches to creating a minimal efficient design. One is typical of how many (if not most) designs are done. The design team considers all of the customer’s goals as a package, and tries to design to meet, and usually slightly exceed all of them simultaneously. More often than not, this will result in a design that is heavy and expensive. To get it light enough and cheap enough, the design team must do a weight or complexity reduction program and a cost reduction program. When the team has given this its best effort, chances are the design still will not be minimal and efficient. It may meet functional requirements, but a competing design will often meet them at lower cost.
The other approach we will call “evolutionary” (see Exhibit 10-1 nearby). It begins with rank ordering the customer’s goals as was discussed in chapter 5. Create a design that focuses on meeting the top goal as minimally and efficiently as possible, just as Mother Nature might create a simple new species that can function in a simple environment. Then, imagine that the new species you have created enters a new environment that includes the next goal on the list. As in nature, it must adapt to this new environment. Think of the simplest adaptation that will permit barely adequate functionality with respect to both goals. Incorporate that into the design.
Continue this process, working your way through the goals. Arrive eventually at a design that meets all of the goals, some perhaps just barely. Simulate giving it ten million years of evolution to make it more efficient by doing a design for manufacturability study (more on that shortly). You should be there – minimal and efficient.
An excellent mental aid in working through the goals is to use a tool of value engineering called functional analysis. As implemented in VE, a functional analysis comprises expressing the function desired as an action verb followed by a noun, such as “measure temperature” to define the functionality of a thermometer or a moist finger, or “contain liquid” to define the functionality of a glass, a pipe, a bucket, or a tub. The advantage of this approach is that when the functionality is thus reduced to its simplest form, options tend to become visible, and one can choose the least expensive one. Even if the next goal to be considered renders it impossible to use the cheapest one, it might still be possible to use the second cheapest one, or alternately, to make a slight change in the cheapest one that has little cost effect.
Sometimes several passes through this process will result in a choice of several low cost designs, among which one can choose the best based on such subjective criteria as appearance or comfort. It can sometimes be productive to shuffle the goals into a new, random order, and repeat the process.
It frequently comes as an unpleasant surprise to teams who think they will win a competition hands down that some competitor “out there” has come up with a way to provide the same or better functionality at lower cost. If this is a possibility, even having a balanced minimal design does not guarantee a win. It may turn out, for example, that a competitor can build a product with the same functionality as yours but 15% cheaper. The competitor’s design is more efficient than yours in the sense that it is more in tune with efficient manufacturing processes. This competitor has considered “design for manufacturability” (DFM) and you have not.
Design for manufacturability is a process by which designs are crafted so that they can be manufactured at minimum cost. Such designs minimize what must be done by hand or with expensive materials. Snap into place replaces screw down with many fasteners. Testing is automated. Parts counts are minimized. DFM is further discussed in the next chapter.
Many expensive and risky projects today are concerned only with the development of software. Design for manufacturability is not a consideration, because software is not “manufactured.” The closest equivalent to DFM in the software world is probably function point analysis. Function points are features of the software that meet specific customer wants. They are strong drivers of both effort and schedule in software development, and they are closely related to software architecture. Through function point counting, you can show your customer how his wants relate to costs. And you can conduct trade studies that lead to minimal designs.
A current trend in software development that must not be overlooked by astute pursuit teams is the re-use of existing code and use of commercial off the shelf software (COTS) to avoid software development costs. These options are not cost free, and in some instances may be more expensive than developing code from scratch. But used judiciously, they can cut development costs and schedule considerably.
Design of services products likewise may involve little or no manufacturing. The equivalent of DFM in services design is process design. See Appendix A for more information on this important subject.
Other ways a competitor might beat you on cost include use of low cost labor and rigorous application of certain cost disciplines such as value engineering, life cycle costing, design-to-cost, cost as independent variable, and target costing. These are all discussed in the next chapter and in Appendix B.
The minimal approach must be pursued across all aspects of product functionality, not just the one or two most important aspects. This means that product functionality must first be fully defined. Functionality definition ultimately comes down to allocation of the customer’s goals to the various elements of the product. Such allocations are commonly referred to as the product’s architecture.
Generally, the same overall functionality can be achieved with more than one architectural option. Ideally, in our proposal we will examine as many architectural options as possible and will reduce them to minimal balanced designs before trading them off using conventional trade study processes, or perhaps simply looking to see which one has the lowest cost. Because such trade studies virtually always include cost as a factor, trade study costs are usually estimated using parametric estimating methods because of the speed with which the estimates can be done.
Chapter 10 Review Questions
- Can you think of an example of design gold plating in any product you recently worked on?
- Is it possible to have a conflict between the concepts of “balanced” and “minimal” designs? If such a conflict could occur, how would you try to resolve it?
- On your most recent project, were customer goals explicitly considered in design reviews?
- Customer goals are the criteria by which project success must be measured. Design requirements are constructs of the design team based on selected product architecture. In your most recent experience, did the design team carefully segregate customer goals from requirements derived from architecture choices? (Some teams lump them together, thus potentially confusing what the customer wants with what they like, potentially resulting in designs that are neither minimal nor balanced.)
 Function points are a unique and clever way of measuring the functionality of software. Interested readers should contact the International Function Point Users Group (IFPUG).