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

Management of Process Improvements

The process of change for an organization can be difficult, with nontrivial risks for achieving the intended benefits. Probably you have experienced this yourself. There can be many sources of resistance. The investments that are required may be beyond those that are thought to be affordable or worthwhile. The challenges to learn new methods may be viewed as not contributing to short-term imperatives. People in power may not believe that the problems being experienced are severe enough to justify the changes. Paradigm changes may not be understood easily. We expect that you can add to this identification of barriers easily.

Certain factors have been found to be critical to success in changing the approach to product development. Examples include the following:

• The reasons for the change must be clear and compelling, both for major transformations and for reforms in the context of continuous improvement.
• The adoption of new methods must be developed internally so that ownership is with the people who must practice them.
• The implementation process must be embraced and enabled from the top down. The improvement plans must have objectives that harness the corporate energies.
• The change process must achieve measurable results early to demonstrate the benefits and to build confidence and momentum within the organization.
• The timing of implementation must not be so disruptive that the organization resists it as a "theme of the month." Remember this advice: "The best time to fix the roof is when the sun is shining."

There are several good sources for useful insights and practices for change management. You may find the work of John Kotter ¹ and others to be interesting and applicable.

Clear and Compelling Call to Action

With probing, open-ended questions your evaluations of recent development projects can identify those practices that provide competitive advantages and those that consistently put your projects at a disadvantage. Where should you focus? Clearly your business achievements and disappointments will set your priorities. Capability assessment tools can identify the gaps relative to "best in class." Cause-and-effect diagramming can establish probing questions to identify those factors that contribute a larger impact and have a higher probability of occurrence.

For example, suppose your projects miss schedule milestones consistently, with market entries being late. What are root causes that can be addressed? Certainly your projects will have their own specific factors that contribute to these difficulties. If it seems evident that project management practices are deficient, the Project Management Body of Knowledge (PMBOK) ² can guide probing questions about practices and their integration. If it seems that engineering practices are sound, but cross-functional interactions are too iterative and contentious, the principles of effective product development and of high-performance teamwork ³ can provide probing questions. Clearly there can be complex interactions among the many factors.

What does not work well? What are their causes and effects? Here are some thought provokers that are relevant to our topic of reliability development:

• Weak design concepts: Reliability problems caused by immature or inferior design concepts that cannot be controlled well enough can force too many design changes late in the development process. Those that have consequences for tooling and parts inventories, for example, can lead to schedule slips and cost overruns.
• Delays in market entry: Major schedule slips increase development costs, threaten revenues, and have serious consequences for those organizations mobilized to launch the product. Long, repeated delays can jeopardize the competitive product positioning and threaten the reputation of the company.
• Escaping reliability problems: In addition to dissatisfying customers, design and manufacturing problems that are not prevented prior to production impose higher service costs and the potential need to retrofit design modifications or to recall products.
• Constrained human resources: Not having enough of the right skills or experience working on specific problems can cause inferior or delayed solutions. This problem raises the question of whether to hire, to develop internally, or to outsource the missing skills.
• Constrained prototypes: Additional prototypes may be necessary to develop robustness and grow reliability, or to obtain customer feedback. That may require additional funding and development time, which management may not tolerate.
• Overloaded resources: Centralized functions may be staffed only to maintain a high level of utilization, leaving no reserve capacity for variations in demand. The lack of capacity when needed may be a root cause of conflicts among projects and queues that steal development time. For example, the lack of access to an overloaded testing facility may cause important tests to be skipped in deference to the schedule or delayed to the extent of jeopardizing the product launch date. This problem can be anticipated if there is an integrated approach to project planning when using shared resources rather than a culture of competition, where the project manager having the dominant personality gets satisfied first and everyone else fights for the leftovers. Typically, overloaded resources and top-down pressures lead to multitasking, which actually tends to reduce efficiency and further aggravate the resource problem. For a more detailed discussion, in the context of Critical Chain Project Management, see Leach. ⁴
• Lack of attention to risk management: Project teams may not be diligent at identifying risks or reducing them. Certain risks may become actual problems that must be resolved, often an expensive process that can delay the product launch. The management of risks takes resources, time, and management attention, all of which may be in short supply.
• Bureaucratic decision processes: Management gate reviews and other decision processes may be difficult to schedule or may demand iterations of reviews to answer unexpected questions. Those iterative reviews may actually dilute responsibilities rather than reduce risks. They may tend to add little value for customers and cause significant delays along the project's critical path. They often fail to draw sufficient attention to the rate of reliability growth that lags behind expectations and needs management intervention.
• Lack of flexibility in a design: The system architecture of a product may depend upon the robustness of a specific design concept. If that is not achieved early in the project, the inability to change to another, more robust design concept may cause serious consequences for schedules and costs. The capabilities of the entire product and its development schedule can be in jeopardy.
• Late changes in requirements: The development of complex, heavy metal products can benefit from requirements being defined and frozen early. However, many products are aimed at markets that can change rapidly, leading to either late-arriving feedback from customers or new expectations set by competitive entries. Design architectures or development processes that cannot accommodate late changes gracefully can be plagued by the consequences to their schedules and costs.
• Weak investment in early development: Design concepts that are chosen to be baseline may be found to lack sufficient robustness in the early development phases. This can lead to numerous problems that can force costly corrective actions in the later development phases.

Of course, the list of possible problem-cause scenarios is endless. The challenges for your capability assessment are to identify the business results that are not acceptable and to establish their priorities and their root causes. Process solutions can then be devised, often with assistance from outside specialists who can bring wisdom from their experiences with other projects or companies. The business case for improvement initiatives can then argue for resources, justified by a "call to action" that is derived from the consequences experienced.

Internal Ownership

When new "best practices" and methodologies are introduced, they rarely become "common practices" until lead users inside your projects demonstrate their benefits. It takes learning and experience for people to become believers. With internal experts coaching project work, the consequences of the learning curve for project cycle times can be reduced. Once the benefits are seen to be important to a project's objectives, the new practices can be built into the project's plans. When management understands the intent of the new practices and their technical or business advantages, they can set expectations for their appropriate use. This can be very powerful. Without reinforcement by project leaders and management, new practices with high potential value can be set aside in favor of the more familiar "way we always have done work."

Top-Down Enablement

People in power positions may feel threatened by suggestions that current strategies and capabilities do not work well enough. They may see a recommendation as a reflection on their own personal competence rather than a concern for a corporate process or method. They may not appreciate the long-term value of time off the job for training or of the investment in new software tools. For example, getting customers on your project team may be viewed as too troublesome or a violation of project security. However, pilot projects can show how substantial the benefits can be. The emphasis on the development of superior robustness may take a clear understanding of why a design-build-test-analyze-redesign strategy under nominal conditions is not sufficient. Learning from other companies can help a lot.

It should be in the interest of management to promote changes that will add value. Without their participation, bottom-up initiatives tend to be short-lived, doomed to falling short of their potential impact. It helps greatly to have a high-level champion whose commitment is based on painful experiences. Members of the management team need to be the suppliers of resources, the stakeholders in the expected benefits, and the drivers in the implementation of changes. An effective tactic is for management to teach and coach the new principles and methods. This has a powerful influence on how well new methodologies are understood and integrated. It also ensures that individuals and teams recognize them as being expected in how they do their work.

There is major value in the expectations and rationale being set at the top of the organization. Subsequently, these expectations must cascade throughout the organization and be reflected in individuals' performance. Clear expectations drive behavior changes if they are reinforced in top-down communications and applied in the probing questions and acceptance criteria for project reviews. It is management that enables major changes through strategies, resources, motivation, and a constancy of purpose. It's also management that can sabotage major changes by not making their support deliberate, visible, and consistent.

Bottom-Up Improvement

What if there is no upper-management support for a major overhaul of the product development process? Should you assume that there is no point in trying to improve? Fortunately, even with management reluctance, it is still possible to make improvements. Usually management recognizes when things are not optimal. They would like capabilities to improve, so it is very unlikely that they will prohibit the use of better methods and processes as long as improvements don't jeopardize schedules, budgets, or product quality. If all you can get is indifference, take it. It is better than active interference or prohibition. The problem is that everyone is tired of the "program of the month." A major process overhaul requires the commitment of time and money, making it very difficult to argue that there will be an acceptable payoff. This is especially true if people have been disappointed with past initiatives. Under these conditions, a better way to approach the problem is to scale back from trying to make the "big win" and concentrate on demonstrating success on small subprojects. Shoot for small initiatives that will be "under the radar." It is easier to get buy-in after you have demonstrated improvements. When success happens, publicize it. Before long there will be supporters.

Objectives with Substantial Impacts

What are the objectives of your major improvement initiatives? Examples may include

• Higher levels of customers' satisfaction
• Higher quality in new products and services
• Higher product reliability and longer usage life
• Lower manufacturing and service costs
• Lower development costs
• Shorter, more predictable time to market

These objectives may be obvious. What else applies to your situation? All can have a direct impact on the profitability of the portfolio of new products. They are measurable, but what are their criteria for acceptance? How well are these objectives related to the success of your business? How well can they be reflected in the performance expectations for individuals, teams, and projects? Development time can be measured for a project, but is the real objective a shorter time or the more efficient use of time? Is it increased "leanness" or higher productivity? Possibly a better objective is to start on time.

Is a lower failure rate the objective, or should the emphasis be on reducing those failures with the higher severity levels? Should the project teams care more about constraining development costs to comply with budgets or about getting the right functionality, quality, and reliability to the market on time? Are all development projects comparable, or is each one unique in its challenges? The setting of objectives is not easy, particularly since if it is not done well it can create unintended incentives for the wrong behaviors.

Are these objectives independent? Probably not! Higher product reliability and durability will contribute to higher customer satisfaction. So will features and functionality that are not provided by competitive products. More customer benefits can enable higher prices without jeopardizing the perceived value. Lower manufacturing and service costs can enable lower prices. Lower prices can contribute to higher perceived value and higher manufacturing volumes, which in turn can decrease unit manufacturing costs and increase profit margins. A more efficient product development process should reduce development costs and enable on-time market entry with a more predictable beginning of the revenue stream.

Early Measurable Results

It is through performance expectations, cascaded throughout the organization, that the necessary actions and behaviors can be driven. This is particularly effective if people's paychecks are affected. For example, if engineers are required to shorten product development time, but managers are not expected to start development projects early enough, it will be clear that the engineers are to be punished for a failure in management. There is a powerful message sent when development teams share performance expectations with upper management. Balanced scorecard methods ⁵ provide a way to make the change process important to everyone's wallet. People then work to the same set of goals. Here are a few suggestions that may be helpful:

• Know what excellence looks like. It will give you benchmarks against which to establish your capability gaps and important projects for corrective actions.
• Evaluate your current experiences with an eye to the business consequences, not just to excellence in the scientific or engineering results.
• Identify lessons learned from past projects and from benchmarking. Incorporate them into the functional and project plans and the standardized business processes.
• Allocate funding, labor, and management bandwidth to the development and implementation of process improvements. Otherwise, not much good will be achieved and the past will also be the future.
• Do not try to fix everything at once. Focus on the "high bang for your buck" opportunities. Prioritize your improvement activities to achieve quick, visible results that build enthusiasm and confidence, and then form the basic foundations for longer-term improvements.
• Keep it simple. That doesn't mean that learning sophisticated methods is to be avoided. However, if a collection of improved engineering strategies and tools is the answer, their direct relevance to "bottom-line" benefits needs to be demonstrated for and understood by those who provide the funding and resources.