3.3 OPTIMIZING ARCHITECTURE AND SYSTEM DESIGN
3.3.5 Raising and Resolving Issues Early
The MIT study, The Machine That Changed the World,11 summarized that in the best Lean projects: “… the project leader’s job is to force the group
to confront all the difficult [issues] they’ll have to make to agree on the project.” According to team- building expert Patrick Lencioni, team mem- bers must overcome any fear of conflict12 to openly and effectively raise and resolve issues. And a Harvard Business Review article cited a survey that stated that, “Surprisingly, the most common reason for withholding input is a sense of futility rather than a fear of retribution.”13
3.3.5.1 Project Issues
Each design team should candidly ask the following questions:
• Is there a reasonable chance of achieving the project goals in the scheduled time, given the allocated budget?
• Will the project receive enough resources to accomplish its goals?
Will they be allocated early enough?
• Are there any red flags? For instance, is the product definition stable or does it keep changing?
• Are cost and time goals based on bottom- line metrics such as total cost and time to stable production? If goals are based on the wrong metrics, the design team may be encouraged to specify cheap pur- chased parts, go for low- bid vendors who won’t help teams design their parts, let labor cost dominate sourcing and plant location deci- sions, or not optimize product architecture and throw the design over the wall to manufacturing “on time.”
3.3.5.2 Team Issues
Each design team should address all the team issues. For instance, the team should discuss lessons learned from previous projects and formulate appropriate action plans. Team members should thoroughly understand the risks from the lessons learned, including:
• Risks that were mitigated early. How was that done?
• Risks that could have been mitigated early. How could that be done now?
• Risks that were not mitigated. What were all the consequences and associated costs?
Upon discovering unresolved issues, everyone should immediately raise them to the appropriate level.
3.3.5.3 Mitigating Risk
Discuss and mitigate risk issues, for instance:
• Are new product and process technologies proven enough and refined enough to incorporate into new designs and production?
• Are there multiple sources of risk regarding new product technolo- gies or new manufacturing processes?
• How much does success, cost, and time depend on entities and developments not under the control of the development team, such as partners, suppliers, outsourcing, regulations, etc.?
• Are there supply chain risks such as bidding or multiple sources ver- sus vendor partnerships?
• Will “cost reduction” directives compromise part quality, early ven- dor participation for custom parts, resource availability to ensure a complete team, or concurrent engineering itself if manufacturing is done far away?
3.3.5.4 New Technologies
Raise and thoroughly investigate new, unproven, or historically trouble- some technologies, parts, processes, features, user interfaces, and so forth.
Before deciding, thoroughly investigate all issues to ensure that all risk can be mitigated before pursuing. Make sure there is enough time and resources to do this.
Investigate and verify quality, reliability, manufacturability, usability, total cost, and functionality in all user environments by the expected range of users. Thoroughly investigate suppliers’ application guidelines; if not well documented, contact suppliers’ application engineers. Investigate the history, reputation, and financial strength of suppliers. Ensure avail- ability of all parts throughout the life of the product.
3.3.5.5 Techniques to Resolve Issues Early
Some things you can do to resolve issues early include:
• Research. Make sure that technical feasibility studies do not specify or even suggest suboptimal product architecture.
• Experiments with statistical significance ensured by design of exper- iments (DOE), which should also be used for prototype testing, first article and beta test evaluations, pilot production, and tolerances.
• Enlist experts, such as those available from consulting associations like PATCA.org (which has 350 technical experts in Silicon Valley) or research services like Guideline.com (formerly TelTech), who can do research and provide access to 3,000 consultants that are experts on 30,000 specialties.
• Simulations, both for the product and the processing.
• Risk analysis and management.
• For critical applications, conduct failure modes and effects analy- ses (FMEAs).
• Make early models and rapid prototypes.
3.3.5.6 Contingency Plans
Formulate “Plan B” contingency plans to deal with the most likely changes, setbacks, delays, shortages, or other problems regarding technology, pro- cessing, customers, markets, regulation, and so forth. For instance, prod- ucts can be designed to readily accept the “Plan B” part if the “Plan A” part doesn’t work out or is not available in time.
3.3.5.7 Achieving Concurrence before Proceeding
Another MIT study, Made in America: Regaining the Productive Edge, gave additional insight into Japanese product development project management:
“A key task of the manager is to make sure that all disagreements are aired and resolved at the outset. Achieving consensus takes a great deal of effort, but by skillful management at this point it is possible to gain the full com- mitment of all members of the program team so that subsequent progress is very rapid.”14
At the Xomed division of Medtronic, “Xomed works harder validating process at each stage of a project, which forces them to ask the right questions earlier and earlier, and wastes less overall project time by reducing the num- ber of bad assumptions made to compensate for incomplete information.”15