Robustness Development and Reliability Growth: Time, Money, and Risks

This chapter is from the book

Robustness Development and Reliability Growth : Value Adding Strategies for New Products and Processes

Learn More Buy

This chapter is from the book

This chapter is from the book 

Robustness Development and Reliability Growth : Value Adding Strategies for New Products and Processes

Learn More Buy

Soft Causes of Poor Reliability and Durability

What is reliability? What is durability? Here are useful definitions:

• Reliability: Acceptable quality delivered consistently over time, under specified operating conditions
• Durability: Acceptable product life, under specified operating conditions

So we focus on achieving the required quality, as perceived by customers, and on keeping it stable under the operating conditions of the various product applications.

These definitions don't have the rigor associated with being testable and measurable, but they are useful when thinking about reliability and durability at a high level. In Chapter 2 we present a definition for reliability that has statistical rigor.

Fundamentally there are two categories of root causes of reliability problems: "hard" causes and "soft" causes. Hard causes are in the technical elements of the product's design and of its manufacturing and service processes. Soft causes are in the human behaviors of project teams and in the management of the development process.

Many of the tools and processes in this book address the hard causes. Soft causes focus on opportunities for project leaders and management to enable excellence in execution and to avoid being the root causes of failures in project support, cross-functional integration, and teamwork.

Your process capabilities assessment may identify soft causes such as

• Project plans that are not based on sound strategies or cross-functional dependencies
• Production-intent designs specified before robustness and integration have been developed
• Product requirements that are neither complete nor stable (e.g., "feature creep")
• "Seat of the pants" decisions that increase project risks
• Selection of design concepts that lack sufficient capabilities or initial robustness
• Technical deliverables that lack clear expectations at a project milestone
• Development teams that lack process discipline or are complacent about their capabilities
• Project teams that are not able to speak truth to power or ask for help
• Project plans that do not apply lessons learned from past projects
• Development budgets that are reduced by ad hoc decisions external to the project

To the extent that your capability assessment recognizes these or similar problems, effective solutions can be developed. The literature on product development includes references that can provide additional insight into soft causes. For example, Robert Cooper ⁶ has characterized many things that successful companies do well. An interpretation of these, in the context of your business model, can help you design probing questions for your assessment. Don Clausing ⁷ describes many fundamental engineering methods and echoes the concern about soft causes in his description of "The 10 Cash Drains." You may recognize many of them as root causes in your own business. Let's look at our list of soft causes in a little detail.

Inadequate Project Management Plans

A development process to achieve higher reliability should follow strategies chosen by the project to have the highest probability of success. It may leverage mature designs. It may be dependent on the development of specific technical concepts achieving prerequisite robustness. It may collaborate with other companies that have necessary and complementary technical capabilities. It may depend on extensive modeling or experimentation in the early development phases. In whatever way the strategies are intended, the project management plans must then reflect their relevant activities, dependencies, timelines, milestones, and resources. The plans have to show how the strategies will be implemented. If the resources or funding is not available, the plans may not be achievable and the strategies may not work.

Another concern is that the project management plans must deliver key parameters to the project's business plan. For example, if the plan to achieve the required reliability is not acceptable or achievable, the initiative to achieve the reliability requirement is set up to fail. So if the project plans are not achievable, the business plan also is not achievable and the project should not be chartered.

Inadequate Development of System Integration and Robustness

This is a critical concern for reliability development, being part of the foundation for the familiar guidance to "achieve quality early." To the extent that these criteria are not satisfied, additional risks are incurred and the objectives for quality, reliability, and durability are in jeopardy, as are those for schedules and cost structures.

The evidence of robustness is the specification of critical design parameters that have been demonstrated to control the mean and standard deviation of performance under expected stressful conditions. The specification and configuration control of these set points are the objectives of Critical Parameter Management (CPM). During the product design phase these functional parameters are converted into design parameters suitable for product manufacturing and service. Without them, there is no sound basis for the specifications of a design.

Important actions include these:

• Technical concepts should be developed to be robust for the application prior to becoming baseline for the product development project.
• Subsystems should be developed to be robust within the system architecture prior to being integrated with other subsystems.
• Robustness should be optimized at the system level in order to specify the parameters that must be controlled by the production processes.

The strategy for robustness development must incorporate an understanding of the roles and benefits of specific methodologies, many of which are discussed in later chapters. From a project management viewpoint, sufficient time needs to be allocated for the selection of the best design concepts and for the planning of experiments, avoiding a rush to cut metal and to build prototypes prematurely. Too many prototypes, built without the learning from previous generations, contribute to Don Clausing's concern for "hardware swamps." The rush to build-test-fix may satisfy management's desire to see things happen but may be contrary to sound engineering.

Effective product development is analogous to applied systems engineering. It follows a disciplined process of developing linked information and decomposing it to be useful at the various levels in the system hierarchy. Manufacturing and service functions are considered to be part of the system, as are the procedures for users of the product. The development process includes the flexibility to make changes easily within the system and to freeze elements upon which other developments are dependent. Although it is a disciplined process, it should be very adaptable to the technical and business characteristics of a project. The leveraging of existing information and designs is prudent and efficient, while ill-advised shortcuts introduce risks and can sabotage the project.

Changing Product Requirements

Your engineers create solutions to requirements that are understood in the technical language of their design concepts. The origins of these requirements fall into three fundamental categories:

1. The needs and preferences of your customers in selected market segments
2. The standards and mandates imposed internally by your company
3. The government regulations and industry standards for your markets and countries

Ideally these requirements are defined and clarified in the initial development phases and, in the ideal case, approved and frozen. In practice, life is not that easy. Requirements are vulnerable to misinterpretation, internal biases, lack of insight, disagreements, conflicts with each other, risks for achievability, and changing market situations. Feedback from customers may prove the initial requirements to be wrong or ambiguous. Your experience adds to this list. The consequences can range from being trivial to disastrous. If the requirements are vulnerable to changes, engineering is shooting at moving targets with an increased probability of major consequences for their delivered quality, costs, and schedules. If the requirements lack insight into the real intentions of their application, or lack clear differentiation from competitive products, the product and price positioning are in jeopardy. Failure to comply with regulations or industry standards can be a barrier to market entry. There is very little forgiveness.

Good practices are well developed to enable engineering and customers to work together so that designs not only solve the actual problems but also delight customers in ways that establish competitive advantages. Useful tools can enable the thorough and accurate translation of requirements from the language of customers into the technical language of engineering. They can then be decomposed to be applicable at the levels of subsystems, components, and manufacturing processes. Agile strategies for product development enable teams to react to late-arriving changes in requirements and to feedback from customers' tests of prototypes without dramatic consequences for schedules and costs.

It is the job of development teams to design the basic functions of the product, specifying the controllable parameters so that the product transforms the customers' inputs into desirable outputs, in spite of stressful factors that can cause deterioration or failure. Figure 1.1 illustrates this simple viewpoint. It's then essential for development teams to understand the input/output relationships in the applications and the uncontrollable stresses that can affect them.

Figure 1.1 The requirements for a product's output attributes are driven by customers (VOC), as well as by internal mandates (VOB, VOT) and regulatory standards (VOM).

There are two fundamental concerns that project leaders need to address:

1. There is a tendency for engineers and management to believe that
   1. They already know more than their customers
   2. The process for understanding the voice of the customer (VOC) is too expensive and time-consuming, or it places the confidentiality of the project in jeopardy
2. Requirements can also be driven by "voices" other than those of customers (VOC):
   1. There is the "voice of the business" (VOB), which tends to demand lower development costs, shorter schedules, and lower production costs, but often without comparable concerns for satisfying customers. Lean product development and sound strategic decisions early in the process align with this mandate. Start the project earlier, instead of depending on schedule pressures to compensate for delayed decisions.
   2. There's the "voice of technology" (VOT), which tends to modify requirements to reflect those capabilities that can be delivered within the cost and schedule constraints. Another version of VOT is the "technology push" scenario that assumes, often naively, that customers will benefit from a new technology because it's new.
   3. There's the "voice of marketing" (VOM), which tends to push a wide range of requirements focused on opportunities for current sales and market share. These can be a reaction to the latest market information and to sales challenges with current products.

These additional sources of requirements are not to be ignored. The worst case of technology push assumes that the benefits of the product are needed, that customers will accept and pay for whatever capabilities you deliver, and that there are no competitors. This is often called a "WYSIWYG" product, that is, "What you see is what you get." Of course, in a competitive market that strategy doesn't work.

In many cases there are valid and reasonable strategies to shortcut the VOC process. It may be that a few key people have more insights about future markets than do current customers. That's a gamble that may pay off. The challenge is to know when a rigorous VOC process must be included in the project plan and how to get more benefits from the investment in its process.

Risk Management

Many decisions are made during a product development project. Good ones clarify the direction of the project, enable the progressive freezing of information, and reduce risks. However, business and technical pressures can promote risk taking, even reward it. Risks are problems that have not yet occurred but might occur in the future. The probability of their occurrence is uncertain, as are their expected consequences for customers or for the company. When problems actually do occur, projects know that they have to be dealt with in a manner appropriate to their consequences. However, potential problems that have not yet occurred tend not to get the same deliberate attention.

Another way to say this is that problem correction is expected and rewarded, whereas problem prevention is a quiet competency that can go unnoticed. Problem correction late in the process tends to cost more than problem prevention. Excellence in achieving schedule milestones and the objectives for reliability and durability, for example, often is rooted in the capabilities of reducing risks, that is, avoiding the problems that consume valuable time and resources when they can be least afforded.

Good practices for managing risks reserve some capacity in resources to identify risks and to implement preventive actions, where justified. Contingency plans are the alternative. These are preplanned actions that will be taken to compensate for the consequences of the problem, when the problem does occur.

Collective wisdom and functional understanding are organized to identify risks and to characterize their expected consequences and probabilities of occurrence. This understanding can be based on experiences with previous projects, on specific technical or business insights, on scenario planning, or on other techniques. Often the foundations for a lower-risk project are put in place with decisions that are made in the early development phases, such as the selections of the development strategies, the system architecture, its design concepts, and their enabling technologies. The concerns increase when significant risks are ignored and risk taking is rewarded. But what are the costs? And who pays for them? For example, decisions based solely on reducing manufacturing costs can result in poor product quality or reliability, higher life-cycle costs, or a loss in market reputation.

Imagine a development project that achieved its requirements for quality, reliability, durability, production costs, and schedule, with no late crises that jeopardized its graceful market entry. Calculate the costs of delayed market entry, and then ask how much you could afford to invest in identifying risks and preventive actions. Remember the wisdom in "Pay me now, or pay me later."

Immature Baseline Technologies

Baseline design concepts are chosen in the early development phases. What criteria are used for their selection? How dependent on them is the product architecture? For new or adapted design concepts, what happens if their capabilities fall short of their expectations for the application?

The concern here is that new technical concepts may be chosen for reasons that are independent of the value they can deliver to customers. It may be that engineers favor a particular design concept for purely technical reasons. Possibly it enables lower costs or an attractive architecture. It may be one for which they have personal preference. It might be the key to major increases in reliability and durability. Fine, but is it ready to be commercialized by a product development project? Does it have functional parameters that control its performance and variability? A disregard for this question tends to place technology development within a scheduled product development project, imposing additional risks. A very difficult situation is created when the product's architecture is entirely dependent on a design concept whose technologies are immature, that is, neither superior to alternatives nor robust for the application.

We remember a disastrous project. The product's architecture was entirely dependent on a design concept that enabled a rather compact system configuration with lower power consumption and reduced acoustical noise. However, the control parameters of the design could not be replicated by available manufacturing processes. In robustness terminology, the process could not be maintained "on target with minimum variability." In addition, the environmental stresses from the product's applications caused shifts in the functional response that customers would not tolerate. Fighting these problems continued well into production. No alternative designs were available, primarily because the system architecture could not be adapted. The root cause of the problem was a decision made very early that "bet the farm" on the hope that clever engineering could compensate for a failure of technology development. It could not. The costs were enormous!

In preparation for its commercialization, a new technical concept must be developed to be superior to available alternatives and to be robust for the range of intended applications. These criteria say a lot. Products often compete with their technologies. What makes them superior to available alternatives? What does it mean to be robust for the application? Good practices include two basic deliverables:

1. A stream of alternative technologies developed in anticipation of the needs of future product development projects
2. An unbiased selection process that places available alternative concepts in competition, with selection criteria that include demonstrated performance and robustness relevant to the intended product applications

Examples of "available alternatives" can include a current design already in production, an analogous mature approach that can be adapted to a new application, a design available from a partner or competitor, or an alternative new technical concept developed in parallel. A selection process that is vulnerable to the loud, bully voice of a concept advocate will lack the objectivity that is necessary.

Lack of Clear Expectations

Management has substantial power to guide a development project and affect its outcome. Certainly they charter projects, review their progress, provide resources, and make decisions. They also have the role of setting clear expectations. These expectations may focus on functional excellence. They may demand rigorous integrity in data that are needed to support decisions. They may express a bias for costs or schedule compliance. They may emphasize concerns for risks, that is, reductions in uncertainty. In the absence of clear expectations, development teams are left to define their own acceptance criteria.

Routine conversations with management, as well as those during project gate reviews, are opportunities for these expectations to be clarified and reinforced. If the discussions are entirely business-oriented, the technical expectations are at risk. If the discussions are entirely technical, the development teams can tend to forget that they are managing an investment that is the generator of a new value stream with expected returns to the business.

The challenges for management are substantial. For the purpose of this discussion, they can include the need to

• Maintain an accessible and interactive relationship with development teams
• Ask probing questions with both technical and business insight
• Recognize good answers and understand their metrics
• Make data-driven decisions so that their customers win
• Set clear expectations for the effectiveness and efficiency of future project work
• Focus on the "critical few" risks that are most important to the business, rather than on the many potentially trivial "issues" that people tend to push on management
• Accept action items to enable the predictable progress by development teams
• Reinforce both flexibility and discipline in standardized development processes

Certainly there are other items for your list, but the important point is that your development teams listen to management. So management needs to be clear about the signals they send.

Lack of a Disciplined Process

Complacency can be a handicap for those companies that have dominant technologies, a high market share, admirable profitability, or a history of successful product launches. With deep pockets, money can be thrown at problems. An unfortunate side effect is that the realities of inefficient processes, growing competitive disadvantages, and customers choosing other companies' value propositions, among others, can remain outside a company's consciousness. Fundamental changes in the marketplace can be overlooked. Your company can become vulnerable to its own successes.

In these situations, the problems that have soft causes become much more fundamental than just product performance or reliability. Your basic business model may no longer be viable. Instead of your capability assessment providing guidance for continuous improvements, it may identify the need for major reengineering projects. Companies that survive over the long run often practice an ongoing reinvention of themselves. Those that do not often find themselves no longer being significant players in the market, or in some cases no longer existing. Although this concern is far beyond the scope of this book, to the extent that it exists it can be a major handicap to the development of reliable new products.

Inability to Speak Truth to Power

In the preceding discussion about the setting of expectations, the advice has been for management to have an "accessible and interactive" relationship with development teams. The absence of this relationship can easily jeopardize the ability of teams to deliver on their value proposition.

Suppose, for example, that management gave clear expectations that they did not want to hear bad news, particularly at gate reviews. This is a "shoot the messenger" scenario. How would development teams behave? Management may intend sternness and ridicule to motivate improved deliverables. On the other hand, such a policy may also prevent bona fide risks from being revealed or significant decisions from being based on the correct data. Project teams may not be willing to acknowledge problems, hoping to correct them before the next gate review. Worse yet, the development teams would be set up to be scapegoats for resulting failures. That situation is neither constructive nor efficient.

The quality leader Dr. W. Edwards Deming ⁸ was prescient when he urged management to "drive out fear." Rewards should go to those who are open and honest about the status of their project. Management needs to understand the truth early, when there's still time to react without jeopardizing the project's success.

This same intimidation may motivate project leaders to withhold any requests for additional resources or guidance. They may be convinced that it would reflect poorly on their own leadership capabilities. But who pays for this mistake? Imagine how constructive would be the process that brought the right resources to the right problem at the right time, regardless of a naive plan that was established sometime in the past. Independence and self-confidence are healthy attributes, but they can work against you. Certainly it's better to address problems when they are small, when their corrective actions can be managed easily. In his memoir, Harold Geneen, ⁹ the executive who built ITT into a multinational conglomerate, described his expectations on being open about problems. He felt that hiding problems was a waste of time, time being the one irreplaceable resource that his organization had. He expected his staff, when faced with difficult problems, to be open and to seek help early in the belief that the collective experience, wisdom, and skills of the organization usually trumped those of the individual.

When we work to solve problems, time is our most important asset. Letting too much time pass before getting help on a tough problem makes it more likely that schedules will suffer and that the delivered product performance and reliability will fall short of expectations.

Failure to Implement Lessons Learned

Many organizations engage in the struggle to get a new product to market faster but do not allocate time afterward to learn about what went well and what did not go well. These lessons learned are important contributors to continuous improvement. Without organizational learning, the mistakes of the past tend to be repeated. This can generate inadequate technical and business results across the portfolio. It can also demoralize the workforce who see the same mistakes being made over and over, and who will wonder if product development work will ever become less stressful.

A key element of organizational learning is the clear intention that the evaluation process not be a negative one, that is, one that is perceived to place blame on individuals or teams. To the extent that it is managed to be blameless and clearly intended to build wisdom into follow-on projects, with a top-down commitment to act on the results, it will be a healthy and anticipated process.

Inadequate Development Budgets

If teams are required to shorten development time and also to reduce their resource budgets, they may have objectives that are overly constrained. For example, it is often the case that an overrun in the project's development budget will have only a small impact on a new product's profitability. However, spending more money on resources to commercialize the product earlier, with higher quality at launch, can enable higher revenues and contribute to lower manufacturing and service costs. Unfortunately, budget compliance often gets more attention, probably because it is more easily measured and is a familiar measure of management performance.

This discussion of common soft causes of problems reinforces the notion that product development, although often perceived to be a set of technical activities, is managed in the context of a wide range of processes and behaviors that have the potential for either positive or negative consequences. That depends on how they are managed. The assessment of your company's capabilities and of the related needs for their improvement must include these soft concerns as well as those more technical hard causes.

Throughout this book we intend to shed light on both categories for improvements, particularly to the extent that they can contribute to the development of improved product reliability.