Design for Manufacturability: Optimizing Cost, Quality and Time-to-Market Second Edition David M. Anderson; Cambria, California: CIM Press, 2001, 302 + x pages, US$44.95 Agile Product Development for Mass Customization: How to Develop and Deliver Products for Mass Customization, Niche Markets, JIT, Build-to-Order, and Flexible Manufacturing David M. Anderson (Introduction by B. Joseph Pine II); New York, McGraw-Hill Professional, 1997, 293 + xvii pages, US$37.95 Although the scope of this journal (and of the Product Development and Management Association) covers the full range of product development, it has tended to emphasize the up-front activities of portfolio management, product definition, design and development, and marketing-R&D interaction. Product developers seem to presume that once the product is designed, it will slip into manufacturing transparently and flawlessly, despite the fact that many development projects experience late-stage crises because the product cannot be manufactured smoothly, effectively, reliably, or at target cost. Anderson 's two books (hereafter called DFM and APD, respectively) are among the few that view product development from a manufacturing vantage point. Consequently, they are valuable in sensitizing product developers to the manufacturing implications of the decisions they make. DFM in particular is a practical, how-to book for product developers and their managers, especially for design engineers, manufacturing engineers, and those involved in purchasing, finance, quality, and product testing. To the extent that marketing is interested in reliable, low-cost products, marketers should also be familiar with this material. APD is not as technical; it concentrates more narrowly on mass customization. Both books apply to discrete manufactured products, both mechanical and electronic. Chapter 5 of DFM, on standardization of parts and materials, is perhaps the most valuable part of this book. Anderson explains why part proliferation happens, what its substantial but subtle costs are, and what can be done to overcome it. He provides a detailed 13-step process for creating a standard parts list, and he goes on to describe how one can also standardize raw material, part features (such as fillets and hole sizes), and even expensive parts (such as motors, pumps, and microprocessors). An aspect of the issue that he does not cover is that proliferation is much easier to maintain under control than it is to bring under control once it has gotten out of hand. Another unmentioned dimension is that proliferation is easier to deal with in some industries than others. For instance, at Intel, where Anderson implemented a successful standardization program, products turn over quickly and are not usually used in life-threatening applications. Contrast this with Boeing, where products require spare parts for fifty years, a mistake can cost a few hundred lives, and each ounce of excess weight in a part adds dearly to its life-cycle cost. APD covers much of this same standardization material (in its Chapter 5), including the 13-step process. In Chapter 3, The Cost of Variety, Anderson presents a strong case for standardization, because it is a prerequisite for mass customization. Chapters 6 and 7 of DFM address product cost, and the book convinces us that the designer 's normal focus on part cost misses the big opportunity, which is overhead cost. Anderson suggests that to rationalize product cost to the point that we can make intelligent design choices to reduce it, we need a cost accounting system that allocates overhead equitably. He suggests activity-based costing, but unfortunately, he does not explain how one implements such a system. Anderson covers these two chapters virtually word for word in Chapter 6 of APD. DFM 's Chapters 8 and 9 get to the title, and the heart, of this book, design for manufacturability. Chapters 10 and 11 move into design for quality and design for repairability, and Appendix B offers design-for-manufacturability guidance specifically for printed circuit boards. These chapters are all organized into lists of guidelines arranged by category. For example, one category is assembly, and a couple of its guidelines are
Each guideline receives a paragraph or two explaining why it is important. For instance, assembly from above allows gravity to aid automatic assembly equipment, such as screw inserters, and it also eases manual assembly. The other categories covered are fastening, motions of assembly, test, standardization, part shape, handling by automation, quality and reliability, and repair. In connection with these chapters, Appendix C provides useful, specific guidance on setting up a system of design for manufacturability guidelines for your organization. In fact, Anderson suggests both guidelines and rules. The rules are specific yes/no items that must be followed, whereas guidelines suggest a range of practice; the closer one can achieve them, the more manufacturable one 's design will be. Rules will predominate for fully automated assembly, because automation equipment allows little latitude in how the product can be manufactured. While DFM subsequent to Chapter 7 concentrates on design for manufacturability, APD subsequent to its Chapter 6 focuses more narrowly on development techniques and perspectives for mass customization. Anderson elucidates the key mindset for developing mass-customized products: "In contrast to the development of a discrete product, developing products for mass customization focuses on product families/platforms or many product families and their evolution over time" (page 202). Pages 255–63 of APD present an enlightening discussion of the three means for implementing mass customization: modularization, adjustability, and dimensional customization. For instance, if one mass customizes a bicycle, modularization would provide a choice of components such as hubs, saddle, and brakes. Adjustability would allow the saddle's height, angle, and fore-and-aft position to be changed. Dimensional capability would allow the tubing to be cut to the rider 's size before welding the frame. I found DFM 's first four chapters disappointing. They broadly extol the virtues of manufacturability, concurrent engineering, and flexibility. Chapter 4, for example, covers "flexibility" by somehow linking it with lean production, build-to-order, mass customization, reusable engineering, and modular design. But none of these terms is defined, so the linkages are vague. More importantly, each of these techniques has its strengths and limitations, but Anderson doesn 't mention the downsides. For example, modular design can be a powerful tool, but it can also raise costs, decrease performance, introduce reliability issues, and complicate system testing. Thus, modular design should be exploited only where its benefits outweigh its disadvantages; otherwise, one should strive for more integral architecture. APD suffers from the same vagueness. Even the title term, agile product development, is left for the reader to interpret in any of several listed ways (page 215). Although, like DFM, APD is overwhelmingly positive about moving toward mass customization, it does provide a valuable list of both the pluses and minuses of modularization, adjustability, and dimensional customization (pages 262—63). DFM is a self-published book, and its quality falls short of normal commercial standards. The overall design is uninspiring, the figures are amateurish, references are cited inconsistently, and there are a fair number of typos. Worse, half of the pages had fallen out of this $45 paperback by the time I had finished reading it. (Perhaps this product wasn't designed for manufacturability?) Although APD is four years older, its material doesn 't seem dated relative to DFM. For example, of the 125 references cited in DFM, only two appeared after APD was published. In conclusion, both of these books cover an important subject that has been given too short shrift by JPIM and PDMA. Although they have shortcomings, I do not know of better books on this vital product development topic. Preston G. Smith CMC (Reviewed in the Journal of Product Innovation Management, November 2001, pp. 417-18.) Book reviews | Product development publications | Home
Mastering #Virtual Teams: Strategies,
Tools, and Techniques that Succeed Many of us have battled to keep product development teams together geographically, as we have observed that co-located teams perform both better and more rapidly. However, times are changing, and in the 21st century physical co-location will be increasingly difficult to achieve. This is a book for those who must form a dispersed team, lead one, oversee one, or serve as a member of one, especially if they have little experience in working with team members at a distance or if they have had problems in the past in making such teams work effectively. Team dispersion is arising from several sources. Corporate acquisitions bring together team members who naturally work in different locations. Globalization trends will continue to drive manufacturers toward global markets and offshore manufacturing, adding distance to relationships [1]. In addition, companies that formerly developed products solo are now creatively forming development alliances with suppliers, customers, contractors, academic and other consultants, and even competitors, generally all of them offsite. Duarte and Snyder have chosen a most timely title but, unfortunately, not a very helpful one. Virtual team is clearly the management buzzword for this phenomenon. However, virtual is defined as "being such in essence or effect though not formally recognized or admitted" [4]. The difficulty with this word is that it softens (i.e., only in essence or effect) the quite real (formally recognized or admitted) work that the team is charged with doing. This distinction is more critical for dispersed teams, when many activities are out of sight. We cannot afford to not formally recognize or admit what is happening, trusting that results will appear in essence or effect. Consequently, in this review I will use the term dispersed teams rather than virtual teams to recognize their essence without suggesting anything like smoke and mirrors. The strength of this book lies in the wealth of tools and techniques it offers. To help readers select the most useful tools, the authors classify seven types of teams. Product development generally fits best in the project team category. However, they characterize project teams as having fluid membership and decision-making authority. In my experience, these are not givens for product development teams and, in fact, are primary criteria for distinguishing teams that perform well from those that do not. Consequently, be careful about following the recommendations for project teams blindly. Many of the tools are in the form of checklists. Some checklists are of the conventional type that helps you to remember things that need to be done, but many are more powerful. For instance, the book 's initial checklist defines the seven types of teams to help you identify your team type. Then it guides you toward quantifying the complexity of your dispersed team so that you get an indication of the roughness of the road ahead. Another checklist, number 4.1, is a rather elaborate instrument that allows you to assess critical dispersed-team competencies of the individuals on your team. It should be quite useful to a leader setting up a dispersed team. The nature of dispersed teams is that they require both the soft issues (for example, trust building and leadership development) encountered in traditional teams and hard issues (communication technologies) used to span distances. Duarte and Snyder handle this balance beautifully. They cover the technology in Chapter 2 at a level of detail that will retain some permanence as the technology advances, and they provide several charts to help readers connect the task at hand with an appropriate technology. Throughout the book they point out strengths and weaknesses of various technologies for specific team tasks. For example, on pages 162–63 they address technologies appropriate for use in dispersed team meetings, depending on the purpose of the meeting. I also enjoyed the concrete way that these authors treat cultural issues. They divide dispersed team culture into three types: national culture (for example, Japanese versus Americans), organizational culture (differences between Intel and Lucent Technologies), and functional culture (engineers versus marketers). In the national culture area, they present the useful and well-founded categories of Hofstede and Hall to clarify the distinctions. In the organizational area, they rely on the Competing Values Model of Cameron and Quinn. Four checklists help to make this material actionable. Clearly, these cultural issues can get in the way of progress, but Duarte and Snyder are careful to emphasize that cultural diversity is not something that we should—or even can—change but is instead an asset that ultimately adds richness to a team 's output. Trust is such an important issue for teams, especially dispersed ones, that the authors devote a chapter solely to it. As they say, "One of the biggest mistakes a virtual team leader can make is to underestimate the power of trust . . . if we do not find ways to build trust and understand how technology affects it, people will feel as if they are always in a very precarious state." (page 83) In addition to the trust chapter (Chapter 7), the team-building chapter (Chapter 5) has a couple of excellent tables useful for selecting team-building activities depending on the cultural differences that exist on your team. In general, dispersed teams have all of the difficulties that co-located ones have plus several more. One difficult area is in coordination and collaboration. The authors observe that "traditional organizational structures, reporting hierarchies, processes, and systems do not ensure coordination and collaboration in virtual teams." (page 122) Another is in six additional competencies, including use of technology, self-management, and boundary management, that dispersed team members must acquire (pages 126–31). One more difficulty that the book addresses (pages 195–201) which leans much more heavily toward history (back to Norman times), concepts, and case studies, restricting its how-to help to just thirteen pages (pages 212–24). Its apparent foundation is Stamps ' Ph.D. dissertation from twenty years ago. Virtual Teams ' message tends to be: dispersed teams are here, and you had better get the technology and get onboard. Your third option is Virtual Leadership [2], a business novel that conveys the concepts involved through the fictional exploits of modern-day manager being coached by King Arthur as he created Camelot in 597AD. If you learned from Goldratt' s manufacturing flow classic, The Goal, you will enjoy Kostner. She handles the soft issues well but is of no help on technology topics. One final caution: In my experience in working with a similar book [5] for a decade, I have found that although such books ' value greatly outweighs their price, just buying books and distributing them accomplishes little. Getting your whole dispersed team on board requires that everyone on the team absorb and agree on the techniques the team will employ. We have found no substitute for initial face-to-face training to accomplish this vital preparation. Preston G. Smith CMC References 1. Friedman, Thomas L. The Lexus and the Olive Tree. New York: Anchor Books, 2000. (See review in this journal, November 2000.) 2. Kostner, Jaclyn. Virtual Leadership: Secrets from the Round Table for the Multi-Site Manager. New York: Warner Books, 1994. 3. Lipnack, Jessica, and Stamps, Jeffrey. Virtual Teams: People Working Across Boundaries with Technology. Second Edition. New York: John Wiley, 2000. 4. Merriam-Webster 's Collegiate Dictionary. Tenth Edition. Springfield, Mass.: Merriam-Webster, 1998. Developing Products in Half the Time: New Rules, New Tools. Second Edition, New York: John Wiley, 1998. (Originally published in 1991.) (Reviewed in the Journal of Product Innovation Management, March 2001, pp. 127-29.) Book reviews | Product development publications | Home
The Inmates Are Running the Asylum: Why
High-Tech Products Drive Us Crazy and How to Restore the Sanity This is a voice-of-the-customer book that makes the subject come alive. Although focused on software, Cooper makes it abundantly clear in the first half of the book why products—software or not—get designed to suit users. In the second half he offers solutions that can be adapted to fit products well beyond software. The lessons apply to any product that has a user interface, independent of any software or electrical content. It would be of less value for products that are not designed for users, for example military development where one designs to the letter of a government contract, or products of a third-tier OEM supplier, such as microchips, where the user is unaware of the product 's existence. Inmates is aimed at product developers and their managers, as it is the managers who hold the keys to the asylum. More broadly, the book 's first half would be enlightening to anyone who has ever been frustrated in using Windows, a modern television or telephone, or a computerized library catalog. I take many product development books into restaurants to read while I dine; this is the first one that repeatedly elicited interest from the servers. In short, Cooper 's point is that products—especially high-tech ones—overwhelm and belittle users, because the products' developers live in a different world, totally out of touch with the user's situation. He not only illustrates this with numerous examples, but also digs into the life of a typical Silicon Valley programmer (Cooper lives in Silicon Valley) to show what their world looks like and why it is so far from that of a typical user. His examples of user-unfriendly products seem to go on and on. I was wondering if any positive examples of well-designed software even existed until some showed up relatively late in the book. His examples of needlessly difficult-to-use products span the gamut from airline navigation systems to a simple two-button automobile entry system. Cooper loves his electronic gadgets, but he is equally sensitive to their shortcomings. For instance, he has owned several VCRs over a twenty-year span. After explicitly trying to buy one at any price that was simple to operate, his success rate in recording delayed broadcasts remains at just 40 percent. All of the features added to VCRs by developers over twenty years haven 't made this machine one bit easier to use! This book causes one to think more deeply about the friendliness of the products we encounter every day. For example, if I go to the ATM at my local (Portland, Oregon) bank, I find it slow and frustrating. However, if I fly halfway around the world, instead of the communication delay I expect due to the distance and language barriers, I am delighted to find that I can withdraw cash from the ATM in the main hall of the Singapore airport in half the time, with fewer than half the keystrokes, and with a much greater sense of dignity than right at my home bank. My USBank ATM always asks me if I prefer Español, even though I always opt for English; it keeps asking me if I want a receipt, ignoring my track record of always answering yes; and it continually asks me if I want to withdraw from checking or savings, when I don 't even have a savings account. Once I hit the savings key by mistake. I received a stem warning that I had screwed up, not that USBank had made a mistake in offering me that option. Although this is a book about what is normally called "user interface design," and Cooper 's last book was subtitled The Essentials of User Interface Design, he now prefers to call it "interaction design." Interface implies that there is a clean break between the inside and the outside of the product, and one can slap an interface on the surface after the core is finished. Such interfaces are invariably poor ones, because genuine usability must be supported by certain features in the core, and these are unlikely to be there unless the user is designed into the core first. Going back to the ATM example in the last paragraph, for the machine to know that I always want a receipt and speak English the core software would have to track my behavior, a fundamental change in the core's design. Note that this outside-in design implies a reversal in the normal steps of designing a product. Rather than starting with the core and working outward, one must instead start with the user and design inward. This is the organizational obstacle in Cooper 's approach, as it puts the user in the driver 's seat and takes the customary power away from the programmers to specify the core 's design first. In the words of the book 's title, the inmates will no longer be running the asylum. Cooper introduces several tools for user-centered design. For me, the most powerful of these is personas. A persona is a description of a user, including a name, a portrait, and illumination of certain idiosyncrasies that render this individual real to the developers. Personas are not just fictional write-ups but instead are built carefully from thorough market research to represent key users according to a product strategy. For instance, in designing an airline in-flight entertainment system (pp. 138—48), the central persona was Clevis McCloud, a crotchety 65-year-old Texan with a touch of arthritis who had never used a computer. The team was to build the system for Clevis. To ensure that the resulting design didn 't offend others, the team also built three secondary passenger personas, each being an archetype of an identified group:
Personas on the airline side included Amanda Hopper, the flight attendant who has to keep the system running and the passengers happy throughout the trip, and Mel "Hoppy" Hopper, the mechanic who has to troubleshoot and fix the system during the short time that the plane is on the ground. Note that the persona approach is quite different from the normal one in which a system is built from a list of features driven by competitive offerings. For example, the VCR mentioned above has features galore, but it frustrates nearly everyone who uses it. In contrast, designing for personas concentrates on delighting core users while not annoying others, totally ignoring features unless they fit into this picture. Cooper provides valuable insights on why products are not developed for appropriate users. Marketers, he suggests, in their quest to satisfy everyone, implicitly design products for beginners. On the other hand, programmers are trained to deal with edge cases (those possible but highly unusual situations that, if not resolved in the code, will cause your computer to crash when you press an inappropriate key). When programmers constantly think in terms of edge cases, they naturally design for expert users. Clearly, this sets up conflict between the marketers and the programmers. More importantly, he observes, both are misguided. Most of us users have advanced beyond the beginner stage but don 't use the product regularly enough or with enough variety to ever become experts: we are perpetual intermediates (pp. 182—85). I didn 't find many negatives in Inmates. Mr. Cooper is passionate about poorly designed products and what can be done to improve user interaction, so he sometimes sounds strident. Although Inmates is short, for a computer book, it nevertheless reads a bit like a computer book. For instance, chapter titles such as Computer Obliteracy, Cognitive Friction, The Dancing Bear, and Homo Logicus are clever but not very helpful until you have become initiated by reading the book. (Perhaps Cooper forgot to construct a reader persona!) You may have observed that, following Cooper 's usage, I have consistently referred to users rather than customers. Product developers love to debate who the customer/user really is. We once had a client that developed food packaging used in supermarket bakeries. To them, the customer was clearly the manager of that bakery department. They designed products that displayed the food attractively, were easy to fill but tamper-resistant, and were stackable. To me,the end user, these same products were a nightmare to open, were un-reusable after opening, and created a substantial disposal problem. It only gets more complex when one moves from consumer to industrial products. Cooper concentrates on the end user. His rationale is clear: It is the end user who will have to live with the product day-in and day-out over its life. If you make this person happy, others back through the distribution chain will eventually be happy too. Preston G. Smith, CMC (Reviewed in the Journal of Product Innovation Management, January 2001, pp. 59-61.) |
|