Project Management for Automotive Engineers: A Field Guide 0768080770, 9780768080773

Citation preview

Project Management for Automotive Engineers: A Field Guide By Jon M. Quigley and Roopa J. Shenoy

Warrendale, Pennsylvania, USA

Project Management for Automotive Engineers: A Field Guide Front Matter Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Project Management for Automotive Engineers: A Field Guide

For more information or to order a book, contact SAE International at 400 Commonwealth Drive, Warrendale, PA 15096, USA; phone 1+877-606-7323 (U.S. and Canada only) or 1+724.776.4970 (outside U.S. and Canada); fax 1+724.776.0790; email [email protected] website books.sae.org

400 Commonwealth Drive Warrendale, PA 15096-0001 USA E-mail: [email protected] Phone: +1.877.606.7323 (inside USA and Canada) +1.724.776.4970 (outside USA) Fax: +1.724.776.0790

Copyright © 2016 SAE International. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, distributed, or transmitted, in any form or by any means without the prior written permission of SAE International. For permission and licensing requests, contact SAE Permissions, 400 Commonwealth Drive, Warrendale, PA 15096-0001 USA; email: [email protected]; phone: 1+724.772.4028; fax: 1+724.772.9765. SAE order number: R-437 DOI: 10.4271/R-437 LOC: 2016935548 Information contained in this work has been obtained by SAE International from sources believed to be reliable. However, neither SAE International nor its authors guarantee the accuracy or completeness of any information published herein and neither SAE International nor its authors shall be responsible for any errors, omissions, or damages arising out of use of this information. This work is published with the understanding that SAE International and its authors are supplying information, but are not attempting to render engineering or other professional services. If such services are required, the assistance of an appropriate professional should be sought. Print ISBN:

978-0-7680-8077-3

To purchase bulk quantities, please contact SAE Customer Service: Email: [email protected] Phone: +1.877.606.7323 (inside USA and Canada) or +1.724.776.4970 (outside USA) Fax: +1.724.776.0790 Visit the SAE International Bookstore at books.sae.org

Preface Numerous books on project management have been written. Many are theoretical in nature, and a few cater to the IT industry, but we feel little has been written to capture the challenges faced in executing a project in the automotive industry. Another drawback of the current literature is the overemphasis on tools and terminologies (e.g., agile, six sigma, PMP - project management professional, and lean) rather than focusing on the essential skills needed to successfully execute the project. In this book, we look at the field of project management as a risk-based decision-making activity, driven by continuous learning and adapting to the changing scenarios, not merely following a set of steps. As project managers, we frequently are faced with changing requirements, different work scenarios, and difficult decisions. We narrate a story that summarizes the crux of the dynamic nature of project management. The story is titled “A List,” and it is part of the “Frog and Toad” series written by Arnold Lobel in 1972. It is about a toad and a frog, who are friends. One day, the toad creates a list of things to do, so he can execute the task at hand in a timely and orderly fashion, which we would refer to as a project plan. The toad begins to execute the tasks on his list, and everything stays on track. Per toad's activity list, he meets up with his friend, frog, and goes for a walk. While on the walk, a strong wind blows the list from his hand, and the toad refuses to chase the list, as that activity was not part of his list! He fails to react to a situation he had not planned. Nobody can plan for everything, certainly not the wind blowing away the very list that was meant to help get everything done. The essence of what we should learn from this fable is that as project managers (PMs) we excel in creating elaborate time plans, with activities that meet the project milestones, hoping the plan would get us successfully to the end, until a strong wind blows our plan away, and we refuse to adapt, and attribute the failures to scope creep. When the risk becomes a reality, the project manager often struggles to adapt and react in a timely manner, like the toad, to control the situation. In many cases, this results in failed projects or projects that do not meet project timelines, and produces wasted effort. We endeavor through this book to better prepare our fellow project managers to anticipate changes—to react swiftly and be watchful for triggers for project risks. We provide practical examples, based on our cumulative experience managing projects of various degrees of complexity in the automotive industry. Taking a pedagogical approach, we have included “Box Moments” in the text, which illustrate practical examples or key points to be aware of while working on projects. For a practicing or an aspiring project manager, these hints will be helpful.

Project Management for Automotive Engineers: A Field Guide serves as a reference for a practicing project manager, explaining critical concepts with examples based on the authors' experience in the automotive field, featuring engineering complexity and leadership challenges. The book is divided into ten chapters, with a brief introduction to project management in the first chapter and a summary at the end. As project management in the automotive industry is intrinsically linked to the product development process, the subsequent chapters focus on the project management aspects that are significant during the different stages of a product development cycle. We readily recognize that the automotive industry also includes projects such as cost improvement and manufacturing updates that are not focused on new product development (NPD). However, this book focuses on the product development application. Other chapters emphasize business case evaluation, product development cycle, process development cycle, test phases, and production ramp up at the plant and at the Tier 1 supplier. We also focus on the various challenges of a matrix organization. Last, we discuss the principles of value projects, and how to revive failing projects. How to get the best from this book Unlike other project management books, you can hop from one chapter to another without losing synchronization to the whole theme. As a reader, if you would like to learn and focus on original equipment manufacturer (OEM) testing, you can start with chapter 6. The chapter is broken down into the fundamentals of the testing process, what the project gains from testing, when it is important, and what critical measurements are needed to make it successful. The book's focus is on various project management topics and challenges including organizational structure and global footprint, resource management, product development, and process management. Critical aspects of product development and ramp-up plans are unique to the automotive world. We place special emphasis on addressing design and process documentation required to accomplish a good production start. We sincerely hope you enjoy the book and find the examples useful in making critical decisions at your work. Most of the concepts in the book are not new but are presented from the unique perspective of the automotive industry.

Jon M. Quigley and Roopa J. Shenoy

Project Management for Automotive Engineers: A Field Guide Chapter 1: Overview of Managing Automotive Projects Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 1 Overview of Managing Automotive Projects

“You have to learn the rules of the game. And then you have to play better than anyone else.” —Albert Einstein

1.1 What is at Stake? Around the world, approximately 806 million cars and light trucks were on the road in 2007, with 86 million vehicles sold in 2013 alone [1-1]. The automotive industry including its supplier base, automotive services, and the oil industry combined are a source of employment for millions and significant contributors to the global economy. The numbers demonstrate that the stakes are high in the automotive industry. A successful product can enhance the company's reputation. Take, for example, what Corolla did for its maker, Toyota. Through several redesigns in the last 40 years, Corolla has become one of the bestselling nameplates in the world [1-2]. Similarly, if the new product has poor quality issues, a high cost is associated with fixing it. This cost will include administration of recalls as well as the damage that is done to the company's reputation and its growth potential. According to the survey conducted by the Standish Group International [1-3], in the year 2008, only 32% of the projects succeeded by delivering the expected outcomes on time, with the intended quality and features, and on budget. This statistic should not be surprising to project managers around the world, and it emphasizes the need for project management skills to handle mega-scale projects. In the global economy, automotive projects involve across-the-board resources and the convergence of many disciplines, challenging sourcing strategy and logistics, and necessitating compliance with legal requirements related to safety and pollution. The organization may have multi-site product development, manufacturing, and assembly processes, which adds complexity into project management. Automotive industry projects require high investments in terms of R&D budgets and can take many years to be completed. These costs are related to design, tooling, supply chain management, changes to the production line, and marketing activities. To maximize the return on investment, a typical project affects a high volume of models, and thus has the potential for higher risks. To handle this, most companies in the automotive world use a phase-gate product development process; this allows for a controlled

maturity of the product and process (refer to chapters 4 and 5). The project manager is expected to deliver the project by following the product development (PD) process, an essential part of product success in this industry.

1.2 Overview of Project Management Areas In the next four sections, we discuss the key elements of project management: project scope, cost management, time and schedule, and risk management. In the later part of the chapter, we cover organizational influence, communication, and contract types in greater detail.

1.2.1 Project Scope Project scope outlines the goals and constraints of the project based on the market, customer, or business requirements. This is the core of the project, including the project's sponsors, and dictates all the actions and activities required to deliver the objectives of the organization. In some cases, the scope of the project is governed by legal and/or safety requirements. The scope statement is used to develop the project profile, which is employed to define the project's delivery prioritization, and the impact matrix applied to assess risks and resource planning. Using the impact matrix, it is easy to prioritize the delivery based on cost and risk. As shown in Figure 1.1, if the customer really cares for Item #1 and Item #4, the matrix clearly shows that the investment is identical for both, but the risk differs. The project manager (PM) can then put the risk mitigation plan for the project delivery in the early phases of the project.

Figure 1.1 Example of the impact matrix.

If the scope of the project heavily impacts manufacturing, manufacturing risks related to product and process changes should be assessed along with the resource capability to execute the changes. In Figure 1.2, the early-pass requirements are recorded to help establish the impact to different departments and drive the project profile.

Figure 1.2 Developing the project profile.

The project profile is used throughout the project life cycle to prioritize the activities for the project team, and to help focus on key deliveries associated with the project and product objectives. Through a clear definition of the scope, the team determines the risk exposure in the context of the project. For example, an incremental adaptation of the existing product has a lower level of risk if compared to introduction of a new product line. The risk grows with a larger scope, increasing degrees of variation, and interdependencies with other projects. Figure 1.3 describes the three main dimensions of project management.

Figure 1.3 Three dimensions of project management.

The project scope is governed by time schedule, quality, and cost. Changes to any one of the dimensions will affect the delivery of the product. In an effort to achieve synergies or save money, the project scope could get loaded up with nice-to-have features, with the wish to

increase the product portfolio. These “new” additions alone can multiply the project cost as well as risks, resulting in low profitability for the product. In some cases, the synergies can be good and should be used to drive changes for efficient use of resources within the company.

Take time to prioritize the features and objectives of the project scope. Understand the connection between the increase in scope and project cost, schedule, and risks.

The scope of the project should always be kept under control, and any changes should follow the defined protocol and agreement in the project meetings. This discussion must determine financial implications and impact to the project's hurdle rate, and the desired outcome. The conclusions of this process should be presented to the governing body for the decision. The governing body will be discussed at length in a future chapter. It suffices now to say that this entity consists of executive management and helps make decisions and guide the project. Experience suggests that uncontrolled changes are one of the biggest reasons for project failures. Projects lose considerable time to delivery as well as costly rework due to uncontrolled changes, also known as scope creep. One of the tools used to capture the entirety of the scope of the project is the Work Breakdown Structure (WBS) [1-4]. The WBS resembles a product bill of materials (BOM), and it is a hierarchical deconstruction of all work required to produce the project scope. This deconstruction of the total scope into discrete and specific actions ensures that all required targets and deliveries are met. Further, by effective use of the WBS, the cost estimation becomes more accurate. Smaller pieces are easier to define and estimate. The WBS can also uncover other attributes needed for successful execution of the project, such as resource needs, training, tools, and partners. For example, if the scope defines the development of a new hybrid car, the early estimate could show $X million needed for the new platform. After further analysis, the WBS can define changes needed in the hood, engine, electrical architecture, support in the market, change in the factory, etc., and such a thorough analysis then can help to refine the original estimates.

1.2.2 Cost Management Project acceptance is based on the business case, profitability, or fulfilling a strategic need for the company, such as entering a new market to improve the company's competitive position. Cost management is employed for addressing both product and project costs. These are used in the profitability calculation through the project life cycle to justify the project. In the case of strategic projects, the profitability calculation can be downplayed by justifying the market

needs and the organization's long-term objectives. Cost management requires input from the different stakeholders to accomplish the task, and then securing the budget and monitoring the project spending. Earned value management calculations are continuously reviewed to check the rate of spending against the plan. Earned value management consists of a set of equations associated with project metrics and execution that provide cost predictions. Budget estimation, which provides the cost baseline, can be done using the following methods: Bottom-Up Estimation: The team provides the best estimate after reviewing the scope. This is the preferred method, since the estimates originate from the experts, creating awareness about the project. It also helps establish buy-in from the team members. Estimates that originate from the people who do the work are more compelling than estimates sent down from on high by those who do not perform the work. Estimates from the team are believed to help establish engagement and commitment to the project deliveries. Top-Down Estimation: Executives and the management team provide the estimates based on limited information. It is typically done quickly or in an ad hoc manner. There is considerable risk to achieving the cost target, and the project manager should assume high variation in the final cost from the estimate. Top-down estimates are also done to get the company's pet projects in the pipeline. A pet project is a project for which an executive has great enthusiasm. This energy and optimism may tend to override the business case (can be viewed as strategic) considerations, and to initiate the project the executive may choose a top-down approach. Historical and Analogous Estimation: This exercise engages the team members to compare the scope to earlier completed projects. The team then uses expert advice and adds a risk factor to provide the estimates for the new project. Parametric Estimation: Data and proportional relationships from previous projects are used to determine the cost. A good scalable relationship must exist, both from the project and product perspectives, with the baseline project. For parametric estimation to work, the present project must have considerable correlation to any being compared to. The larger the discrepancy, the larger the associated risks with this estimation method. Whatever the chosen method may be, once the baseline estimate is established, the project manager is always challenged to meet the baseline target. Imagine a project manager's challenge to bring the project cost down when the earlier estimate was done ad hoc without solid information. The team will be continuously challenged to beat the expected cost, and for faster delivery.

1.2.3 Time and Schedule

In some cases, the initial schedule or the expected start of production is driven by marketing. In legal projects, the government plays a significant role in setting the requirements, and the automotive industry as a whole negotiates with the government for the best date for the product or feature introduction. Legal projects are those that must deliver to meet a legally mandated expectation to allow the firm to remain in business. The sales and marketing team tries to establish what are often non-practical expectations very early on in the project, which forces the project team to come up with a response and justification to complete all the activities to meet the expected quality product delivery. The project team should employ a pragmatic approach by breaking the scope into smaller pieces, analyzing development time, and testing time to arrive at a reasonable estimate to launch the product. Always be mindful of the “wind” that blows away everything, as we stated in the introduction of this book. It is important to note that no matter what the method of estimation at the initial phases, the team is making an educated guess on what is required to meet the project scope and organizational objectives. For a legal project, a hard delivery date, which is mandated by the government, must be met. In these cases, the introduction date becomes a high priority in the project delivery. With the WBS method, the estimation can be narrowed down to very specific work items. The method also uncovers what work can be done in parallel to improve the timeline and activities with interdependencies. The sum of the duration estimates of time for each WBS element makes up the amount of time required in the total project schedule. This, in turn, identifies the start of production date for the project. Understanding the interdependencies, meaning that one of the tasks must happen with some sort of link to the other task, is an important exercise for the project team. This identification should be done from a cross-functional perspective at various levels of the time plan management. Product design personnel should know when to freeze the design to kick off tooling with the supplier, which interconnects the parts available for the testing purposes. The first level of time planning should capture departmental interdependencies, and at the lower level, it should also capture activity interdependencies.

To meet the challenge of improving the project's time plan, understand the risks associated with task interdependencies. One loop of the development and test phase should be completed and reviewed before starting the second loop of development. This is essential if you are working with agile development.

There are four different interdependency types: Finish-Start: This is the most used type of relationship, where one activity cannot start

without the end of the previous ones. System testing, for instance, cannot start until all the parts are secured and used to build the test unit. Start-Start: Both activities start at the same time. In this type of dependency, one task cannot start without having the other task started as well. Start-Finish and Finish-Finish: These are infrequently used types of dependencies. Figure 1.4 shows the graphical representation of the dependencies between the tasks.



Figure 1.4 Graphical representation of task dependencies.

Modern day complexity is not just in the end product, but in the ways of working that may require us to adapt. While we are more connected as a community via the internet and cellular telephones, we are also more distracted by these same devices. Additionally, for years, organizations have re-scaled, re-engineered, and adopted a more-with-less philosophy. The final result is a constant erosion of available talent within the organization, or a push to outsource for greater efficiency. Some of the intricacy in way of working could be related to: Multiple projects: At one point, project managers as well as the line organization personnel work on multiple projects. This multitasking requires constant resource shuffling. In most instances, this is neither efficient nor focused to produce successful results. In the case of priority projects, such as regulatory projects, the project manager should work diligently to keep the resources secured and focused on the necessary outcomes. An agile method will help keep the resources on the development or evaluation phase, thereby keeping the focus and energy on the project objectives. Agile is a project management approach developed for software products to address technical uncertainty and risk. The method relies less on formalized and rigid processes and more on people, objectives, and adapting to the situation as the team learns. This topic will be treated in greater detail in chapter two. Constant juggling of the priorities: Companies might rank the priority of their projects, which can be changed frequently over time by new market conditions or management's own new priorities. This can cause confusion throughout the project, and it will have a severe impact on new platform development or legal projects. To solve this conundrum, it is necessary to have a clear priority list, which is constantly revised with all stakeholders. Talent erosion: A common issue found in companies that have a high turnover of human resources is the lack of knowledge management. This problem is especially damaging in countries such as India with a fast growing economy, where the erosion could be as high as 26% [1-5]. This could cause delays in the project delivery as people change jobs and information management is poor. The Harvard Business Review article titled “Six Myths of Product Development,” written by Stefan Thomke and Donald Reinertsen, demonstrates the logical conclusion in myth number one, “high utilization of resources will improve performance” [1-6]: They don't take into full account the intrinsic variability of development work. Many aspects of product development are unpredictable: when projects will arrive, what individual tasks they'll require, and how long it

will take workers who've never tackled such tasks before to do them. Companies, however, are most familiar with repetitive processes like manufacturing and transaction processing, where the work doesn't change much and surprises are few and far between. Such processes behave in an orderly manner as the utilization of resources increases. Add 5% more work, and it will take 5% more time to complete. Processes with high variability behave very differently. As utilization increases, delays lengthen dramatically. Add 5% more work, and completing it may take 100% longer. But few people understand this effect. In our experience with hundreds of product-development teams, we have found that most were significantly over-committed. To complete all projects on time and on budget, some organizations we worked with would have needed at least 50% more resources than they had.

Over-utilization of human resources is a key risk area for many a project—be aware and respond accordingly—do not over schedule resources. With 80% utilization, the resources still have 20% time available for adapting, learning, and accounting for unexpected contingencies. Be also cognizant that there is a difference between the actual times spent working or developing solutions, and the time to report the status to the variety of committees and management involved in the project. If the resources are being used up in meetings and working on reports more than focusing on the actual development, the efficiency of the process should be questioned. Next, we will talk about network diagrams, dependencies, and the Gantt chart, which will lead to the discussion of the concept of critical path. The network diagram (Figure 1.5) shows the durations and dependencies for a given collection of tasks. It is an important concept that if one of the activities gets delayed, it can lead to serious consequence to the others, and to the subsequent project delivery dates. Experience indicates that these interactions or exchanges are often the areas of most risk and problems for the project. The receiving person does not get what is needed in time, or at the required level of quality, to allow them to proceed. This means the output from the receiving person will be delayed, and so on.

Figure 1.5 Example of a network diagram.

Another way of viewing the project tasks and dependencies is through the Gantt chart. This chart has benefits over the network diagram in viewing of responsibility, and start and completion dates associated with each activity. The Gantt chart is populated with those activities found in the WBS. Figure 1.6 shows a Gantt chart with the work breakdown structure item on the left, and interdependencies with percentage completion on the right. The chart also gives a quick snapshot of the critical path depicted in bold black (image zoomed in Figure 1.7).

Figure 1.6 Gantt chart.

An important advantage of the Gantt chart is that it allows us to predict the end date. As we build the chart with the events and connect the dependencies, we can discern the possible date

for completion of the task and ultimately the product launch date. With the tracking Gantt chart, a baseline is developed for the schedule, and the performance is tracked against the plan to monitor the projected completion date based upon the team's ability to deliver. This is much like how the estimated time of arrival (ETA) works on the global positioning system (GPS). Any deviation is recorded in the risk register, with a resolution to find possibilities to put the project back on track. Building the Gantt chart allows us to visualize the critical path for the project. The critical path is defined as the longest path in the project to accomplish the project objectives. This is the shortest time in which the project can be completed without padding or slack. Where there is no slack, there is little chance for success. Therefore, once the slack is gone, the project is in dire straits.

Figure 1.7 Gantt chart showing the critical path in bold black.

The critical path should be discussed in the project meetings with all the stakeholders and should capture the input from all the departments. Any time the project status is reviewed, the focus should be put on the critical path. If the design freeze is delayed by three months, and the production date does not change, the time plan should be critiqued.

The critical path is a living path, which changes with any change in scope, delivery, execution mode, talent, assumptions, and even objectives of the final project. The critical path should be monitored throughout the project life cycle.

1.2.4 Risk Management Project managers exist to facilitate or ensure that the project objectives are met, and a cornerstone of project management is the proactive risk management. A prudent project manager will consider the risks throughout the project with special note during the scope development, and contrive strategy to achieve those objectives. The major risk management

activities are: Identify issues that can cause project failures Assess and prioritize activities according to severity and probability of consequences Develop a risk response strategy: Eliminate risk by choosing alternative courses of action Transfer the responsibility for the risk (outsource or insurance) Mitigate risk by taking actions that either reduce severity or probability, or both Accept the risk Monitor for risk symptoms and bring planned actions to reduce the impact Figure 1.8 illustrates the continuous chain of events that the project manager should be following. Every time a risk is identified, it should be assessed and an appropriate plan of action developed, which includes measurements to help predict if the risk is becoming a certainty. The risk should be assigned to a specific team member for monitoring. Monitoring the risks requires a constant check on symptoms by the person most logistically responsible. By limiting the speculations to the boundary conditions, the noise or distractions affecting the project can be reduced. As the project continues, there could be new advancement in technology, new process, or any other change that could make a difference, positive or negative, to the overall deliverables. Note as much as possible, recording everything in the risk register. In short, the graphic represents the PDCA cycle—Plan, Do, Check, and Act.

Figure 1.8 Risk management.

It is certain that not all project risks can be predicted or accounted for, but it is also true that not looking for the risks means nothing can be foreseeable.

Based on the project's phase and criticality, the risk register (an example of risk register is shown in Figure 1.13) should be reviewed regularly—in some cases on a daily basis—to remove roadblocks.

1.3 Organizational Influences Based on the culture, size, age, and level of regulation or technology, an organization will have its own personality, which will likely influence how its projects will be managed. The organization will have various project managers with unique personalities, and its decisionmaking, together with its tolerance to risk, will influence the project operating environment. The project manager and the project team must adapt to these organizational norms and modus operandi to successfully lead and execute the project. Another significant factor impacting project execution is the structure of the organization, with the level of challenges growing with size and number of geographical locations involved.

1.3.1 Matrix vs. Line Organization

Based on the organization's structure and culture, the project manager's responsibility and expectation can vary significantly. This factor also drives the efficiency in executing the project within the organization. Three basic types of organization structure are worth mentioning because of the influence they might have on how projects are internally developed: Functionally Structured Matrix (a range of possibilities in this category) Project Structured Functional organizations are the type of organization often referred to as “stove pipe.” These structures are based upon the expertise areas of the organization. Group managers are the project managers for the represented discipline (for example, the testing manager), and they drive to execute the project activities within that discipline. This is one of the easiest ways to get the job done. Every one of the resources is under one manager, who has a direct impact on their performance review. It is also an efficient decision-making process. This structure can work very well if the projects are research related or require strong technical impetus, and are few in number. The technical expertise helps to drive the decisions and can expedite the early phases of the project. Matrix models of the organization are shown in Figure 1.9. This configuration has various degrees, ranging from the weak matrix to the strong matrix. In the weak matrix, the line manager will control much of the project through interfaces with the project manager and the line organization. The line manager controls the resources as well as tactics and, perhaps, even defines the strategy. In all matrix organizations, project managers share the same responsibilities with the line organization. Human resources report to the line managers but perform work for the project managers. The strong matrix organization looks something like Figure 1.9, with multiple group managers administering the resources and being responsible for talent management and resource allocation.

Figure 1.9 Strong matrix organization in its simplest form.

The resource managers also work for the project manager, and they are responsible for delivering results to the project. The simple group of resource managers working for the project manager is shown in Figure 1.10. In the real world, this could be very complicated with multiple stakeholders such as customers, multiple engineering groups, and multiple process owners all interacting concurrently.

Figure 1.10 Project manager managing resources for project delivery.

The balanced matrix has the project team members report to both the project manager and the functional manager. Thus, the balanced matrix requires considerable communication between the project manager and the functional managers, and the proper identification of the areas of priority for each.

In a matrix organization, the project manager should be prepared to extensively negotiate for resources, the right expertise, and acceptance of strategy.

The balanced matrix is the most difficult to work due to the shared responsibility between line and project managers. Contentious leading and directing can negatively affect the timely achievement of project objectives as well as employee morale. Competing managers and deliveries can be resolved by establishing a good responsibility split for the project, including the functional manager and the project manager. Well defined and established roles and responsibilities along with a clear decision-making process can help reduce confusion for the project team. In the strong matrix, the line manager makes sure the staff has appropriate competencies and adheres to the department's process to deliver the product. The project manager has more responsibility and a higher set of expectations, and can demand for allocation of the resources. The final form of organizational structure is the project-driven organization. In this type of organization structure, the project manager and project team are within the same group. This group has all the competencies required for executing the project. For example, development of concepts, testing, and evaluation as well as final launch of the product is done by the same group of people. All skills required to develop the product are led by the project manager. This streamlines the logistics and communication channels, and it is a significant component to the agile way of working. The team, in this format, can achieve good results in a shorter time. Yet, there could be a downside of limited specialization knowledge or synergies. For example, consider a new challenge the team has never encountered together or a time when the project requires more of one type of resource such as testing. The structure of the organization defines the operating area and expectation upon the project manager, the general management, and the workforce of the organization. It also provides clues to risks and conflicts that can be expected. Therefore, it is pertinent to know where the organization and any supplying organization fit on this continuum. Consider two partners with different organizational structures interacting. A manager from supplier X (project-driven organization) promises to meet the schedule for supplier Y (balanced-matrix organization). Both these organizations will have to negotiate the use of human resources in different ways to meet the common goal. Additionally, the level of responsibility for meeting the date in the balanced-matrix organization has more risks associated with the complete delivery, as the line management has significant impact.

1.3.2 Organization Size and Footprint The size of a project-driven organization will also be closely connected with the company's footprint. Both will affect its communications channels and methods. The footprint of the

company is defined here as the physical distribution of the organization, including its supply chain. For a large distributed automotive company, some of the project team members will be colocated (in one location), and a few may be distributed across the globe. Team members can also be part of development for a multitude of vehicle platforms around the world, requiring input from different market segments. The situation gets more serious as they deal with Tier 1 and Tier 2 suppliers. This can further add distance and communication hurdles due to language barriers or different time zones. With increasing complexity of a given project, the probability of its success decreases. Various tools are available to keep the team connected and to help address communication issues.

A communication protocol should be established at the beginning of each project. The protocol should have a process for communicating within the team and outside the team, and an escalation process if so required.

1.3.3 Stakeholder and Sponsor Management A fundamental part of stakeholder and sponsor management is to always remind them of the current scope of the project, using effective ways to communicate with these two groups. A common and agreed-upon understanding with sponsors through the project life cycle is significant for the project's success. Internal exchange within the teams as well as with sponsors should be handled carefully, especially when the project is underperforming and the project manager must deliver bad news. Details around the communication plan are described later in the chapter. It could be argued that one of the reasons for which agile approaches are so successful, besides being adaptable, is the constant and close connection between the development team and the product sponsor, who represents the customer perspective and their input. There is no reason why this contrivance must be restricted to an agile methodology. Lack of connection with the sponsor can be the main cause of failures for the project. The project manager should establish the roles and responsibilities of the project prior to the kick-off meeting, as part of best practices. In some companies, project initiation is only accepted after a clear understanding is defined for roles and responsibilities, and resources are assigned and secured.

1.3.4 Roles and Responsibility of Stakeholders and Sponsors

At the high level, the project team should have an organization chart showing the resources from different areas of the company. Figure 1.11 shows a simple structure that can vary in degree based on the size of the organization and the nature of the project. Each of the project managers reporting to the project management office can have their own sub-teams. Crossfunctionality and interdependencies are a complex component for successful execution of the tasks.

Figure 1.11 Project organization.

If the purchasing team suggests a technical solution, the project may become stalled due to differences of perspective or priority between the technical team and the purchasing team. Technical solutions should be driven by engineers in a crossfunctional development environment and accepted by the project team.

In the case of the mega-scale project with multiple locations responsible for development, testing, and market requirements, a compounding impact occurs. Each interaction associated with the global footprint, in addition to working with different cultures, adds a level of risk to the project. The availability of the appropriate skill set in the project team is fundamental for its success. It includes both acquiring suitable talent and defining the roles for each stakeholder. It certainly is a waste of time and resources to watch the project stall while trying to figure out the responsible party for an important decision. This is a problem that can only get

amplified by responsibilities and expertise being spread across the world, as is the case with globally distributed organizations. Roles and responsibilities can be broken down further to the work package level, as described in Figure 1.12. The illustration also shows the scope of decision-making by different groups or individuals. For example, in the design hardware objective, the project manager is a participant but is not accountable.

Figure 1.12 Roles and responsibility matrix for the project.

Establishing such a matrix helps the project team avoid unnecessary confusion in the decisionmaking process and improves communication.

1.3.5 Role of Executives Phase reviews with executives are beneficial in providing support and making decisions at the

end of each phase. In this way, executives of the company play a significant part in the gate (phase) reviews. They decide whether the project and its associated risks are under sufficient control to proceed with the next level of investment and activities. In addition, executives may fill a mentor role for the project managers to help determine the right direction and mediate conflicts. Project managers should use the governing body in an efficient way to escalate quickly to resolve the conflicts and roadblocks. In the case of conflicts between different stakeholders, the decisions are made by reviewing the impact to the project in terms of delivery, cost, or quality.

If the project continuously gets reviewed by the executive body due to high risk, and over time the risk increases, an introspection of the role of the governing body is needed. Delaying the decision until no option remains is not a successful strategy.

For example, a technical solution might require a change in the manufacturing plant, which could drive costs up. The project manager should provide all the options to the governing body with the overall impact to the project. The team should also make the best recommendation, and the executive group should provide either complete endorsement for the acceptance of the cost increase, or support the project manager with alternative solutions. One area to exercise care pertains to reduction in scope. Much can be said about scope creep and golden plating, but when the project gets hit by an increase in cost, it is important to recognize that a reduction of scope can help lower the project cost.

1.4 Communication A good project manager establishes communication with all stakeholders and provides an update mechanism to keep them involved and aware of project progress. With good information flow inside and outside the project team, the project manager improves the workflow and support for the project team's objectives. Communication challenges in the automotive industry become complicated with global participation. Time zone differences as well as cultural differences, including language barriers, can make understanding each other difficult. The goal of the project communication protocol (PCP) should be to establish the communication structure for regular team meetings, problem resolution, design reviews, and escalation process. With a recurring and constant engagement, the technical roadblocks either can be prevented or corrected early. Good cross-functional communication in the project management team and with the line organization helps ensure a good understanding of technical and commercial challenges. This common understanding helps to prevent the severity of the issue from becoming worse with time. The team should engage inside and outside the project management group to provide quick resolution to issues, severe or not.

The communications plan articulates the requirements for the project with the focus on Who, What, When, Where, How, and Why. With a good communication strategy, and roles and responsibilities well defined, it should be very clear who is in charge of which item and how it gets addressed in an efficient manner.

“It was impossible to get a conversation going, everybody was talking too much.” Yogi Berra. While it is important that everyone express their opinion, the project manager should play an important role in eliminating noise, in order to obtain a clear message that supports the action plan.

Communications plans are important when an issue needs escalation to a higher level of management. This is also true in cases of major failures, conflicts, and disagreements. At any rate, whether formally or informally, the project team should consider how information disseminates among participants. The team specifies activities for creating and reporting decision logs. The project manager chooses procedures for creating, storing and accessing, archiving, and presenting information. These acts define what information the team needs, and the format required by the project participants, including stakeholders. The typical contents of the communications plan are: Information Distribution: Distribution defines “Who” should be on the list of information sharing. This list should include the project team members and the critical stakeholders. Information Description: Description defines “What” and “How” the information is shared: email, text, excel sheet, graphics, documents, voice mails, and videos. Information Schedule: Schedule defines “When” or “How often” the information is updated and distributed. The frequency can vary based on criticality. Progress Reporting: Status of the project is defined with progress report based on the phase of the project. Communications Plan Revision: The plan should be documented if revised. This should also be agreed within the project team. Depending upon the organization, this may fall under configuration management control. The communications plan also lists the types of reports and documentation that the team will be using, such as:

Project Scorecard / Vitality Report (specific metrics of interest): The scorecard of the project should be simple and concise to follow. It should capture hard points, achievements, activities planned, and support needed, if any. Financial and Earned Value Reporting: Project cost metrics should articulate the details of product cost and project cost. These metrics are either published by month to monitor project expense or before going to the governing body. Risk Register: Project risk should be recorded in a register through the project life cycle. Based on severity and probability, the risk should be escalated and adjudicated. An example of the risk register is shown in Figure 1.13. In short, it should have one owner and a plan with clear direction on how to close the risk by the set date. Support/ Recommendation/Escalation: In the event of project deadlocks, or technical or commercial challenges, the project team should work through options and present to the governing body for proper support or recommendation.

Figure 1.13 Example of risk register.

1.5 Contract Types The organization's procurement area is responsible for contract application and administration. The contract type has implications on the project risks. Therefore, it is incumbent upon the project manager to be part of these contractual discussions. Each contract type has associated challenges and, therefore, certain specific failure potentials that will need to be identified and symptoms that allow predicting the failure.

In case of a project getting scrapped internally, the project manager must understand how procurement handles the sunk cost for any expenses already incurred.

Depending on the contract type, the risk is weighted in favor of either the contractor or the customer. At one most extreme end, the type of contract is a Fixed Price one, and losses could be big. In this type of contract, the scope is identified, and the supplier assumes all risks with late delivery and cost overruns. The supplier is able to walk away with whatever profit there may be as well. This type of contract requires strong scope and change management controls to mitigate the risks. The second type is the Cost contract. In this contract type, the risk is on the customer. However, cost contract type provides the most flexibility. The supplier will bill the customer for all activities of the project. Risks are associated with the type of contract under which the project is working. The specific risks depend upon whether the project manager is the supplying organization or the customer organization. This also applies to the outsourced work.

References 1-1. Plunkett Research, Ltd. https://www.plunkettresearch.com/industries/automobiles-trucksmarket-research/ Accessed March 25, 2014. 1-2. Toyota Motor Corporation. http://www.toyotaglobal.com/showroom/vehicle_heritage/corolla/. Accessed March 27, 2016. 1-3. “The Standish Group Report, Chaos,” The Standish Group, http://www.projectsmart.co.uk/docs/chaos-report.pdf. 1995. Accessed February 2016. 1-4. WBS Planner. 2007-2015. http://www.wbsplanner.com/home/. Accessed March 2016. 1-5. “Attrition in India to top world charts in 2013; one in four employees to change jobs,” The Economic Times, http://articles.economictimes.indiatimes.com/2013-0607/news/39815456_1_three-employees-indian-employees-attrition. Accessed October 2014. 1-6. Thomke, Stefan, and Reinertsen, Donald, “Six Myths of Product Development,” HBR Magazine, May 2012.

Project Management for Automotive Engineers: A Field Guide Chapter 2: Business Case and Product Development Models Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 2 Business Case and Product Development Models

“Estimating is what you do when you don't know.” —Sherman Kent

2.1 Business Justification Organizations create projects to improve cash flow, increase the company's share value, and, eventually, boost their profitability. In some instances, a project is undertaken to enter new market segments, meet legal requirements, or fix major quality issues. In all cases, a complete business justification and profitability calculation should be performed. For entry into a new market segment, the profitability calculation should remain positive, with significant return on investment demonstrated. In the case of legal projects, the government mandates the change, and the automotive industry must comply with the regulations. Profitability in such projects is not a big factor, but the company should still try to improve the overall cost targets to minimize the cost impact to the bottom line. If there is a field quality issue, the company may undertake a project to address customer complaints, thereby reducing the warranty cost and preventing market erosion. The project manager becomes a gatekeeper by evoking assumptions and establishing measurements for profitability calculations for the project. This calculation helps management to determine the project viability throughout the project life cycle. The assessment is made by reviewing the cost for the project, the volumes that the project affects, and the selling price.

The business justification using a mathematical formula should be closely monitored for correct assumptions. Incorrect assumptions will lead to an incorrect business case.

The project manager should be aware of two financial criteria: the accuracy of the input data and the capability of the employed model or calculation to predict. Figure 2.1 shows that if all or key assumptions are incorrect, the probability that the project profitability calculation will produce poor results is high. Similarly, with perfect assumptions but an incorrect calculation, the profitability calculation of the project should not be trusted. As described in Figure 2.1, the results in both cases are errant, and any subsequent business decision is fraught with risk. From

the perspective of a project manager, the probability of success in such projects is low and is largely due to luck.

Figure 2.1 Model accuracy for business justification.

Some of the major financial definitions used in business justification analysis are discussed in the following sections.

2.1.1 Return on Investment One of the simplest investment measurements, return on investment (ROI) is the ratio of the income generated from the product to the cost to undertake the project:

The project team should be careful with assumptions in the early phases, because each of them can impact the project cost. It is important to take time to determine the validity of the assumptions. The cost of investment can go up exponentially if technical failures occur in the late phases of the project.

2.1.2 Cash Flow Impact

Undertaking a project has an impact on the organization's cash flow. Cash flow is the amount of money coming into and going out of the business. The money spent on the company's project portfolio (all the projects in the organization at a given time) is considered expenditures. These projects will periodically be launched and bring cash back into the company (if executed well). At the executive level, cash flow is monitored as project portfolio or research and development expense. Based on the state of the project, the economy at a given time, the targeted market segment, and ongoing financial commitments of the organization, the decision to add or scrap projects is made. For project management, discounted cash flow is a better method of valuing a project with the concepts of the time value of money. In many cases, the organization has pre-existing templates based on certain documented assumptions that the project manager should be able to use to make those calculations.

2.1.3 Payback Period Payback period is the time it takes to recover the investment. For example, if the project costs $500,000.00 with a volume of 50,000 units annually and a profit margin of $20.00, expect to pay off the investment in six months. In equation form, it would be 50,000 units × $20.00 profit = $1,000,000.00 profit. With a uniform distribution of sales over the course of a year, the $500,000 will be paid back in six months, as indicated by the following equation.



Check with the supplier on the end-of-life dates for electronics components before using the data as input to the model. With limited life of electronics components, the project justification may not stand up to scrutiny for the long-term project.

2.1.4 Internal Rate of Return Internal rate of return (IRR) evaluation allows the assessment of any opportunity costs associated with accepting a project. IRR is the interest rate that makes the net present value (NPV) equal to zero. NPV is the difference between cash inflow and cash outflow and is a project profitability calculation. With this method, a comparison is done between the competing projects to evaluate which is the most profitable. This financial evaluation method does not consider the risks that may be associated with the project, which may influence the initial investment value. The present value is determined by the following equation:

where PV = present value, FV = future value, R = rate of interest, and n= number of years.

2.1.5 Legal Demands The automotive industry is a regulated industry, and there are always legal projects in the company's portfolio that are considered priority. It is essential to comply with these legal demands to continue as a viable business. The introduction date for the project is mandated, and the complexity of the project can vary from simple tweaking of monitors to complete chassis or engine redesign. The detailed scope is not entirely clear at the start of the project. The regulating organization may have to work through the specifics of the legal requirements even while the project is in the process of being executed. For successful execution of legal projects, it is important to define the project strategy to minimize risks. At the start of the project, as the scope is evoked and documented, the project has inherent risks due to organization, process, parallel project priority, etc. The goal should be to fix the scope, with aligned strategy and tactics, to reduce risks as much as possible. Consider the example below: Problem statement: A regulatory demand is established for an upcoming model year. The objective can be achieved in two ways. Option 1 is to develop a new subsystem, with minimal change to the vehicle. Option 2 matches the company's strategy to maintain fewer platform tracks, but it requires many changes to the various subsystems of the vehicle. Very clearly, option 1 is low risk, low cost, as well as guaranteeing time to market with less development and with low complexity. However, if the company chooses option 2, the risk in the project multiplies due to the added complexity of the subsystem development and the interaction among multiple new aspects, thereby increasing the probability of failure. Solution: A decision matrix such as Pugh analysis (Figure 2.2) can be used to evaluate design solutions against the desired criterion. Decision matrices come in two forms: weighted or not weighted. The Pugh matrix illustrated in Figure 2.2 is a weighted example. The team evaluates the proposed designs against the project or product objectives. To be effective, a common understanding by the team of the key attributes is required.

Figure 2.2 Example of Pugh matrix.

The tool can be used to assist in escalating a concern and to outline the issues for resolution. In the early phase of the project, the project manager should try to influence the organization to move to option 1. Sometimes, the decisions are made outside the project manager's realm and with little information. At that point, the project manager should map out all the technical and commercial risks to the management for choosing option 2.

2.1.6 Shareholder - New Market and Strategic Projects Some projects are termed as “strategic” to capture new market segments, and they may not demonstrate profitability in the short term. Up-front investment cost can be significant, and volumes are typically low initially. A degree of uncertainty is present for these new markets. In such situations, the project manager has a difficult job to minimize the project cost and identify and record previously unknown risks. There is a fine balance in fulfilling the strategic vision of growth and minimizing research and development costs. The board of directors will normally require a link to the long-term profitability of the enterprise and need a solid rationale for an immediately unprofitable investment.

2.2 Project Life Cycle This section is a review of various models of how the project can be executed. These models are simple representations that enable a better understanding of how the workflow occurs from the beginning of the project to the final product. In general, they exhibit similar characteristics: initiation, planning, execution, and closure.

2.2.1 AIAG Standards

The Automotive Industry Action Group (AIAG) [2-1] defines the following areas of automotive interest: Quality system Quality system assessment (QSA) Measurement system assessment (MSA) Product part approval process (PPAP) Advanced product quality planning (APQP) Statistical process control (SPC) Failure mode and effects analysis (FMEA) Advanced product quality planning (APQP) defines the approach to automotive design and development of new products. The phases of the APQP are planning, product design and development, process design and development (manufacturing or service oriented), product and process validation, production and feedback assessment, and corrective action (all phases). APQP represents a useful approach for project and program management, and the process presents a rational approach to product and process development. The approach fundamentally applies to any services as well as product development equally. The phases described in Figure 2.3 are concept initiation, program approval, prototype, pilot, and launch. These phases can form the infrastructure of the complete project planning and execution.

Figure 2.3 Project phases (adapted from AIAG) [2-2].

2.2.2 Concept of Phases - Why Have Phases? Projects can be broken up by phases. At the end of the phase or stage, a gate review or audit, which provides the terminus for that stage, is conducted. Each of the project segments clarifies and refines the project output. This is often referred to as progressive elaboration. These segments reduce the risk to the organization by providing a map of the product development and growth for the project team. The result is a clear set of short-term and long-term deliverables associated with a specific phase. The gated approach helps to make the right decision of terminating the projects, if costs go so high as to preclude profitability, or if mounting product technical challenges make them potential market losers from the get go. This saves the organization from possible big investment resource losses, with no payback. By terminating the bad projects, companies can explore other opportunities of investments and ensure appropriate use of the resources. Specific deliveries are established for each gate at the start of the project. The deliveries must be discussed with the project team and agreed with all the stakeholders. The gate target approach lends structure to the project by defining deliveries expected for that particular phase. Each segment of the process leading up to a gate target will have cost, quality, and schedule goals built into it. Program managers will define the gate targets in terms of entrance and exit criteria, and record the results in a simple checklist. Where possible, the project manager defines the decision path for key gate targets before a project starts or well before a specific gate.

2.2.3 Lean Project Management (Agile) Agile is a lean approach to project management and has received considerable attention from a variety of industries. This approach strips away the clutter and focuses on the fundamentals of the product development and project by streamlining communications channels, and by obtaining the most out of those involved through the use of self-organizing and self-directing teams. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development, by Dantar P. Oosterwal, and The Toyota Way, by Jeffrey Liker, offer perspectives on lean principles for product development. The automotive industry has adapted too few of these agile processes into the line management and conventional project management, even without formal adoption of the agile project management practices exclusively. For example, a company can adopt the agile approach to communication for conventional projects by using the sprint-like approach for daily updates. Instead of establishing a large scope for each iteration, smaller increments with shorter time horizons can be defined. Agile project management is typically used in software or embedded product development, but

it does not have to be restricted to software development. Powerful techniques that are present in the Agile tool box, when used correctly, can produce exceptional results in both line management and conventional project management. More details can be found at the Agile website [2-3]. Some of the main topics addressed here are: empowerment, product backlog, sprint backlog, sprint, daily sprint meeting, burn down chart, and retrospective. Empowerment is a must for successful implementation of an agile methodology and, arguably, any modern business endeavor. An empowered team can make good and informed choices based on the team members' individual and collective experience and expertise. Empowerment puts the authority to impact the project outcomes in the hands of those who do the work. This happens in two ways: first, by encouraging the team members to take a significant role in the overall process. Second, by providing the employees with larger work areas for the teams to be co-located, and engaging them in decision making. No longer does the team member perform strictly as the executive or management dictates. Empowerment is required for employee engagement. Product backlog amounts to the scope of the project. The product backlog provides the team with the prioritized objective of the product sponsor. The product sponsor and the scrum master work to keep the product backlog in order. The scrum master has some similarities to the project manager in conventional projects, although the techniques are different. The scrum master is a servant leader. This will be covered further in future chapters. Sprint backlog is analogous of the work breakdown structure. The team decomposes the product backlog to produce the work content for the immediate sprint. The sprint backlog is the next level of detail or specific work details. It consists of the specific tasks required to meet the product backlog that will fit within the single sprint. Sprint is defined as the time in which the team will produce an iteration of the product. That duration is typically two or four weeks, but it can be any time-boxed period. In fact, we have used a six-week period for some projects. This period is fixed and is sometimes dictated by the organization. The daily sprint meeting is used for communicating the needs of the project during the sprint, and it is an opportunity for progress monitoring and adaptive planning based upon performance and discovered risks. Adjusting the pace and altering the sprint items are a few of the tactics employed to keep the project moving. The product sponsor often participates, and the scrum master facilitates the decision process. Through the use of the following three questions, the scrum master tracks the progress and evokes the risks associated with the project: What did you do yesterday? What are you doing today?

What are impediments to achieving the objective? The burn down chart helps to track the team's progress and is similar to earned value management. The chart keeps track of the time available compared to the estimated times to perform each sprint activity. This helps reduce the need for a complicated project schedule and equations. When the progress is slow, as shown in Figure 2.4 (on the left), the burn down chart alters from the ideal and predicts that the sprint may not achieve all planned objectives. As a response, lower-priority sprint items may be removed. Likewise, if performance is better (Figure 2.4 on the right) than planned, adding sprint content is an appropriate response.

Figure 2.4 Burn down chart for Agile methodology.

Retrospective is the critique of the actions at the end of the sprint, and it is similar to the post-phase project critique. The project team learns what went well and not well, and how to improve for the next sprint. The team is able to learn more frequently by reviewing the short bursts of work through the incremental progress to the project's objectives. The Agile methodology supports a constant review of the project performance on a recurring basis at a much shorter schedule and, thereby, improves the project continuously. Figure 2.5 shows the short version of the Agile Scrum Methodology. The product backlog is the demonstrated requirements of the product as the product owner sees it, often in the form of a use case. With the prioritized product backlog, the sprint backlog is created to fit with the sprint. The scrum master facilitates the execution and monitors the product backlog.

Figure 2.5 Agile Scrum Methodology.

2.3 Models of Development Development models help to visualize how activities are performed to meet the project objective. In general, all models have similar characteristics: scope, develop, test, and deploy. Sequence and the complexity of the project can dictate the model that is best suited for the project execution. A few of the models are described in the following sections.

2.3.1 Waterfall Model The waterfall model illustrates the product development process as sequential and cascading activities culminating in the final product. Each of these logical elements could impact one or more gates to ensure the objectives of that phase are met. One of the limitations of this model is the implied single pass of the development work. For example, the requirements phase captures the scope from all the stakeholders, and there is never revisiting of these requirements as the team learns more about the product. The five stages of the waterfall model are: requirements, design, implementation, verification, and maintenance.

2.3.2 V (or W) Model - Prototype Models

Another model for product development is through an illustration known as the V-cycle model development life cycle. The activities start at the upper left corner of the “V.” The model illustrates how the development starts from a customer input through systems level, and it progresses through increasingly detailed development phases until an iteration of the product is delivered, which ultimately results in a vehicle. This customer input drives concept selection and documentation. Once the team defines the concept, the system requirements are generated. The vehicle-level system requirements are then broken down to the next level of details as component(s) requirements. For example, the top-level system is defined: the vehicle should have a collision avoidance system with active braking. Systems-level specifications will define how this total system will perform. Antilock brake system updates will be required for the system to work as defined in the systems specification. These updates will be included in the antilock brake specification documents. With the component-level documentation complete, the design implementation work starts. The output of each block is the input to the next one. The strength of this model, as shown in Figure 2.6, lies in the juxtaposition of the development work (left side of the V) with the verification or testing work (right side of the V) necessary to secure the quality of the product. Each step has related verification to ensure that the requirements are satisfied. For example, design is verified by developmental tests. During the design stage, performance and functional theories and hypotheses can be tested and verified to either substantiate or refute an expected quality level, which includes performance. Virtual designs can be used, following the same approach.

Figure 2.6 V-cycle model [2-4].

As with all models, limitations are present here as well. Viewing the V-cycle model, strictly, can be interpreted as a one-time loop for design, develop, and test. However, it does not reflect the iterative nature of the development process. With some imagination, it is possible to extend the V-cycle graphic to a W-cycle graphic or even more cycles to account for the additional phases for a good-quality product.

2.3.3 Toyota Model (or Set Based)

Set-based development, or the Toyota Model, is an incremental and iterative approach. Using this method, the key attributes of the product are identified either by testing or by reviewing the specification or simulation. With these key characteristics, the tradeoff curves that apply to the product are developed using a variety of concepts. Once these curves are established, the detailed specification of the product can be developed. Rather than premature selection of a single concept, investments are made in exploring a number of promising concepts. From this exploration, a variety of possible solutions can be reviewed. In fact, rather than specific concepts, the process uncovers the key variables that will lead to a successful product and project.

In the example of developing a fuel efficient vehicle, fuel efficiency should be the key attribute and can be achieved by changing various parameters on the vehicle. From engine specification to cab changes, the project team can explore the combinations and permutations assessing investment cost, complexity, and then base the concept selection by weighing the opportunities against the risks.

2.4 Mix the Two: Business Case and Phases As the project gets kicked off and development work starts, the gated process keeps the project on track with monitoring of the cost, projected profitability, and scope and features that are being delivered. The project manager will often see the profitability erode as development and product costs increase. With a profitability trend consistently negative, the project manager should engage and start reviewing the assumptions made in the project, as well as the input provided by the line organization. In Figure 2.7, projects 1, 2, 3, and 4 start with a very high profitability calculation result and, then, over time and project execution, the profitability declines. We will expect the profitability calculation to fluctuate over the course of the project execution as we learn more about the product and the marketplace. However, if the drop is significant, as seen in projects 1, 2, and 3, the likelihood is high that an incorrect hypothesis was made about the business justification, and possibly errant assumptions were established by the project team, leading to incorrect estimates. These projects then get a reality check during development phases, when there is already a significant amount of sunk cost involved. If such a trend is observed in the organization, the project management office should be alerted immediately and strong actions put in place to understand and address the root cause.

Figure 2.7 Profitability over the different phases of the project.

These calculations and trends should also be monitored after the project is introduced to reflect on the magnitude of impact the project had on market share or company profitability. Even after big investments are made in the project portfolio, If the market share remains unchanged even after huge investments in the project portfolio, we can conclude that there is a disconnection between the strategic vision and the program portfolio of the company.

References 2-1. Automotive Industry Action Group, Advanced Product Quality Planning and Control Plan (APQP), Southfield, MI, AIAG 1995, p. 5. 2-2. Reprinted from Advanced Product Quality Planning (APQP), p. 6, 2nd Edition, 2008 Manual with permission of FCA US LLC, Ford and GM Supplier Quality Requirements Task Force. 2-3. Manifesto for Agile Software Development, www.agilemanifesto.org. Accessed March 2016. 2-4. Pries, Kim H., and Quigley, Jon M., © 2008 Taylor & Francis Group, LLC. Reprinted with permission. This figure originally appeared in Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality, p. 299, by Kim H. Pries and Jon M. Quigley.

Project Management for Automotive Engineers: A Field Guide Chapter 3: Vehicle Subsystem and Concept Generation Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 3 Vehicle Subsystem and Concept Generation

“When it is obvious that the goals cannot be reached, don't adjust the goals, adjust the action steps.” —Confucius

3.1 Vehicle Concept Development and Selection Project risk exposure begins as soon as the project gets started. With each decision or strategy or change, the project could be at greater or reduced risk. The project management function is there to identify risks, ensuring that risks are mitigated and cost is controlled in such a way that the project portfolio remains profitable. The end result should be a final product that delights the customers. The beginning of the project is the best opportunity to set the boundaries and the course for success, and to assess the project risk exposure. Sorting out and finding good concepts are the basics of profitable project management. This helps reduce risk and improves the probability of successful product development. The project manager should help the team hone in on concepts by accurately assessing the weight of customer requirements. Various tools are available to capture project requirements to develop, for instance, an outstanding platform.

3.1.1 Voice of Customer Voice of customer (VOC) is the most critical input for the product development phase. Customer requirements should be defined and quantified in a manner that can be measured over the project life cycle. These requirements must also be prioritized. In the course of exploring the design solution, trade-offs based on these requirements will likely be required. Specifically, the customer requirements may at times present a contradiction in the solution. Suppose, for example, the customer wants a lightweight, hand-held, battery-operated device to be available in a certain car model. Also suppose that the runtime that the customer expects for this device to work would require the battery to be the size of a car battery instead. In this case, it is important to find a way to achieve a reasonable compromise. Another equally important reason for prioritizing the requirements is to ensure that the money spent on the project is focused upon those requirements most important for the customer. Later

in the project, if the money is running low, the team will have delivered those most important or most desired features. This is one of the core concepts of the Agile methodologies, and although it is not often practiced, conventional project management as well. Most companies use either market surveys or known market needs to define the customer requirements. It is vital to differentiate between the core requirements vs. the delighters. These criteria will later define the project profile and help prioritize project activities. The VOC also helps to set up the measurements for the output of the project in terms of customer satisfaction and customer loyalty. Quantified requirements help to bridge the gap between the input and output of the project. Additionally, this allows for integration of the various channels of communication between company and customer. With this approach, a consistent view is established of the requirements impacting project team members and sponsors, aftermarket services, customer satisfaction, insurance groups, and market analysts. More importantly, where a consistent view does not yet exist, the team can take active measures to ensure convergence. The following example discusses the issue of definition related to the concept of a smooth drive. In the automotive industry, a “smooth drive” is a very common term, but the understanding varies from customer to customer. The customer driving in rough or steeply contoured terrain may have a different idea and perception than a customer driving in normal weather conditions on a common highway. Again, tangibly quantifying the definition of “smooth drive” is essential for the solution to be developed. Is it the rate of change in acceleration, or is it a change in the variable transmission logic? For some customers, it might just mean achieving a better fuel economy by enhancing braking techniques. Thus, we see that one requirement can lead to multiple interpretations and solutions. It is up to the project manager to ensure that as clear a picture as possible of the objectives and goals of the project is established. Ambiguity will not make the decision process easier, nor will it bring the team's focus to bear on the project objectives.

3.1.2 Competitive Intelligence Competitive intelligence is another tool that helps drive the product strategy and project management portfolio. It is an important component for the company to align the program portfolio (comprised of multiple projects that are executed with synergies) to the company's vision. The technological roadmap defined by the research team should also define the limitation of the product scope. Marketing and customers often have a “want it all” attitude, and the role of a good engineering team is to put the right boundaries for the product in the project life cycle. If the demand is for a high-end product, the project team should explore ideas of a two-step approach. In the first phase, a base product with certain features could be launched; from there, customer feedback could be obtained to help drive the next phase of the product development cycle. In this way, the company can develop the revenue stream more

quickly. Even more importantly, the customer feedback provides more realistic product growth and adaptation mechanisms. The scope of the project should tie to the main strategy and vision of the company. Strategic planning confirms the future needs of the organization, and project management is an excellent tool to plan for the unknown. In other words, our project activities are there to ensure that the company is able to compete at some future date. The organizational uncertainty about the future of the product line or service is addressed via the projects that are approved, undertaken, and successfully delivered. The scope of the project should be part of the overall product portfolio, and project managers should categorize the incoming projects as Strategic, Legal, Quality Improvement Initiative, and Customer Requirements, among other possible strategic categories. The approach to each of these projects will be slightly different in terms of resource prioritization, fund allocation, and risk mitigation. From strategy to execution, this is the journey of project management; each decision has the possibility to affect the profits of the company. A good understanding of the interdependency with other ongoing projects is required to reduce risk and align the projects with the company's overall profitability goals.

3.1.3 Project Coordination or Program Management Figure 3.1 depicts the great complexity of the organization via the interconnected product projects and coordinated deliveries throughout the supply chain. Projects can be executed in the same company or by various companies with multiple stakeholders all around the globe. Coordination can become more difficult if the requirements and execution are done in different parts of world. To meet legal requirements in the Australian market (Project E), for instance, successful execution of multiple other projects (A, B, and D), either on the same continent or in different parts of world or involving different suppliers, is required. Each one will add multiple risks to the main project (Project E). Experience counsels to closely review the objectives of Projects A, B, and D, which should have a clear definition and priority for the legal requirements as in Project E. It is also crucial at the initial stages to review other similar projects or historical data within or outside the company to define realistic targets. This could be done as a white book exercise by reviewing the documents with all stakeholders. The white book exercise is also known as lessons learned. The exercise has a specific method, with interviews and data being recorded in a journal for the project. These critiquing points are typically gathered at the end of each project phase (or gate).

Figure 3.1 Program management or multiple project coordination.

3.2 Requirements, Specifications, and Drawings Experience suggests that many projects fail due to lack of requirement control, insufficient time to map the scope, and not including input from sponsors or customers. Late input to the scope, requirements, and requirement traceability can cause chaos within the project organization, and also with outside suppliers and end customers. Insufficient time spent on the gathering of requirements can significantly increase the probability of failure. When little investigation is done on the details of an adaptation project due to unclear understanding of how to implement the “standard product,” ambiguity in the requirements phase is created.

A business justification made by using a standard, off-the-shelf component can quickly escalate cost and time to delivery after the details of required product changes to the adapted solution are established.

Understanding the market needs is part of determining the scope. Ultimately, the market demand is documented in the requirements specification. The project sponsors should be part of the requirement specification review and agree to the deliverables. The requirement elicitation and documentation portion will freeze before the development begins. In the case of moving targets, little time is spent on defining the product, and this will likely cause project failures in

the future. Requirements traceability is coupled arm-in-arm with configuration management. The inability to trace the requirements back to the scope of the project means the contract closure activity will be tenuous, and perhaps contentious. With clear top-level scope or objective of the project defined, the project management team should break down the scope in terms of clear requirements for each stakeholder with defined targets. Some organizations employ a systems engineering approach, and a system analyst is assigned to the project and is often responsible for this activity. The project management team should then provide a methodical examination before reaching the final agreement. In Figure 3.2, a short synopsis of the process is shown. This demonstrates how the customer requirement is broken into specific objectives, deliveries, and delivery contents or deliverables by the project team. The sum of these pieces defines the product attributes.

Figure 3.2 Process for defining product attributes based on customer requirement.

For example, product development engineers should agree with the aftermarket team on the location and ease of serviceability, while manufacturing will have different requirements for ease of installation or material handling. Subjective views should be avoided in all stages of the project life cycle. Consider a case of LED lamp installation in the dashboard of the car. The interpretation of the brightness of the LED is subject to the customer's perception. How bright is too bright? Is the brightness the same in foggy conditions or rainy conditions? To understand the real illumination need will require vetting feedback from a variety of customers. Securing the requirements early on in the project will help reduce the development and verification loops. In this example, the LED brightness should be quantified by lumens and color by wavelength. Experience indicates a well-articulated requirement specification is a significant contributor to the project success. One of the easiest approaches includes developing a requirement matrix with specific deliverables, weights, responsibilities, status, and clear corresponding measurements. The specification should at least document core features, interfaces impacted, and performance requirements. With a complete analysis, the project team should be able to understand and assess the potential threats to the desired outcomes with the added technical and commercial challenges. At this requirements stage, the project manager has the maximum leverage and alternatives to present to stakeholders. In some instances, this presentation of cost, duration, and risk could result in a radical change in the project scope. If that is the case, the same exercise should be repeated with the result of a complete agreement with stakeholders on revised scope, cost, and time. The change control process can be used to formalize stakeholder agreement from the baseline.

With the clear requirement specification, there is a possibility to find gaps between the market needs and project delivery. The exercise should be done with all stakeholders to maintain the course or to terminate the project if the profitability or other value is expected to be low.

Figure 3.3 illustrates an example of the requirement specification. In the simplest version, it should record specific goals and the responsible stakeholder, priority in the project (must have vs. nice to have), interdependency with other requirements, clear measurement techniques, and status. In the following chart, the various status conditions can include: IP - In Process Open Closed

Figure 3.3 Example of basic requirement specification.

One significant aspect of the requirement specification is that it forces the entire project management team to accept and agree to the project objectives by removing any misinterpretation of scope and their quantified deliverables. It also serves the purpose of maintaining the primary control over the definition of the product. Definition of soft requirements could be subjective, such as the definition of white light, which can be perceived differently depending on the individual. Soft requirements should be captured in the requirement specification document with clear goals and interdependencies. Once it is established, the requirement specification document should be controlled and only changed after an agreement is made between the team and governing body. This is part of the configuration and change management process of the project. The next step is to add value to the requirement specification by developing functional documents and technical documentation for the product. Subject matter experts (SMEs) should

set or, in certain cases, reshape the product by placing additional details around the requirements. Consider the scope of the project to build a red sports car. Requirements specification defines how red, what shape, and how fast this car should be. Functional documents serve as detailed drawings defining the specifics of acceleration, handling, driver comfort, and most importantly, the definition of red itself. Subject matter experts work to exploit the opportunities of innovation and historical information and design reuse, thus reducing the development cycle and risks associated with new projects. It might not be obvious, but the red color of the sports car may be as important as its ability to accelerate quickly. The automotive world has various areas of development, from changing the roof surface area or angle (slope) for fuel economy, to multilayer electronics and embedded software, all of which can benefit from the use of the model based requirement (MBR). However, MBR works especially well for electronics and software (e.g., helping to understand and record the requirements, reusability of software, and interdependency between different components). MBR is also effective with embedded hardware changes and electronic system development. In the structural or mechanical world, finite element analysis (FEA) provides opportunities to learn about the design without the heavy investment in tooling. Essentially, finite element analysis is critical for cost-effective change in the body in white. Before the functional documents are set for the product development, the project manager should ensure that proper design reviews are conducted, as discussed in section 3.6.

3.3 Requirements and Change Management The product requirements provide the product baseline, and project planning is streamlined on delivering these requirements. In a phased development process, product features are highlighted, and the team works in incremental iterations to deliver the final product. This staged delivery provides additional insight into the product—new knowledge that necessitates changes to the original requirements. The required changes must be managed to secure the design integrity. This is true for system development, where a change to one component may have implications on other subsystems and, as a consequence, affect the performance of the overall vehicle. Any disconnect between customer requirements, scope definition, and product development could be catastrophic for the project delivery. The classic example is described in Figure 3.4, where all the time and effort is spent on the development of a product that the customer does not need or want. Change is inevitable in the project life cycle, and deviation could come from new commercial or technical risks. Change management in the project life cycle is vital to its success. The scope of the project should not be changed arbitrarily, but as the project progresses; alterations

from the original scope are highly probable. Changes should not be made via email or verbal communication. Verbal communication is difficult to consistently propagate throughout the project team and, therefore, to ensure that each team member understands the details of the change similarly. If any change or deviation is required or requested, the project team should evaluate the risks associated with the change in scope. Also, the project's scope document should be changed prior to the changes made during the development phase.

Figure 3.4 Example showing the gap in customer needs vs. translation of product attributes by various stakeholders.

If the impact of changes on the entire project is not understood, then the triple constraint image becomes distorted (Figure 3.5) or does not even remain an equilateral triangle. The project sponsor often expects that any addition to the scope will have no consequence on the costs and time to deliver. That is not necessarily the case. In the worst case, the project sponsor may even expect the costs to decrease. Figure 3.5 depicts the distorted triangle with changes in scope.

Figure 3.5 Triple constraint impact with change in scope.

Clear understanding of implication of change is needed before commitment to the change and start of the execution. For the legal projects, particularly, as a project manager, one should be very critical of cost-saving ideas and late-design change requests. In every case, it is crucial to be aware of the dependencies within and outside the project. In the previous example, a change in body-in-white project D should be agreed to by projects A, B, and E. At the high level, every effort should be made to reduce the project risk as the time progresses and as the production date approaches.

With change in scope, do not forget to revise the business case. Does the new scope pass the litmus test? If not, should the project be terminated? Check for the dependencies on other possible costs, cost overruns, and additional risks.

Figure 3.6 describes the phases of the project in the X direction (you can also interpret it as the project life cycle), and the overall risk (area of the triangle).

Figure 3.6 Risk probability and impact over project life cycle [3-1].

Risk should decrease as activities are completed successfully. In the image of the solid triangle, the probability of incurring risk is high in the beginning and reduces due to the successful completion of activities. The risk envelope indicated by the dotted line shows that, as time progresses, fewer options for response are available; thus, the severity of impact that the risk has on the project increases. In addition, fewer mitigation options are available, and those available will likely be costly. A good example in the automotive world relates to tooling, which gets kicked off after the design intent solution is finalized. Yet, after the first prototype is received, designers might not like certain aspects of the product. If the project calls for changes in tooling, additional money is needed to fix the problem or address a new design request. However, tooling is often expensive and requires a long lead time.

3.4 Requirements Traceability Plan The project team can get into a chaotic state during the product development phase if any deviation in the scope occurs. The team should agree upon a procedure for traceability of the requirements through the project life cycle. Change in torque curves, for instance, could impact the performance of the vehicle. The team should analyze the system impact, the testing implications, and the acceptability of the overall performance of the vehicle by customers. Similarly, a change in instrument panel dimension must be agreed upon with all the other departments to make sure that fit and function are not affected. As described in Figure 3.7, the customer's demand for improved fuel economy (feature A) drives three requirements at functional levels. Any change that is not hardware compatible could have significant impact on feature A.

Figure 3.7 Basic structure of requirements management.

Requirement traceability secures confidence that the product is completely tested for as many scenarios as possible. Additionally, this map provides traceability of test failure to implications on the product as a whole, mapping specific test case failure to product feature. It is a good tool to analyze upstream and downstream effects with each proposed change, including the overall time plan. Each proposed change presents a potential increase in risk to the project, and it also adds time to the development process. This can lead to demands that pressure project managers to cut corners on testing and quality events to keep the production date stable. Minimizing or skipping testing can be catastrophic. Imagine the scenario in which a winter test could not be done because the project is four months late, and minimum conditions are not met in actual testing. Now the team must entertain other ways to achieve the winter test. This could range from the long logistical and expensive challenge of shipping a vehicle to the opposite hemisphere, or worse yet, delaying the project by one full year to get the requisite winter exposure. Next, we review how the team efficiency is impacted with changes to the project. In the graph (Figure 3.8), the speed bump effect is described. As the project is executed, the team is expected to ramp up and execute, and eventually ramp down as shown in the solid line.

Figure 3.8 Speed bump effect.

In reality, any time the scope is changed, confirmed agreement on direction must be obtained after an understanding of the overall impact. This includes assessment of risk and business case. During such events, the project team gets away from execution mode and slows down (speed bump effect). The team later continues to do the catch-up game through the project life cycle unless drastic measures are taken to put the project on track per original schedule.

3.5 Configuration Management Plan Projects and product development will always deal with changes, either due to technical restrictions or new information. Some project management classes offer more than a suggestion that change is undesirable and should be eliminated. However, it is very likely that in the course of product development, change will happen and the project will have to adapt as we learn more about the intended product. Project managers are therefore in the unique position to always focus on scope, but also be prepared with the risk that comes with changes. To know what constitutes a change, we must create a baseline from which we can compare change requests. The original scope, with fixed cost and schedule, is the baseline, which serves as a reference point when changes are proposed. Every change request must be assessed before any work progresses. For example, in automotive development, if the interface bracket is changed under a cost-reduction idea, it could impact the wire harness, requiring a complete rerouting and thereby affecting different packaging needs.

Beware of cost reduction ideas during the project life cycle. Often small changes can severely impact the final project outcome. For example, a seemingly trivial change to fuel tank design could impact the diagnostics monitors.

Figure 3.9 shows the dollar value of risk at different stages of the project. This graphic compares risk at the paper and board level compared to the ramp-up stages. Making changes during the paper design portion of the project is cheap. The stakes become higher if the change is introduced at the later stages of the project. The project team and sponsors will be more receptive to change at the early stages of the project.

Figure 3.9 Investment risk at different project phases.

Risks associated with challenges in the project can be mitigated widely by proper design reviews. These reviews are conducted cross functionally and consist of reviewing the details and interdependencies of the different departments. Change is often disruptive in nature and can cause loss in productivity; with the right level of engagement, the team can become more involved in the decision-making process, which enables an easier acceptance of changes and better implementation strategies.

3.6 Technical Reviews Design reviews help to evaluate the system performance of the vehicle at the subsystem level. In the early phase, design reviews are a tool to obtain consensus among the stakeholders and gain agreement for product changes and definition of key characteristics. The design review should be done at multiple levels, including paper definition, component, subsystem, and vehicle level. The target audience for each of these reviews will be different, with different expectations.

Stakeholders should not sign off on any changes before understanding the implications of the intended design. Without proper critique, design reviews are useless and a waste of time and money.

Design reviews should be the most effective tool for specification or requirements review. At the concept or early phase, technical reviews are helpful to make adjustments to the product, usually implying low cost. To facilitate a good cross-functional review, the project manager needs to follow key rules: Participants: To get the most out of the group, the perspective to review the design intent

should be diverse. A review by the person authoring alone is pointless, as is a group of reviewers with little technical knowledge or stake in the project. All critical stakeholders, including the engineers who will follow the development and launch of the product, should be involved. Material to review: Documents should be sent out well in advance to be critiqued and to identify the technological gaps or risks. A good review of the scope of what the product is, why the product is being developed, and how the customer will use it should be presented. The review should not solely focus on the technical aspects of the project or product, but should also include its application. Time to review material: Material should be distributed in advance for the subject matter experts to prepare and review the proposal. In some cases, a prototype part or demonstration of the product will lead to productive discussions. Facilitator to manage the process: A good facilitator and a note taker are required. The facilitator will guide the discussion and does not participate in the review. The facilitator works to clarify the group's collective understanding of the item under review, and helps to resolve differences of perspective in a productive way, ensuring sufficient critique of the item under review. Schedule the review: The design review should be planned well in advance for people to make adjustments to their schedules. It is also important to schedule before any major design freeze so that proper feedback and input can be captured. Generate the action plan: Fruitful discussions can create more activities. Design review should capture all the action items, with responsible person and date of completion. After the design review, the team should spend time giving feedback and set the correct course of follow up needed. Before the conclusion of the project and launch of the product: Project reviews with the stakeholders at the end of each phase are a great communication and decision-making tool. Reviews can serve as marketing preparation and manufacturing readiness. With the right competency in attendance and mindset, reviews can establish confidence in the project team. The final phase approval can serve as the project approval as responsibility is transferred to operations. The last section of this chapter is focused on suppliers, because they are one of the biggest contributors to the success of robust product development and project delivery in automotive projects.

3.7 OEM and Top-Tier Supplier Selection

3.7.1 Supplier Selection In the large matrix organization, the purchasing project manager is responsible for leading the efforts of supplier selection. Supplier procurement is one of the most challenging activities in project management. Based on the scope, the solicitation process could be as easy as negotiating production units (off-the-shelf units) vs. working with the supplier as a part of the product development process (supplier integration). In getting off-the-shelf components, risk is relatively low because the product is already in the market and has been evaluated by other customers. For the case in which the supplier becomes part of development process, the risk automatically goes up. Now the project manager has to monitor and manage the product development process outside the organization, and accept the updates on the progress till the production parts are received. A supplier selection matrix should be established early in the project before the quoting begins. The matrix should map an unbiased view. Input needs to come from all the stakeholders in the project team. A major pitfall to watch out for is when the supplier selection gets driven by the engineering group or purchasing group, thus ignoring the overall requirements for the project. Another risk is that the procurement process and negotiations exceeds the core product development phase. Developing a matrix is a good way to prioritize the requirements from each of the stakeholders. Again, this document should be kept internal to the company and the project team.

Supplier selection should be influenced by the project manager, and procurement should be in agreement with other project stakeholders.

Cost is an important aspect of any project, but it is definitely not the main driver for the supplier selection. OEM manufacturers push the Tier 1 suppliers for continuous price reduction, which is associated with increased volume based on market acceptance, efficient process, and/or improved quality based on customer feedback. This compels suppliers to continue to focus on higher yield and better margins through process efficiency and cost reductions. The right supplier anchors the roadmap for technological advancement, securing partnerships for future enhancements. A strong supplier relationship helps to excite the market with the next-generation product line. On the other hand, a less capable supplier organization can have significant and negative impact on the company's supply chain, and ultimately on its profitability. This relationship between OEM and Tier 1 suppliers becomes more complex during a time of environmental instability, such as a global financial crisis. In the case of the financial meltdown of 2008/2009, both the supply chain and the supply base for the automotive industry were affected worldwide due to complex interdependencies between Tier 1 and multiple automotive companies. Automobile manufacturers suffered heavily due to their high

fixed costs and capital investments. Figure 3.10 shows the employment plunge and the decline in the automotive establishment during that time. It depicts the serious consequences to the global economy worldwide and the adverse effect to the associated businesses. The decline in market demand happened on a global scale and triggered the downfall of the supply chain, which is two times or even larger than the automakers themselves. Figure 3.11 captures the vicious circle of financial failure and the inter-relationship between the supply chain.

Figure 3.10 Quarterly census of employment and establishment for North America.

“The government's intervention was absolutely key to helping create a chance for GM and Chrysler going forward. That's why I testified on behalf of GM and Chrysler, as you know. The reason we did was that we believed —like two presidents [Bush and Obama]—that if GM and Chrysler would have gone into freefall bankruptcy, they would have taken the supply base down and taken the industry down plus maybe turned the U.S. recession into a depression.” —Alan Mulally, CEO, Ford Motor Company, October 16, 2010

Figure 3.11 Intertwined supply chain could lead to an industry-wide death spiral.

3.7.2 Supplier Selection Evaluation Process This process can be broken down into the following steps: Establishment of the evaluation team: Cross-functional team with quality, financial, buyer, and subject matter experts. Definition of the scope for the supplier: Request for quotation should capture the highlevel scope with rough timeline for the budgetary bid. Establishment of the technical and business requirements: A quantified way to capture is with a decision matrix. An agreement on critical features is important, and can later drive the decision-making process. Definition of the supplier requirements: Minimum requirements for the supplier, such as ISO certification or financial stability, should be the benchmark before the evaluation begins. An example of supplier evaluation matrix after the supplier has been approved is shown in Figure 3.12. As shown in Figure 3.12, B is clearly out, but the choice between A and C is interesting because C gives an option of quick to market with high price tag. It also means that the

company should be ready to ramp up and market the product quickly to get better return on its investment.

Figure 3.12 Basic supplier evaluation matrix.

Here are a few things to be watchful for during the supplier solicitation phase: Timing of the supplier selection: In many cases, the supplier selection is a rigorous and lengthy process. If multiple bids are made, time to complete the entire process from quotation to the final selection of the supplier can last for several months. Risk becomes relatively higher if the supplier is working with you on the concept selection. The uncertainty multiplies if you are dealing with a platform project, as multiple project team with different scope and suppliers are interacting simultaneously. A platform project is a project that has the purpose of either building a new vehicle platform or refreshing an existing vehicle platform. The platform is the base model from which main variations in the vehicle are produced. Moving through the supply chain presents more risks that are not readily apparent, as the project employs a Tier 1 supplier, who in turn employs Tier 2 and Tier 3 suppliers. The project manager must be aware of and consider these risks. Capacity planning: Tier 1 and Tier 2 can become troublesome and fall into an untenable state due to insufficient capacity or low yield, and all the OEMs must deal with this reality with the global manufacturing facilities. This can happen also when supplier quality is poor. Vehicle integration: During the project phase, energy and focus are put into supplier development. If parts get to the actual vehicle integration phase, and they do not live up to requirements or are defective, serious production and liability problems may occur. The strategic triangle [3-2], as described by Arjan J. Weele in the book Purchasing and

Supply Change Management, gives a snapshot of how the company can strive toward purchasing excellence. By making customers their top priority, and then using partnered suppliers and competitors, a company will be able to drive innovation in product development and offer an efficient solution for the customer. The image also describes how each of the segments impacts the other, and how critical it is to align corporate strategy to the purchasing strategy. This will drive the most cost-effective solution for the end user, and support profitability for the company.

Figure 3.13 Strategic triangle (adapted from Arjan J. Weele [3-2]).

Figure 3.13 illustrates the importance of the balance between three forces—customers, partner suppliers, and competitors—and each of these forces helps drive the profitability of the company. Next, we will discuss the statement of work and some aspects of supplier quality.

3.7.3 Statement of Work A good statement of work is an exhaustive document with all the specific details related to project development, and it clearly defines the expectations from the supplier. It may include items such as technical approach, pricing and logistic strategy, project management plan, quality tools, system application support, maintenance and warranty policy, and corporate quality policy. It must cover the following points: Objective Scope Supporting documents

Specifications, Standards Requirements General Requirements, Technical Objectives and Goals, Specific Requirements, Reliability, Maintainability, Extensibility Milestones and Schedule Acceptance Criteria Contract During the supplier evaluation process, the project manager should be aware of the major pitfalls that can happen during the execution phase. Experience and historical record are a good place to start. It can be a significant challenge for the supplier to respond to the quotation process without the actual details of the product. The project can spiral out of control due to complexity of the development and if the incorrect baseline is established from the start. This incorrect baseline establishes cost targets that may be too low and have an unrealistic time plan from the supplier's perspective.

A supplier with an unknown or untried proof of concept is a great source of risk to project schedule and cost. This can be addressed by differentiating partnerships with core suppliers, and then by selecting a proven concept to be developed and brought to manufacturing.

The project manager should also be vigilant of the risks due to possible deficiencies of Tier 2 suppliers, and monitor closely how these suppliers integrate to the full product introduction. A failure in a Tier 2 supplier will have consequences on the Tier 1 supplier and, therefore, the project. A simple product such as a floor mat can cause a safety risk for customers. For example, consider the size or shape of the floor mat that interferes with, or jams the brake or accelerator pedal, or does not remain in place during vehicle operation. It does not matter where the supplier obtains the parts, the quality of the parts must be assured. At the early phase of the project, many suppliers may be competing for the project. Competition is used to drive the price down, and in some cases the focus on the product can be lost. This can cause scope creep with each passing day, and eventually it can affect the health of the project. During the execution phase, any time delay in engaging the supplier causes a ripple effect in the time plan. If the supplier selection process is the same as, or longer than, the product development

process, the project manager should raise a red flag to all stakeholders, particularly to the project sponsor. Development of the product should be core to the project management cycle, and negotiations should be done quickly but diligently.

3.7.4 Supplier Quality: Sample Quality, Prototype Quality vs. Production Quality Preferred suppliers are those which are closely tied to the company and are often the big players in the industry. The lowest-cost supplier or the preferred supplier is not necessarily the best supplier for all the products and/or projects a company might develop. Each supplier must be evaluated on project objectives and based on facts and figures.

A preferred supplier for common components may be a good thing, as this often establishes standardized cost for multiple platforms. However, if a project introduces a new application of technology, there might be a need for agile development with a shorter life cycle. One box solution does not fit all the projects.

With new projects, the supplier evaluation should be conducted rigorously, with the team primarily consisting of experts coming from the following departments: Purchasing, Design, Project Management, and Supplier Quality. The evaluation team grades the suppliers' capabilities in terms of finance, customer base, expertise, technology development road map, and manufacturing capabilities. The technology road map is the description of how the company intends to grow and introduce the technology into the product line over time. It is based upon technology growth and customer demands. The first step requires that the suppliers respond to the quote with pricing, timing, and preliminary design. The project team then evaluates the supplier's capabilities with respect to the project objectives. The Supplier Quality team assesses the supplier onsite by reviewing details of the financial footprint, quality certification, and manufacturing capabilities. The objective of the work is to understand the strengths and the weaknesses of the supplier during the product development process, and therefore the risks that may be associated with selection of this supplier. The supplier is then selected (or not) based on all the critical input from stakeholders. Any weaknesses and open issues should be recorded by the project team to prepare the right risk mitigation plan. Generating the quality targets for the prototype and mass production units is essential. Any deviation should be clearly understood in either prototype or production parts. Not all deviations are the same. The team must understand the implications of the nonconformance on the customer and product use. It is possible that the nonconformance has no impact on the

customer. It makes no sense to delay a vehicle launch for a product nonconformance that has no negative consequences. One of the major cost problems in any given project is due to nonconforming prototypes. If the supplier and customer agree on multiple iterations, there is little effort from the supplier to meet conformance for the first prototype, resulting in waste of resources, time, and money for the first testing loop. To add value to the development process, the expectation should be to match the prototype as close to the final product specification as quickly as possible. Another issue could be the virtual verification instead of the actual prototype. In the push for leaner, faster, cheaper products, many companies are employing computer-aided design (CAD) tools for verification activities and conducting actual testing later in the project. Take caution with this approach, as incorrect assumptions are risks to the project deliverables.

Virtual testing is very tricky for ergonomically related aspects. Interference with virtual models can be accommodated by moving or tilting some graphics. In the real world, parts may not be easily moved, creating difficulty for product handling and possibly requiring design changes, which become expensive at the late stages of a project.

Everyday activities of the supplier are not governed by the actual project team, and prototype review is the best way to make sure the supplier work is on track. It also secures the synchronization between the two development teams. Fully functional prototypes help to evaluate the health of the product and project, providing a good baseline for quality before the actual production begins. Quality is money and time, and each time a product specification is not met and is in need of prototype revision, earned value is reduced. One of most effective ways to reduce waste in the project is by reducing multiple iterative loops of development. The following aspects should be considered to facilitate efficiency in the project management: Co-location: When members of a team are moved closer to each other, efficiency tends to go up. In some cases, Tier 1 suppliers can be moved with the project team to establish a good communication circle. A full team in one location has a good forum for formal and informal information sharing, leading to more collaborative and effective decisions. Statistical process control (SPC): Based on the number of units getting tested, SPC establishes good measurements for success and failure of the process. The upper limit and lower limit for control charts can be reviewed with the project team, and specifically with aftermarket and manufacturing. The control chart also depicts deviation for the manufactured product from the baseline. Meaningful deviations need immediate attention,

with a rapid action plan to fix the problem and support a containment plan. Number of units to be tested at each phase: The project team should have early agreement on how many units should be used for each level of prototype testing. Clear definition of prototype parts should be agreed upon with the supplier. Early-phase prototypes cannot be sent to customers, and late-phase prototype parts should not be used only for dimensions' check. In the next chapter, we focus on the project schedule and critical elements of the schedule.

References 3-1. Pries, Kim H., and Quigley, Jon M., © 2008 Taylor & Francis Group, LLC. Reprinted with permission. This figure originally appeared in Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality, p. 54, by Kim H. Pries and Jon M. Quigley. 3-2. van Weele, A. J., “Value creation and purchasing strategy,” NEVI, https://www.nevi.nl/sites/default/files/kennisdocument/LEV-TCO-art-017-bl.pdf. Accessed March 2016.

Project Management for Automotive Engineers: A Field Guide Chapter 4: Product Development Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 4 Product Development

“It's not enough that we do our best; sometimes we have to do what's required.” —Winston Churchill

4.1 Project Schedule: Time Plan A successful product development project cannot become an open-ended research program. It must have an absolute focus on the tasks and develop solutions in a finite time frame. With clear requirements defined, project managers should concentrate on establishing the schedule, cost, and resources required to achieve the project and business objective. A review of the historical records of similar projects can support the project team to analyze the resources and time requirement to meet the milestones for product development, testing, and ramp up. All these activities and exercises should also be formally on the time plan because it provides a good preliminary estimate for the project with respect to timeline, cost, and risks. The foundation of the project time plan includes the design iterations, design evaluation, supplier's time plan, and risk associated with all deliveries. Gathering input (including assumptions) from all of the stakeholders is essential for any successful scheduling exercise. The time plan provides critical path information and dependencies for the stakeholders. The first step is for the project management team to generate a preliminary list of work packages and then discuss the interdependencies with each department (i.e., marketing needs will be different than the needs for the testing group). A set of the critical deadlines from each of the stakeholders helps establish the interdependencies and schedule implications at the early phase of the project. Work does not always progress per the plan, as in the following example. Sometimes the project manager struggles constantly to keep the schedule on track. Even after critical deliveries have been missed or failed, the production date is expected to be met and contingency plans are put in place in an effort to get the project back on schedule. Sometimes the project degrades further until resources are added, such as excess over time, off-shore work, etc. None of these solutions will totally fix the initial problems, but they may have a ripple effect through the organization as resources are stolen from other projects to keep this one on schedule. The project profile should be used to prioritize the deliverables—must have vs. delighters. In

some cases, the company employs an umbrella project or program portfolio, with multiple smaller projects delivering and interlinked to a main project.

The company could have a target of 5% fuel efficiency, and multiple projects might be conducted in parallel to deliver the 5% reduction target. In some cases, these projects will have design or technical dependencies. It is essential that the project manager understands the criticality of the interdependency in design changes, and how the activities such as testing can be coordinated to reduce cost as well as reduce schedule risk.

A typical method to develop the time plan is to specify key milestones first, which will then drive the check points for the project. For each checkpoint or gate, the specific deliverables are defined to check the readiness of the project and set a clear view of the project status to management and the team. The main time plan or the top time plan has four principal areas: Key Milestones: These are the major events in the project such as pilot build or production date. Key milestones provide the structure to which the details of the time plan are added. Ultimately, this provides input to the stakeholders to work on their target dates for delivery. Phases and Delivery: Each phase in the project will have gate criteria/checkpoints that are used to set up certain deliveries to meet the target. The project manager should have objective evidence of the deliverables gathered as a result of the project execution. Responsibility: Each of the items in the main time plan and subsequent detailed time plan should have the associated responsible party's name. This will be in alignment with the roles and responsibility split that is set within the project team. For example, setting up design of assembly would be a manufacturing initiative and not the design engineer's task. Similarly, purchasing should be responsible for supplier agreement, although crossfunctional teams will provide support. Dependencies: Schedule development uncovers and documents the inter-dependencies of the activities. A main time plan without the connection of dependencies is not very helpful and would lead to miscalculation of the critical path. A well-constructed time plan, including dependencies, makes it possible to readily see the impact on the project delivery date if the design delivery is delayed by eight weeks, for instance.

The team's assumptions can play a pivotal role in the time plan development exercise, and later add risk to the project. Typically, assumptions are completely set aside in the early project work, or are not even articulated. Then, later in the project cycle, the ignored or unarticulated assumptions become real risks. To reduce this risk, the disclosure of assumptions should be encouraged. For example, when the purchasing personnel provide the information for prototype delivery, all the assumptions involving the supply chain should be logged and understood. The project manager has a difficult task to focus the team on the deliveries but to also be ready to adapt or revise the plan based on new challenges or failures in the development process. These events present project risk but also a unique opportunity to implement a novel approach to the problem.

4.1.1 Multi-Layer Time Plan For the project manager to successfully manage the timeline, the input to the time plan needs to be timely, correct, and aligned to meet the short-term goals and long-term deliverables. All the deliveries should then show clear connections to the interrelated tasks required to produce the deliverable. Two common methods are used to develop a time plan: top-down or bottom-up. The top-down approach develops key delivery dates for the project team, and the team works with the target date to meet for each delivery. This approach works well with abundant resources and expertise: if needed, the project manager can hire more talent to get the job done on time. In the bottom-up approach, those doing the work provide key dates along with discussions with experts. Based on the information provided by the team members and task interdependencies, the main time plan is developed and production date is set. Let's review the approach between two scenarios: Task: To introduce new axles for an automobile. Top-down approach: First, the production or market launch date is set. Next, key milestones are defined, and the team is asked to develop a second-level time plan based on these milestones. The team then works internally to develop or come up with actions to meet the target dates. Bottom-up approach: The project manager asks the team to develop a detailed time plan using subject matter experts. Based on the available resources and time to develop the product, the second-level time plan is developed. The project manager reviews the second-level time plan from each stakeholder, and the time plan is adjusted or modified to synchronize with other departments. Based on team agreement, the main time plan or first-level time plan is developed, which then lays out the key milestones and the production date.

4.1.2 Critical Path Critical path is defined as the longest path of planned activities to logical end points or to the end of the project, and the earliest and latest that each activity can start and finish without making the project longer [4-1]. A well-constructed Gantt chart affords the project manager the opportunity to clearly see and review the critical path. This chapter does not go into every detail on the critical path; however, it is important to note that this technique requires accurate recording of task interdependencies. Additionally, the critical path describes the sequence of activities needed to complete the project deliveries and provides a mechanism for predicting the soonest the project can be concluded. The importance of the critical path is widely misunderstood; it is a powerful tool for the project manager to set up warning signals when the activity or task delivery dates are not met. Experience suggests that when there is no gap between the desired delivery date and the critical path date (no slack), the project will not meet the schedule objectives. When the critical path is affected, the project team can choose various methods to put the time plan on track. For the technical challenges, the team should be able to use knowledge management within or outside the company to resolve the issues quickly. The Cloud is widely used in the software industry but can be used in any industry to tap and find quick solutions for common issues. These easy-to-access “virtual locations” can help a company with reuse and knowledge management by providing storage locations for recorded experience, tools, and techniques within a company to meet a technical challenge. For resource constraints issues, consider outsourcing. Many companies outsource some portion of the product development, but aftermarket, marketing, and testing are other areas that can be outsourced as well. The project team must develop detailed procedures and statement of work to use outside facilities effectively, along with continuous monitoring of progress. Each delay has a potential effect on the project's critical path and results in a delay of the production start date. If the production date does not change, a complete reassessment of the risk should be done. What activities are not getting done and are negatively affecting the original time line? Moving or adjusting tasks may allow the target dates to be kept the same. The project manager should have a list of prioritized tasks that traces back to the project objectives. Prioritization of key tasks helps to reduce confusion for the line organization and sets the focus on the main tasks needed for the project execution.

4.1.3 Interdependency Project: Program Management Program management plays a critical role when the company tries to drive multiple projects with multiple product changes to meet one single target, often a vehicle platform. For example, consider a collection of projects to meet fuel efficiency targets: project A to change powertrain

monitors, project B to streamline the cab, project C to change the hood, project D to change electrical controls to achieve the target. The program manager's task is to manage the interdependencies between each of these projects and the critical deliveries to kick off activities from one project to the other. It is important to be aware that, since deliveries are interlinked, the business case justification for the program is also linked to the success of other projects. The complexity of the delivery should be understood, as well as the scope of delivery between each of the projects and the program. Figure 4.1 describes an entanglement effect of multiple project deliveries. Two projects, project A and project AB, are part of an organization portfolio that delivers components for different markets in North America and Australia. The cost is relatively low (e.g., $50). There is also a platform project AAA that comes in at a later date and is a very expensive platform change (e.g., $1000). The dotted line shows project A as its delivers to a platform project AAA in North America (NA). Some organizations would treat these projects as part of a program with project A and project AB managed and introduced together to improve profitability with these two projects' cost. In case project A or AB is canceled, the impact to the platform project is not just $50. It has implications on delivery date, resource utilization, and material efficiency as well the cost, which could be three to four times higher.



Figure 4.1 Program management complexity over time at different sites.

4.1.4 Gate Criteria Many companies have checkpoints or gates to review the health of the project. This method is often referred to as a stage gate process. These gates or checkpoints are essential reviews of the project status to determine whether to continue funding or to stop the project. The review is conducted by a body typically composed of executives. By reviewing the completed and upcoming activities, the project team can assess the feasibility and predict the probability of success. The review will likely also cover the state of the market for the output of the project and immediate roadblocks. The executive review can be done to either support the project or recommend the project be terminated. Thus, the term sometimes associated with gates is “kill points.” As shown in Figure 4.2, the check point is a good time to reflect on the project and consider the next steps. Once the team is through the specific gate, the project moves on to the next phase. A project can be reevaluated for the strategy during any phase or gate of the project life cycle if any of the criteria below is met: Technologically too risky Cost to deliver and revenues generated do not warrant continuing the investment Customer environment changed Regulatory changes

Figure 4.2 Gate review: continue with the project or kill the project.

We do not go into the specific metrics for each gate, as various companies handle checkpoints differently. Based on the organization size and project content, the team should set up goals and expectations with metrics that predict the project success. In the early phases, the focus should be on concept readiness, and in later stages it should be on the manufacturing readiness. It is also important to include product and process verification results (covered in chapter 5) to ascertain the quality of the product along the way.

4.2 Prototype Delivery and Risk Prototype parts serve multiple purposes for the project. First, getting a prototype on time gives the first tangible glance into the product and develops confidence in the supplier's development process. The ability to exercise or test the prototype parts has a great impact upon the future product development activities, as these opportunities to learn about the part, the system, and customer use provide us with the information needed to adjust the design. The sooner the team begins working with prototypes and testing, the sooner the team is able to learn about the product and improve the system design. Therefore, it is important to have prototypes in the early phase of the project. Yet, even more importantly, there should be enough time to test the prototype and update the product requirements for the next loop of development and another iteration of the product. Without the prototype test and feedback loop to the next iteration of product in the development process, the prototype has little relevance. It is important to understand the tests that will be conducted upon prototypes in the different phases of the project. Prototypes are used to mitigate the risks associated with developing a product by improving the product quality as the project progresses. To optimize efficiency in the product development, the project manager should look for ways to reduce the time to build prototypes through rapid prototyping techniques. Although rapid prototyping may, at times, be a bit more expensive, the time saved and the risk reductions are often worth the expense. Prototype part delivery can be tricky because the development is often happening outside the company's immediate level of control, and getting the part at the right time, with the right functionality to evaluate is crucial. Prioritization of the product attributes and features to be delivered in each prototype part iteration can help solve some of these issues, as the team and the supplier now have a common road map of the product growth. The prototype parts will not only be used as stand-alone parts, but will also be used on early vehicle trials. These early vehicles are often referred to as development mules or test mules. The use of mules is always a point of discussion, as these can be expensive to create and maintain throughout the project. Mules serve as test beds for prototype parts and are treated with a level of security beyond show room cars. For example, the vehicle may have camouflage, the badges may be removed, or the vehicle will be exercised only in controlled grounds. Mules should be as close a representation of the actual vehicle as possible; using obsolete or outdated mules does not serve any purpose. Making assertions of the quality of the system is difficult when the prototype mule does not represent the intended vehicle incarnation. Cost of the test also must be factored in the project cost when working on the prototype testing and planning. In certain cases, such as crash testing, the test is very expensive and, in those cases, all the parameters and content of the unit should be clearly verified. For example, the accuracy of the weight of the vehicle will impact the veracity of crash test results. The test also destroys the unit, so after the completion of the test, the prototype parts can no longer be used. Specific tests such as full-vehicle electromagnetic compatibility (EMC) could be as expensive

as $200K and should be planned out clearly before conducting any testing to destruction. This is not to downplay the role of test to destruction, only to be cognizant of how the prototype parts are tested. More will be discussed on testing in chapter 6. Early prototype parts can present concerns. The first is that, by definition, prototype parts are not fully developed, and these parts are not built using final production tools and processes. In that, it can become easy for the team to become bogged down with issues due to the imperfect hardware. This hyper focus on hardware issues may also completely erode innovation. This problem can be further exacerbated in the presence of an unrealistic time plan. The rushed delivery of the prototype product may require skipping steps that would otherwise be undertaken, which can bring more product problems. When this happens, the project team can spend too much effort and time on fixing supplier issues or trying to find the root cause of “certain” failure modes. The product failed because it was not built to specification, and that is a function of being a prototype part. It is important that the team not spend hundreds of hours over-analyzing the failures, some of which will undoubtedly be due to the nature of prototype parts. Paul M. Leonardi describes this issue in Innovation Blindness [4-2]. This blindness is due in part to uncertainty or technological challenge that arises out of the ambiguity in the product and after the first prototype is received. The team can become fixated over the prototype and not focus on the larger technological issue, and be unable to find an innovative alternative. This fixation essentially blinds the team to other opportunities and innovation. The project starts to incur overspending and, in some cases, becomes halted due to frustration and lack of clarity of the project mission.

If the project's goal is to remotely get data from the vehicle, the team cannot spend an inordinate amount of time analyzing prototype hardware failures to access data. In that instance, innovation often takes a back seat. The project team can pursue brainstorming other methods to get the data in parallel with hardware improvement.

For projects that focus only on research and development and not commercialization, the prototype is vital for strategy development. The team explores multiple options and alternatives to achieve the project objective, often developing a technological roadmap for the feature along the way. It is important not to underestimate the need for supplier participation with the research team to develop and test the technology capabilities. In the R&D environment, prototype development and testing defines new ways to innovate and explore various options. This is unique to research and development because the team is typically not bound by immediate time constraints or customer demand.

4.3 Virtual Testing and Prototype in Product Development

Product development requires acquiring knowledge and reducing uncertainty through the earlyphase testing; often this is done via the use of prototype parts. However, prototype parts are not the only way to learn about or explore the product. Considerable exploration and learning can be obtained from modeling and simulation. However, there is no substitute for the actual parts and real-world testing. Low-cost and high-end computer systems make simulation a costeffective alternative to extensive prototyping. These virtually generated parts are used to learn about product functionality and critique the design even before a part is made. For example, the part is designed using CAD tools and given properties due to shape and material. The performance of the product is measured against the product objectives and customer needs in a virtual environment—simulating the stimuli and customer use to which the product will be subjected. Therefore, an effective model is contingent upon the understanding of the product and the product's environment and based on the product usage. Yet, virtual testing can have its limitations. The virtual simulation will require measurement of the real-world environment such as gathering vibration profiles from specific areas of the vehicle during a range of road and driving conditions. To gather the customer use, we may have surveys, clinics (customer product use and focus groups), and other customer studies. This helps to establish a good baseline for the virtual test environment and develop a correlation with real-world examples. The second step is to review the prediction from the model and compare it to actual performance. This requires subjecting a version of the product (prototype) to the stimuli contained in the simulation. Then, a comparison of the actual performance of the product against the prediction is made. If the matching or predictions are good, then the simulations and virtual testing are likely valid. If the correlation is poor, further improvement in the model is needed.

If the product has many variations or the system configuration has a high degree of variability, it is especially important to employ simulation. In these cases, testing all combinations or configurations becomes impossible, both in terms of time and from the verification and test perspective.

Based on the feedback during the development process from virtual and real testing, the product design is revised. This is a good time to introduce the words validation and verification. Validation is the comparison of the design to the customer's needs being met. Did we build the correct thing? Verification is the comparison of the product to the specifications used to define the product. Did we build the thing correctly? The work with the prototype parts provides opportunities to learn about the proposed product. This learning translates into design updates or changes to better meet the objectives. Figure 4.3 provides an illustration of the multiple uses of prototype parts. Early mock-up parts do not just serve the purpose of verification of the design but can also provide confidence in the supplier development, as well

as validation of the design for customer use. All of those provide necessary input to improve the next iteration of the product.

Figure 4.3 Purpose of prototype.

In iterative product development, the team builds increments of the product and explores that iteration, thereby learning from each increment. The aim is to improve the subsequently developed product and perhaps the process. This iterative and incremental approach reduces risk and ensures that the product is understood, and the development is under control to ensure a high degree of product quality. The incremental product growth is generally tested in steps as described below: Digital models and simulation Mechanical mock up (form only) Form and basic functionality (most important) Form and all functionality

All the above and built-off production parts, tooling, and processes At the start of the project, the project manager works with the product development team to identify specific product objectives to be met during each phase and prototype part delivery. Success requires good collaboration and communication with the different team members articulated in the project time plan. Figure 4.4 describes the iterative testing in which each design loop is used to design, procure, and test. The most important element here is the feedback from one loop of testing or product critique to the next loop of development. During the procure step, we are obtaining an iteration of the product with a specific set of content upon which we will test and learn more about the product.

Figure 4.4 Iterative nature of successful product development.

If there is insufficient time to test the part and provide feedback, it is time to consider not procuring the prototype parts. Keep in mind that these early parts are expensive and can pose a burden on the supplier development program. From the supplier's view, they are “live prototyping” to gain confidence in the business, process, and technical solutions. Another point of which to be aware is the aspect of multilayer time plan dependencies. The time plan for complete testing should include critical connections between the design iteration and procuring parts and specific test equipment availability. Next, the time plan should also account for shipping of the parts. Sufficient time should be allocated for arrival of the parts and critique or assessment as well as feedback on the design iteration at the local unit and the

supplier. Experience suggests that design engineers underestimate the time required to develop the initial requirements and prototypes, and that results in compression of time for testing time of the iteration. With insufficient time spent on testing, the whole effort for the prototype and cost incurred becomes useless. Figure 4.5 depicts an example of multilayer time. In reality, it may be more complicated than the one shown with engineering, marketing, aftermarket, purchasing, finance, and multiple other projects and components, as well as verification and validation activities. On the top level are key project milestones that dictate the deliverables from other stakeholders. These milestones are illustrated in the downward pointing triangles on the graphic. With a secured time plan, the project manager is better able to quickly see when the project execution exceeds that of the plan by monitoring the actual deliveries against the plan. Each late input and unclear strategy has a corresponding ripple effect—specifically, the expected delivery of intermediary deliveries and ultimately, left uncorrected or adjusted, to the production date.

Figure 4.5 Multilayer time plan feeding to main time plan.

It is, of course, possible to think of modeling in ways other than high-end computer applications. For example, consider the shape or envelope of the product. Perhaps it is possible to use cardboard to derive the shape—modeling need not be complicated. Modeling and simulation can reduce development time. It is good to develop strength in virtual testing within the organization. However, modeling via computer is not the sort of capability that happens overnight. It requires the organization to plan well into the future. To be effective, the organization will need to measure the environmental stimuli to which the product will be subjected: this takes time and specialized expertise. Then, the key measurements are used to generate the model for the simulation. Once established, it is possible to achieve great benefit in lowering the development costs, risk, and product development time though incremental effort. With appropriate and efficient tools, a comprehensive model can be developed to reduce the need of prototype parts for certain iterations. That is, reduce the need, not eliminate it. The team should work to develop a good correlation to understand the real stimuli and product response, comparing the models to actual measured performance of the

product. Modeling and simulation require a mental shift from the way a traditional organization works. To be successful requires great amounts of up-front work in the project, often referred to as front loading. It is important to identify which attributes and stimuli can be tested virtually and which require physical parts. Some features can be tested virtually and can be done in parallel with physical testing. Figure 4.6 shows the basic steps for developing simulation models by identifying the correct parameters, building models, running simulation, comparing to test results, and analyzing data. The veracity of the model is important for the success of the simulation effort.

Figure 4.6 Simulation model.

In the case of the long lead time prototypes, a balance should exist between test needs and the associated development cost. As the project progresses, the objectives of the test become different from proof of concept and design evaluation to the manufacturing assessment. With this change in objective, the scope of the prototype also changes.

Simulation is a crucial tool to decrease product development cost and time. However, the company should be ready to spend some initial investment on simulation model development, correlation, and personnel training. If the project gets tasked to use simulation without initial set up, there will be a serious consequence to the project

cost, time to deliver, and veracity of the simulation results.

With the constant advancement of 3D printers, we are able to build physical mock ups of the product that do not require costly and time-consuming tooling. With these quickly generated incarnations of the product, it is possible to provide the customer with the ability to quickly assess the fit, interfaces, and, to a limited degree, the finish of the proposed product.

4.4 Resources Allocation Resources are, unfortunately, one of the riskiest areas in project management. The matrix organization structure with the focus on the line organization can imply that there are wellestablished processes, tools, and well-trained people. However, not all people have the same level of talent and motivation. This seems to be frequently forgotten when it comes to team construction. In the matrix organization, it can also be difficult due to competing control over the resource's expertise. The established processes and tools may adversely impact efficiency as well. To be successful, both the line organization and project managers must work together on improving and preparing the resources for the current and future project portfolio. The project managers may feel stressed to work with inefficient or underperforming resources. It is important to identify this source of failure quickly, and that is where good metrics can show the underperformance impacting the project. The project schedule is a good source for some of these measurements if the project manager maintains the schedule by updating it. When underperformance occurs or the schedule looks to be compromised, the project manager can then ask for higher performing resources or request the line managers to solve by proposing a training plan that will remediate the problem. The problem in working with insufficiently skilled resources is that by the time the project manager understands it, the project is often already negatively impacted, and in some instances there are few “extra” resources available. Resource utilization is also an issue each time the project is delayed, and management may succumb to the compulsion to use more human resources to address the problem. In most cases this does not improve the situation, and it may even make a resource constraint worse as the present team members work to coach these “new resources” on the details of the project and its working methods. Some companies may try to hire people in the middle of the project cycle or when there is a crisis situation. The corollary of Brooks' Law is that there is an incremental person who, when added to a project, makes it take more time. Brooks adds that “Nine women can't make a baby in one month” [4-3]. There may also be a tendency of detriment to leadership in a crisis scenario as key people are replaced and, in some cases, the project managers are changed. More is discussed on knowledge management in chapter 9 (see Figure 9.1).

Change in the project leadership may seem like a quick and easy fix to project's crisis. A team that is constantly struggling with its ability to execute may not have leadership problems. Evaluate the root cause of the issue and then offer specific corrective actions.

It is critical that project management be tied to strategic objectives of the company. Becoming familiar with the project roadmap of the project management office (PMO) can aid in understanding the type and amount of resources needed in the future. This becomes a more complex scenario for an organization that has multiple locations. Getting people engaged with the same dedication and priority, across time zones, geographies, and cultures can be a challenge. Many companies, not just the automotive industry, have engineering, customer support, and production on different sites or even continents, in some cases. Allocating and ensuring a well-trained and energetic project team is not an easy endeavor, but it is very important that this happens for the project to be successful.

4.4.1 Hiring and Training For any project-oriented organization, hiring and training should be done as part of planning for the long-term project portfolio. Management must understand that it is ultimately a team effort that leads to a successful project execution. The project manager's objective is to facilitate turning a group of individual people working on the project into a high-performing team. In successful high-intensity projects in institutes such as DARPA, the project personnel are assigned for fixed duration and tenures to ensure that the full focus and priority are given to the assignment. It also helps to recruit talented individuals from different parts of the world because they know the type of venture ahead, which should be consistent with each individual's talents and goals. This keeps them focused on the tasks. It can be a struggle for the project manager to gather the right talent for a project for cases in which the organization has a high personnel turnover rate. It takes time and energy to train people in the middle of a crisis and establish a sense of urgency ultimately to achieve the goal of creating good team spirit. In the DARPA Model [4-4], an exceptional and dynamic team is prized to deliver high-priority projects and test the solution in iterative cycles. A constant turnover of personnel in the project can easily break the rhythm and jeopardize the project. Over-committed resources in the project portfolio have a serious consequence, not only to the immediate project, but also to all other adjacently executed projects and, eventually, to the entire company. A vicious circle is created from too many projects in the company's portfolio competing for resources. The company strips one future delivery date of a project to complete the immediate delivery of another. Now, the activities that were planned for the future project are not being executed, so, to catch up, management robs from a future project, and this goes on

and on, ensuring no project has adequate initial execution. A great book on the topic is The Fifth Discipline [4-5], which describes this situation well. Constant turmoil regarding resources puts too much pressure on the project manager to meet target deadlines, and it can result in a low-quality product as the team is compelled to skip steps to meet the schedule. This is all connected with the company's vision: an unclear strategy, with too many simultaneously executed projects compared to the resources available, drives confusion at all levels of the organization. This is not the only way confusion and insufficient resources creep into the project. The situation worsens in the matrix organization, where the same people are also dealing with the firefighting activities. Firefighting is not literally the beating back of a fire; it is the euphemism for project team members being distracted from the project work due to more imminent issues that might not be related to the project at all. For example, the same project talent will be required to solve a design problem in another product already in production. The focus on the project is lost, and morale can erode as the team member is tossed about like flotsam and jetsam due to constantly shuffling of priorities.

4.4.2 Tools The company, often via line managers, ensures that the resources are trained and have the right expertise and tools to do the job. The organization's objective should be to have tools ready for the work package and ensure proper steps are in place for the execution of the task. The longterm goal should be to secure skill development that aligns to the business strategy rather than fixing short-term “fires.” This is the road to creating a sustainably profitable product and organization. Talent management is a significant challenge that resides outside the project manager's responsibility, but nevertheless it has the biggest impact on the probability of success or failure of the project: The right skill set and motivation can secure a good start for an innovative platform. Establishing clear roles and responsibility is a significant factor for successful conflict resolution. It is important to define the boundaries of each team member, their responsibility, and how the team works cross-functionally. Defined process: The process, in itself, does not solve everything. However, it does help establish direction, the dependencies between the activities, and the manner in which the activities and the sequence should align. Additionally, establishment of a process is an attempt to make the outcome consistent via repeatable steps. A project with uncontrolled or random changes rather than working cross-functionally is a failure in the making. The team spends more time solving problems rather than developing sustainable products. Standard templates: The project management office generally provides organizationally sanctioned forms or templates for the project managers to use. These can be a risk register

or template for meeting minutes. The idea is not to reinvent the wheel for each project, but to ensure some measure of repeatability between projects, providing more focus and quality time spent in execution. Technology readiness: Understand the power of technology and use it to the project's best advantage. Work package transfer will be discussed in the next section, but for starters, technology can cross all barriers, and a knowledge base can be established and used worldwide. Technology readiness in this context refers to the ability of the team to make use of the advancement immediately. Hard equipment: Securing all the hard equipment on time helps to ensure the development work goes smoothly. Generating a backup plan for any missing equipment provides alternative paths (risk mitigation) should there be failures or problems with the equipment. In some cases, the extra equipment may afford the opportunity to double throughput or reduce the production time. Soft equipment: This one is often the forgotten child. It takes time for training as well as applying and developing the expertise in the tool usage. What starts out as a simple time plan development in the project management tool or software can in itself become a timeconsuming activity that will provide little or no value added until the result can be properly used by the team. The project management fundamentals are more important than the tool. Third-party consulting services is seemingly an underutilized tool around the world. If the project is in trouble due to development, testing, or marketing, frequently another company that is expert in putting the solution together can be found. Matching the problem with the solution is an art. We discuss this more in the next section.

4.4.3 Work Packages Transfer for Consultants Consultancy is one of the easiest solutions to ramp up the project without adding human resource overhead to the company. It can be done in a variety of ways. It is possible for the company to hire consultants within the company, and they can be co-located at the same site. This is a typical or the readiest way in which consultants are employed by the organization. Consultants become an integral part of the core team or sub-team. In another scenario, work packages, discrete volumes of related work, are transferred to a consultancy that is off site. Little interaction occurs with the project team, and that which arises is usually only around progress reporting and answering any questions that may not be clear in the work package contract, or that the work package leader may have. The work package leader is the lead at the supplying organization that is responsible for managing the work as a sub-project. Before

transferring the work package, the scope and objectives must be clear for the job transfer, which is often accomplished with a statement of work. The work package transfer is done to reduce project risk or increase efficiency by using larger volume of human resource or superior expertise in a different company. The validity of these assumptions should be demonstrated with specific metrics to determine that the quantity and level of expertise exists, and that the ramp up will be fast to provide the required business solution. Some projects transfer work without adequate preparation via the statement of work and associated supporting structure. In the long run, this causes chaos and often a mismatch between expectation and what is actually delivered. The supplier, to which work packages are outsourced, must have the appropriate skills, and the expertise and level of customer collaboration should match the content of the transferred work package.

Assembly of the vehicle can be in Brazil, with R&D done in North America and the owner's manual written in Poland. Authors and reviewers in Poland should have some understanding of the customer's use of the product. For example, the simple steering wheel location can change the content of the owner's manual (right-hand drive vs. left-hand drive).

The project team should work closely with the line organization in understanding the complexity, preparation, progress metrics, and risks for the work package transfer. The work package statement of work is a good way to put the details of the proposal in writing and involves creating an agreement that defines the scope, timeline, and delivery plan for the assignment. Gathering the requirements for the work package from the different customer sites can come with many assumptions that are not fully articulated among the team members. That means the assumptions are not sufficiently critiqued. Later, the team may find those assumptions were incorrect, which will create a new set of issues for the project manager. The complexity and dynamics of the interactions in the product development processes should not be understated; they extend beyond the technology and product itself. With a dynamic work environment comes the need for a quick decision-making process. During these critical stages of development, concern can often be resolved via quick 30-minute daily meetings, which can improve engagement, focus, and the decision process. The work package leader plays a pivotal role in the successful delivery of the task. Regular follow up and review of progress metrics makes it possible to highlight the areas where support is needed. Certain pitfalls are found in using consultants and a third-party company for projects. One of the most severe downsides to third-party consultants is often the inability to see the entire picture of how the work is distributed, and how the pieces work and fit together. The ability to

move from a big picture view to the micro view is one of the elements for success. The role of the work package leader is essentially to ensure that the communication around the work flow expectation and delivery is sufficient to support the product development. The split of roles and responsibilities and the structure of the organization become fundamental for successful execution and timely delivery. It is important to maintain good and accurate report cards or score cards based upon the defined metrics. Progress is then monitored continuously. Changes should be documented and managed through configuration and change management processes for the project. This cannot be overstated; outsourced work should include paying special attention to product changes. With either hardware or software, proposed changes should go through the proper critique with relevant parties to secure an agreement and understanding of the implications to cost and delivery. Impact of culture is also an important key to this communication: some cultures and organizations are more risk averse, and the communication style will be quite different.

For the same work package, project manager should expect different response from different suppliers. There are many ways to get to the end objective.

4.4.4 Outsource Testing Facility Outsourcing the testing will be discussed more in chapter 6. The environment of the product usage is an important element for using an outside test facility. Testing an automotive unit in one particular condition does not address the entire market environment in which the vehicle may be sold. Understand the objective and limitations of outsourced testing, and always remember a famous quote from Ronald Reagan, “trust but verify.” Risks should be discussed and recorded in the risk register.

4.5 Key Product Characteristics As a part of results-oriented goals, the project should be able to break all the requirements into must haves vs. nice-to-have features. Removal of uncertainty helps to reduce chaos downstream of the product development process. With lack of key product characteristics (KPC) defined for the project, the tendency is to steer the product definition, leading to multiple discussions, and ultimately causing frustration, and waste of time and money. KPC should be used throughout the project to capture customer requirements to develop a system-level requirement specification to drive design, and finally develop the production process for series production. The successful project balances priorities of cost, and customer

satisfaction and business objectives. Once the KPC is defined for the project, it is important to measure the variables associated with them. These variables should be monitored, and testing should also be focused on the variables to predict the robustness of KPC. In Figure 4.7, the project starts with a vast scope and multiple requirements. The project team works together to define key product characteristics and the project profile. Once those items are defined, the team should have confirmed agreement with customers or the sponsors on these definitions.

Figure 4.7 Defining critical requirements.

The product requirements may include multiple attributes, such as: Critical characteristics are those attributes of the product that have safety implications. This will be product attributes such as dimensions and performance, and process attributes such as manufacturing. Nonconformance or degradation from requirements in any of these areas may cause a failure of a critical safety item. Cost of the product is an important input for the business case. The project manager should continuously watch for changes in the product cost. These occur primarily due to deviation in scope and to secondary effects such as supplier issues, quality issues, and inefficient manufacturing issues. It is important to note that early estimates of the final product cost are estimates, so some variation in the final costs may happen. The variation needs to be understood to find remediating actions or to be accepted. Soft features of the product are defined as any software implication or impact to any communication or connectivity. Consider the communications systems now used in many automotive applications. These are dependent on the information on the vehicle's data bus (communication networks) and on the back-office systems (systems that receive the broadcast of this vehicle data bus information). These soft offers are now considered as big product differentiators and should not be underestimated as sources of project cost,

and risks. Hard features of the product are the physical characteristics of the product and often have significant consequence on manufacturability. They usually come with significant lead times. These should be understood and tested as early as possible due to heavy tooling cost frequently associated with them. Maintainability: Over the last 30 years or so, quality has become a major factor in competition in the automotive world. Because of this, maintainability can have repercussions on the successful product launch. The project manager should work to define the maintainability in terms of miles or time, and quantify the expected warranty cost of the product. Ease of service is also one of the characteristics for maintainability. Manufacturability is defined as the way in which the product can be efficiently manufactured using a repeatable and under-control process. The project cost is the only part of the cost the company incurs to launch the product. If done optimally, the operating cost to maintain the product in the market is reduced, and the product is profitable and thereby adds to the bottom line. Consider, for example, if product maintainability alone is prioritized: the warranty cost can be reduced and the customer's uptime is increased. In the next chapter, we will focus on process overview and its importance in the project execution.

References 4-1. Critical path method. Wikipedia. http://en.wikipedia.org/wiki/Critical_path_method. Accessed September 20, 2014. 4-2. Leonardi, Paul M., “Innovation Blindness,” Harvard Business Review, Dec. 2011. 4-3. Brook’s law. Wikipedia. http://en.wikipedia.org/wiki/Brooks’s_law. Accessed September 20, 2014. 4-4. Dugan, Regina E., and Gabriel, Kaigham J., “Special Forces Innovation: How DARPA Attacks Problems,” Harvard Business Review, Oct. 2013. 4-5. Senge, Peter M, The Fifth Discipline: The Art & Practice of The Learning Organization, Currency Doubleday, 1990.

Project Management for Automotive Engineers: A Field Guide Chapter 5: Process Development Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 5 Process Development

“Excellence is a continuous process and not an accident.” —A.P.J. Abdul Kalam

5.1 Process Overview The overall chain of events that is required to get the designed product out to the customer from the manufacturing line is known as process development. It consists of incoming materials and material handling, process steps to produce the product, as well as shipping and logistics. In the areas where the floor space is cheap, the manufacturing line may actually resemble a line. If the company supplies a variety of products, the production line will need to be adaptable and easily accommodate the change from one product to another. The line may be reserved for only one product or one customer. The expected volume likewise has influence over the layout of the line, as does the available floor space and talent. The organization will likely have a philosophy regarding the approach to the production line based on the resources, technological complexity, mode of assembly, partnered supplier, export/import regulation, and environmental policy.

5.1.1 Waste A good way to learn about waste in the system can be by reviewing the concepts from the Toyota Product System, the details of which can be found in the book, The Toyota Product Development System, by James M. Morgan and Jeffrey K. Liker [5-1]. Good synopses of the areas of wastes are provided in the next section, as an overview. Consider not only material or machines but also the personnel when you read the text.

5.1.1.1 Muda Waste can sidetrack the project from achieving its objective. In lean parlance, the word muda (a Japanese word meaning waste) is important to consider for manufacturing. This waste can be for every part produced, meaning an erosion or even elimination of profitability with every

product built. A simple way to remember these typical categories of waste is through the acronym TIMWOOD: Transportation - excessive transportation of the material and goods, not just in the final shipment but all stages of the manufacturing process. Each movement represents an opportunity to lose or damage the product and does not add value to the product, but only adds to the transaction costs. Inventory - excessive raw material, as well as work in progress (WIP) and final product that has not yet shipped. These represent expenditures (capital) by the company that have not yet generated income. Motion - unnecessary motion of employees that translates to waste of time. This also includes waste due to machine or operator wear and tear as well as accidents that result in damaged equipment or injured personnel. Waiting - to be worked upon, idle machines waiting for the parts to arrive from inventory or the prior process stage. Over-processing - more effort spent on a part than the customer requirements dictate. An example of this would be an over-reliance upon inspection. Over-production - making more of the product than required or demanded by the customer. Defects - rework of the part or product is required to put it in line with the customer requirements. The company incurs additional labor costs and spends more time on the work in progress category. These two additional wastes more widely apply, and especially are applicable to project management and projects. They are: Human potential - poor use of employee or team member talents and skills. Confusion - poorly articulated decision or direction as well as contradictory or misunderstood goals and metrics. This can be due to poor communication within the project.

5.1.1.2 Mura Mura is unevenness and refers to the waste due to a disjointed or uneven flow of the work or

work products. Most people will have experienced a work life in which the demand upon them has highs and lows rather than a continuous maintainable pace. This is the concept of mura in a nut shell. Subassemblies waiting to be processed are waste when operators are idle awaiting material that is likewise inefficient and wasteful. This includes talent of the team and not just the machines or material.

5.1.1.3 Muri Muri refers to overburdening of the system. Where mura is peaks and valleys of demand, muri is constantly pushing the process, machines, and people beyond their respective capabilities. Over burdening people begets mistakes in the work and increases the risk of safety incidents and rework. Overburdening the equipment leads to machine breakdowns and the production of errant material.

5.1.2 Manufacturing Line Most people associate a sequence of stations end-to-end when they think of an assembly line. In this text, the use of the words “manufacturing line” may not mean a line at all. Not all manufacturing is set up in a sequential straight line as that of Henry Ford's original assembly line. Sometimes manufacturing is set up in a way that resembles the reason for the name assembly line shown in Figure 5.1, and sometimes it is in the form of a cell, as shown in Figure 5.2.

Figure 5.1 Assembly line - all the stations are lined up in a straight line.

Figure 5.2 Cell form: assembly is done in the form of a cell to improve efficiency.

The use of manufacturing cells is typically associated with lean manufacturing. Manufacturing lines thus configured may have similar machines in the cell. These similar machines can then be supervised or run by a single person with the requisite skills. This concept can work very well for batch production. Many automotive companies may require a dedicated manufacturing line, which means that cell or line can only be employed in the execution of certain products for that OEM.

5.1.3 Product and Process Synergies The specifics of manufacturing the product are devised in process development. To develop the product manufacturing process, the project team will consist of product development and manufacturing constituents. Consider, for example, the scenario of little or no connection between the product development and the process development work, which has two possible outcomes. In the first case, the development team may deliver a product that could require costly changes in the existing manufacturing equipment and processes, perhaps eroding or

eliminating the business case for accepting the project in the first place. The addition of expensive new equipment or a radical new way of working can eliminate the profitability of the product. In the second case, industrial engineering requests expensive design changes late in the design to meet manufacturing capabilities. This, in turn, increases project and product development costs due to design rework, along with the associated time delay to product readiness. The project sunk cost, that money already spent on the product, may necessitate the extra expenditure since to not spend the money means to not produce the product and begin recouping the investment. Therefore, the product design and the manufacturing readiness activities are simultaneous and interacting processes often referred to as simultaneous engineering, throughout the project life cycle. With careful planning and a coordinated effort, it is possible to maximize the profit potential and reduce the time to market for the product.

5.1.4 Process Areas of Focus The process development consists of all the activities that must be performed to deliver the product from design output, through production to the end customer, and includes: Product quality (manufacturing related) Volume of parts to be produced (including rate per unit time) Cost to manufacture (time, tools, material, and equipment to manufacture) Cost to ship, including special containers and associated tooling The manufacturing process development work will have implications on all these dimensions, and each of these areas has numerous contributing elements. For example, for the manufacturing processes to deliver product quality, those processes must address identification and handling of incoming and nonconforming material. Too much errant incoming material will slow down the volume of end product produced, which increases cost per unit. Poor control over the incoming nonconforming product will increase the risk of negative quality impact on the final product. In both cases, costs are increased due to excessive material handling, and perhaps rework. With this example alone, it is easy to see how product quality, volume, and cost are interrelated. In addition to the material handling and segregation, the manufacturing line steps and actions that are needed to produce the product must be choreographed and well documented, and the operators must be well trained. Everything from timely raw material order and delivery to staging and through production of the product and shipping to the customer, resides in manufacturing. Provided below is a specific listing of areas in which the production team must work: Process Steps

Process Instructions Production Line Creation Production Line Critiques Tools and Fixtures Handling of Product and Errant Material Shipping Ultimately, the goal at the end of this set of activities is to provide evidence that the line is under quality control and repeatable. This can be accomplished through the following outputs from the project team: Packaging Standards Product/Process Quality System Review Process Flow Chart Floor Plan Layout Characteristics Matrix Process Failure Mode and Effects Analysis (PFMEA) Pre-launch Control Plan Process Instructions Processes in this regard are all of those steps that go into the manufacturing of the product. Each step in the process has to be defined, developed, and proven to yield a repeatable process. To start, first understand the impact of the product scope on the manufacturing process. The AIAG documents referenced provide an excellent road map. Additionally, if the manufacturing organization is built upon a philosophical approach (modular or linear), the company will likely not want radical deviation from this method, as this will require a higher level of expense, more risk exposure, and maintenance of two production systems in the company. Perhaps the product rationalization (reason for accepting the project) was contingent upon making use of existing production process modules or stations. Even at the late stages of product development, control is possible over the cost of the final product in terms of assembly and production cost.

5.2 Tier 1 Production Line and Prototypes The project can take advantage of the fact that both the product development and the manufacturing development (process and tools) happen in concert. Specifically, the team can have prototype parts built from portions of the manufacturing processes as these become available. The parts built from these processes provide learning opportunities about both product design and manufacturing processes. The project is able to also assess cost, efficiency, and risks associated with the manufacturing process development. It is even possible to experiment with the impact of changes on the production line and efficiency, and how these changes impact cost and quality. In doing so, the team is in a position to learn about theories postulated at the start of the project—called assumptions. The production of prototype parts from the burgeoning line provides opportunities for feedback on the proposed line capability in addition to providing parts for product development verification and validation activities. In fact, as the line becomes more capable and begins to resemble the final product, so too do the prototype parts become more representative of production intent. More will be discussed in later sections.

5.3 OEM Product Handling The complexity and logistics of parts requirement for automotive needs, makes it critical that product and parts handling should be monitored throughout the end-to-end process. End-to-end means from the beginning, as parts come into the Tier 1 supplier, all the way through installation and end customer use of the product. No matter how well the product conforms to quality standards at the Tier 1 supplier, as soon as the parts leave the supplier warehouse for the OEM production line, the parts should be handled based on the requirements and standards set up by the supplier and the automotive company. For example, consider an instrument cluster that passes the supplier's end-of-line testing, and is then shipped to the OEM for vehicle installation. The parts arrive on the dock and are removed from the shipping package. At this stage, the parts are relatively unprotected, and subsequent reckless handling on the way to the installation point can result in cracked glass. Sometimes the tendency is to blame the supplier for the failure (the person that witnessed the breaking of the product seldom comes forward). Even if the failure is found when removing the product from the packing and shipping material, it is important to explore the reason for the failure and not fall into the logical fallacy and the desire to attribute the failure to the supplier. To prevent any mishaps, the purchasing agreement should capture all the logistics, parts handling, and packaging of the units in the end-to-end process. Product FMEA should capture details of handling protocol and failure modes of sensitive parts in case of mishandling.

5.3.1 Part Numbering Revisions

Part number changes fall under the configuration and change management plans. Design iterations may have impact on the manufacturing process. This is valid whether in the steady state production phase or in the project phase of the product development. There are rules for the product part number change, and those same rules have implications for the manufacturing process as well. Changes to any of the following list of attributes should trigger consideration of part number revisions. Fit concerns the ability of an item to physically interface or interconnect with or become an integral part of another item. Any proposed change in the existing or new product due to the project requirements should be reviewed in the change management process, which is the function of configuration management. Uncoordinated and discontinuous product alterations can cause system miss builds, process alterations, and sometimes can create major deviations for the project. Each deviation adds cost and risk to the final project delivery. Form is the shape, size, dimensions, mass, weight, and other physical parameters that uniquely characterize an item. Using industrial engineering, there should be a minimum of poke-yoke done for each change to ensure that the bolt fits the nut. Function is the application of the unit or the system. This extends to the way it executes or performs the function. In the automotive world, multiple functions have interdependency, and it is important to make sure the dependencies are captured in configuration management. Interchangeable item is the measure of a product that possesses such functional and physical attributes as to be equivalent in performance to another product of similar or identical purposes. The interchangeable item is capable of being exchanged for the other product or subassemblies without selection for fit or performance, and without alteration of the products themselves or of adjoining products. In such events, where parts change, it is crucial to have clear revisions via part numbers. This allows product development as well the manufacturing facilities to manage events such as product recall. Interface is the performance, functional, and physical characteristics required to exist at a common boundary. This is one of the most forgotten attributes during development. A comprehensive process should be in place to establish a list of parts and associated interfaces, as this is essential for cross-functional performance. Any issue related to misalignment can be solved with appropriate interface control.

With clearly defined interface parts, there should be a process established to monitor any changes to the interfaces at different stages of the product development.

Interface control is the process of identifying, documenting, and controlling all performance, functional, and physical attributes relevant to the interfacing of two or more products provided by one or more organizations. Quality is any improvement or degradation in the product based upon any introduced change. A process should be established to trace changes in the development of the manufacturing process that have subsequent quality impact on the product. In Figure 5.3, process A, B, C, D produces one level of prototype, and due to the result of the feedback in the process, the next iterative process becomes A (same as previous), B2 (change from previous), C (same as previous), and D3 (huge deviation from previous). A good matrix is required to identify which changes caused the quality of the prototype to improve or degrade.

Figure 5.3 Change of process due to feedback loop.

5.3.2 Deviations and Waivers Deviations are authorizations granted prior to the manufacturing to depart from a particular performance or design requirement of a specification, drawing, or other record for a specific number of items or a certain time. Waivers or concessions are an authorization to accept a product that, during manufacture or after submitting for inspection, is found to depart from specified requirements but, nevertheless, is considered suitable for use “as is” or after rework by an approved method. These are important concepts as the prototype parts increase in capability according to a plan, or may have to depart from that plan as the team learns about the product and must work within the confines of the prototyping and manufacturing. The right language provides a common view of the state of the part and of the project. Where deviations and waivers are needed, changes to the design documents should be considered to avoid the long-term management of deviations and waivers.

5.4 Manufacturing Specific Deliverables For the manufacturing process, certain specific deliverables need to be completed prior to production start. The specifics are the achievement of agreed-upon targets between the project team, management, and the customer. Each of these manufacturing processes impacts the efficiency and cost for the company and, therefore, should be monitored closely. Critical targets are: Product and Process Quality System Review, Key Characteristics Matrix, Process Flow Chart, Floor Plan Layout, Process Failure Mode Effects Analysis (PFMEA), Process Control Plan, Process Instructions, Gauge Repeatability and Reproducibility (Gauge R &R), Poke- Yoke, Run at Rate, Trial Production Run, and Packaging Standard.

5.4.1 Product/ Process Quality System Review In industries that employ ISO quality standards, quality reviews are obligatory and audited periodically. Quality review covers the product and the process within the company. In the process phase, the review is to ascertain the competency of the control plan and supporting documents to achieve the objective. The Automotive Industry Action Group (AIAG) (found online at http://www.aiag.org/scriptcontent/index.cfm) checklist for quality review includes questions about personnel, training, various measurement system controls, visual aids, configuration, and details on the process to build the product.

5.4.2 Key Characteristics The characteristics discussed next will have specific symbols and names associated with them as defined by the customer. Key Product Characteristics (KPC) are the attributes of the product that make the product perform. For example, the key product attributes of a bumper are that it should have the ability to absorb shock, and the shape to enable aerodynamics. These attributes likely originate from project requirements. Key Control Characteristics (KCC) are the attributes of the manufacturing of the product wherein control over these variables is essential for product success. Variation in processes will have implications on the product. The goal is to match process and capability with the requisite level of control. The defined KCC will focus the team on the key process. Critical Characteristics (CC) are the attributes or metrics over which monitoring and controls are maintained to ensure performance of the product. These are mostly safety metrics. This part of the product is designated as a critical safety item, or an item wherein a failure will cause subsequent safety system failure.

5.4.3 Process Flow Chart Process flow charting is not just for manufacturing. The process flow chart diagrams the material flow and the build of the product, and it provides a description of each station in the manufacturing process. A graphical representation of how the manufacturing line will look in the final states establishes capacity planning at the Tier 1 supplier. This provides the team with a base for critique (PFMEA discussed later), as well as a common map for the work of developing the manufacturing capability of the product. Part of determining the production processes for the product requires an understanding of the relationship between the available manufacturing time to produce the product, and the number of products to be produced. This relates to Takt Time, which is the rate of product completion in order to meet the production volume needed to meet demand. Cycle time is the actual time that will be used to make each unit of the end product; it is based upon the available time and the desired number of units: The number of units to be produced is 300. The time available to produce the units is 10 hours (600 minutes). This means that 600/300 or 2 minutes is available to produce each unit. Manufacturing processes must meet the target of 2 minutes/unit or less to produce the desired number of parts in time. Cycle time is the amount of time it takes to complete a task; besides the theoretical cycle time, the actual cycle time can be determined via a stop watch. The sum of the cycle times to produce the product must be less than the Takt Time to be able to produce the desired number of final production parts.

5.4.4 Floor Plan Layout The process flow map will inform the team of the steps and equipment that will be required to produce the product. The floor plan will be a scaled graphical layout of the equipment and stations for the product manufacturing; it includes the movement of the material through the line. Synchronization or connection of nomenclature between the process flow chart and the floor plan layout makes easy identification of where on the floor a specific step or process will happen. This will also be an area of critique via the PFMEA by the manufacturing team. Additionally, the team will perform value stream analysis to ensure that no waste enters the system. A lean manufacturing approach known as 5S is gaining considerable support in various

organizations. 5S is a five-step process that results in improved safety, efficiency, cleanliness, organization, and morale. The idea behind 5S is to get employees involved in creating efficiency and engaging them in the company's long-term growth and competitive advantage. It is one way to handle all the ergonomics opportunities in a much more disciplined manner and continuously monitor it. The specific areas of the 5S are: Sort - eliminate obstacles and segregate unwanted material Systematic arrangement - streamline so all necessary items can be obtained easily and a smooth workflow can be achieved Shine easily clean work stations, maintain equipment Standardize easily determine and establish best practices for the work area Sustain easily keep things in order via discipline and audits

5.4.5 Process Failure Mode and Effects Analysis As the DFMEA is to the design, so is the Process Failure Mode Effects Analysis (PFMEA) to the process. The review is conducted using the same methods as the DFMEA. However, the team will change and so will the focus area. To maximize the value, a continuous review, starting from the graphical representation of the production line, is desirable, and it is important to engage the right industrial, process, and quality auditors. The review work is not a single-pass event at the closing of the line development. Specifically, as soon as the flow diagram is completed, the PFMEA activities should start. The PFMEA document will evolve as the line develops and new risks and limits are uncovered.

5.4.6 Process Control Plan The ability to deliver a quality assured product is part of the project objectives and is impacted by the Process Control Plan. Creation of a product that cannot be produced at the desired quality and production volume will essentially mean a failed project, failed product, and loss of investment. From the manufacturing perspective, the process control plan helps secure the production implication on the product quality. The process control plan is essentially a matrix of items, whose purpose is to improve our probability of success, which is defined by reduction of waste and delivery of a quality product to the customer. The process control plan (Figure 5.4) has a column for using customer-defined symbols to emphasize the key product/process characteristics. Note that this approach applies just as much to services as it does to manufacturing. Making changes to the

product or to the processes requires revisiting of the process control plan. The control plan therefore grows as the product matures to a production level of maturity. Note the areas for stage of part and the part number. Figure 5.4 gives an example of the control plan and is also described in AIAG Blue Books [5-2].

Figure 5.4 Example of control plan.

The process control Plan (PCP) is a matrix of items listed in tabular/columnar format. Contained therein are: Process number (to be tied to the PFMEA), process/operation description, device used for manufacturing, characteristics, special characteristics, tolerances, evaluation measurement techniques, sample size and sample frequency, control method, and reaction plan.

5.4.7 Process Instructions Process instructions will reside at each station on the manufacturing line. They instruct the operator how to perform the work at the station, which includes what tools to use. Instructions consist of a list of sequential directions and can include a list of measurable attributes. The instructions will likely have graphical elements to illustrate the work directions. In fact, in some places the work instructions may be on touch screen and via video. The process instructions will provide information on how to use the tools, and identify gauge repeatability and reproducibility (Gauge R & R) studies.

5.4.8 Gauge Repeatability and Reproducibility (Gauge R & R) Gauge R &R [5-3] is the part of the measurement systems analysis process in which exploration in the variation of the measurements due to tool and talent are studied. An example (Figure 5.5) is provided of an Excel sheet for tracking.

Figure 5.5 Example of gauge R & R measurement and tracking.

The test employs multiple operators (appraisers) taking measurements of parts (samples) with the specified measurement device or tool. Information on those measurements will be recorded and assessed to see how much variation is present in the measurement system, including operator perception or interpretation. Gauge R & R refers to repeatability and reproducibility of a given task on a production line. A statistical analysis is performed upon measurements taken by the operators (or machines) on the process. Using the statistical analysis, if there are issues, inferences can be drawn. Three examples follow: either the product is causing too much variation (product issue), the operator is not able to measure correctly (training issue), or the tools used are causing variations (equipment issue). To have the best results, the product needs to be matured, and training and tools should be adequate. Once the baseline is established, gauge R & R can be a powerful tool to measure quality of the production.

5.4.9 Poke Yoke Poke Yoke originated in Japan. It is the term meaning mistake proofing and is sometimes referred to as “goof-proof.” The technique is employed to ensure that the product part under consideration can only be installed or fit, or built to the subassembly, in one way. The goal is to reduce mistakes, as rework is costly and reduces the manufacturing line efficacy. In Figure 5.6, the left side of the picture shows three wired bundles in three connectors. On the right side, those same wired bundles are color coded by wires and the connector. This is an example of poke yoke in that there is no issue connecting the wire bundles to the appropriate connector.

Figure 5.6 Poke yoke for an electrical connector.

5.4.10 Trial Production Run The manufacturing team (including the supplier quality assurance engineer) will perform work with the supplier to develop a trial production run (TPR), sometimes called a pilot run. This will be used to develop the manufacturing processes and improve the specific line processes. Trial production runs happen before the start of run at rate (R@R) and production part approval process (PPAP) activities. The objective is to work out the unknowns of the production line, such as station variation, specific work instructions, and throughput improvement activities. This is analogous to the prototype parts for the product development work in that learning from this activity is used to improve the processes employed to produce the product. This affords the team the ability to make quality improvements and develop a stable line in advance of the production volume builds. Using this method, portions of the production line are targeted and stressed. The production team will identify metrics or measurements that will allow them to make tangible evaluation of the capabilities, which establishes realistic goals of the production line, including rate and throughput. To accomplish the objective, both the supplier quality assurance and industrial engineering will need to be heavily involved. It is often prudent to have key developmental engineering

staff present from both the supplier and the OEM. This critical, multiple-perspective review ensures that the product from the line will meet quality requirements at the desired volume and to the customer's expectation. This exercise is especially beneficial for lines that employ large amounts of manual labor due to the human-oriented quality of the controls (often visual inspection). The goal is to produce improved work instructions and tools for the assembly process. Part of the trial production run is to determine an estimate for the first-pass yield of the product. The first-pass yield is the ratio of the useable parts to the entire population of produced parts, and is a measure of line capability and efficiency. This measure of end-of-line parts consists of parts that are not reworked or manipulated but are from the end of the line and capable. For example, if there are only 90 working/useable parts from a run of 100 parts, then the first-pass yield is 90%. This becomes a target for the line improvements, and helps to plan the production rates to meet the customer volume demands. If the line is capable of 90% efficiency, and the peak production capable volume is 10,000 parts per week, then manufacturing and the customer expectation of parts cannot exceed the production of 9000 working parts without rework of the remaining 1000 parts. This informs the team and the customer of the ability to meet the full production volume, and provides a measure of the waste in the manufacturing line.

5.4.11 Run at Rate Run at rate has been discussed briefly at the beginning of this chapter. The purpose of run at rate is to demonstrate that a quality product can be built at required manufacturing, quantity/time efficiency, and cost. Run at rate should be planned early in manufacturing process development to uncover production risks. Since Tier 1 units produced are not part of an OEM production run, they do not make it to the end of the OEM manufacturing facility; neither are they used in the construction of a customer's vehicle. However, a number of solutions have been found for using these parts, so the material is not wasted. Earlier discussions on prototype parts use fits here nicely. These parts are frequently used in OEM testing, including systems integration and durability and reliability testing. This can include validation activities as well: events such as customer reviews or critiques of the product in a controlled setting. These parts are sometimes also used in process verification testing (PVT), which will be discussed in later chapters but essentially fills the same role for the process as our design verification testing (DVT) does for the design. Performing run at rate activity uncovers bottlenecks in the process. It is also provides the mechanism in which the first-pass yield of the line is discovered, which provides a measure of efficiency and indication of waste due to rework.

5.4.12 Packaging Standards

Part of the process to deliver the product includes the shipping of the end units to the OEM customer, also known as the manufacturing facility. Building the product to the customer quality targets is part of the story. Standards that apply to product logistics include the following shipping container aspects: Returnable package Recyclable package Pallet material composition (returnable dunnage) Pallet size, weight of maximum filled packaging Package envelope limits (l × w × h) Package identification, product layout in the packaging Packaging also includes how service parts move through the supply chain. These packaging and logistic requirements will likely differ from that of the manufacturing volumes. Manufacturing locations are not the same as parts distribution center location and can have huge complexity due to a diverse supply chain, as shown in Figure 5.7. In the whole logistics picture, product quality, product forecast, push vs. pull methodology for logistics, and need of replacement parts further complicates the scenario. All these decisions are not part of project management but are more of an operation's area; however, each of these criteria has an impact on the successful project execution.

Figure 5.7 Packaging and logistics of the OEM [5-4].

In the case of introducing new technology such as hybrid, liquid natural gas (LNG), and compressed natural gas (CNG), parts can be labeled as “Dangerous Goods”; the project team has the responsibility to take care of details on how the parts will be packaged and moved within the assembly line and also through the supply chain.

References 5-1. Morgan, James M., and Liker, Jeffrey K., The Toyota Product Development System: Integrating People, Process, and Technology. Productivity Press. March 25, 2006. 5-2. Reprinted from Advanced Product Quality Planning (APQP) Manual, 2nd Edition, 2008, p. 58, with permission of FCA US LLC, Ford and GM Supplier Quality Requirements Task Force. 5-3. “Gage R&R Study Example,” QI Macros, http://www.qimacros.com/gage-r-and-rstudy/gage-r-and-r-example/. Accessed April 17, 2014. 5-4. A2Mac1, Automotive Benchmarking. https://www.a2mac1.com/home/loginpage/. Accessed April 17, 2014.

Image

source:

Project Management for Automotive Engineers: A Field Guide Chapter 6: Product Life Cycle and Testing Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 6 Product Life Cycle and Testing

“Expect the best, plan for the worst, and prepare to be surprised.” —Denis Waitley

6.1 Fundamentals Testing is the continuous verifying of the product as well as the processes throughout the product development life cycle. Product testing starts early—as soon as there is anything from which the team can learn and adapt the design. The same is true for the processes employed in the manufacture of the product. Models and prototype parts provide the earliest possibilities of proving the design concept and production processes. To start, define the prototype and incremental iterations in a way that maps to the project objectives (e.g., the highest priority features or high risk items, etc. should be tested and verified first). Even though the definition will likely change as the team works with the product and processes, it will keep the team focused and provide a reference point from which to start. The testing activities provide one of the learning mechanisms for the team regarding the product. The testing outcomes are analyzed, and adjustments to product or process, or both, are made. Alternatives are developed to fix or remediate the design or the process issues by which the design is produced. The interaction is depicted in Figure 6.1—test, analyze, and fix.



Figure 6.1 The three main pillars of product development.

Experience shows that the testing portion of the project is often a source of great risk. In the beginning of the project, it is important to determine the processes required to manage the test and verification activities. For example, an established process should exist for handling nonconformance or bug reporting, to whom the bugs are reported, and a scale for severity of the defect. If the company does not have a process as part of the organization's working method, the project manager and domain subject matter expert team members must develop the procedures and secure the proposed process cross-functionally with the project team and sponsors. This requires clear articulation of how the team will work, and then this process must be followed, changing as learning dictates. A few of the possible failures seen in the verification area are listed here: Team does not know how to report test results: In such a case, differing formats or methods of reporting can cause confusion. Excel spreadsheets, Word documents, and emails should not become preferred ways. A common tool that serves as a repository for all bugs and failures that are reported should be used to communicate cross-functionally and escalate to executives for resolution as needed. Some examples of specific areas for resolution can be test or development resource availability, and prioritization of bugs or prototype product nonconformance. Numerous tools that allow recording of test cases as well as test results are often part of product life cycle management (PLM) tools. Lack of tools (equipment, talent, and time): Prototypes that arrive late or test equipment that is not ready cause stress on the test team and can lead to short cutting to maintain the timeline. Specialized test equipment can be expensive, and to justify purchase often requires keeping the equipment fully engaged or employed. Late-arriving parts will often impact the use of this equipment, and the next project in the queue. Getting back into the test rotation will require additional planning and perhaps reprioritization. Overly optimistic view on the product quality: The testing of the product or process should be approached critically. The team is looking for evidence to ascertain the quality of the product or the process. The team should be well motivated and unafraid to break the product. An overly optimistic view can impede an objective evaluation based upon evidence that is a desired perspective. Poor categorizing of the fault reports: Severity points are assigned to all faults reported. This provides the ability to prioritize the resolution of the failures. Not all faults are equal. Faults that are nearly imperceptible should not be prioritized above those that have catastrophic consequences. For example, a failure in the brake system requires more immediate attention then perhaps a rattle or moderate mirror vibration. Although both issues should likely be fixed, it is clear that a failing braking system can have a much more severe outcome and should be prioritized higher to garner the appropriate level of

attention. Political aspects: The testing environment should be kept sterile and away from political influence and undue hierarchy stresses. This enables a true judgment of the product without fear. Excessive politics that desire to downplay or cover up failures found, and that may pressure the test group to underestimate the severity of the problem, are not helpful. This is especially true for instances in which the product development and testing reside in the same organization. Experience suggests this is a critical area of concern.

6.2 Testing Process Given the complexities of most modern systems, testing should happen often and should have as high a level of automation as practical. With automation, it is possible to move through the testing quickly, covering a larger scope of testing of the product, with minimal human interactions and, thereby, reducing human-fatigue induced errors. Automated testing is a good solution for the requirements-based testing portion of the test suite.

Pay attention to time plans that reduce the time available for testing, or that relegate testing toward the end of the development cycle. Either of these approaches could result in lower-quality products for the customers and the company.

By developing key performance metrics for the testing phase, the project team creates transparency, measures product quality and efficiency, and is able to assess the risk to the organization. These metrics also help in predicting the future changes and overall success of the project. A few key performance metrics are listed here: Total number of test cases: Provides a measure of the amount of the project scope that will undergo verification activity. This represents the amount the project team and test experts believe should be tested. Percent completed: Is defined as test cases performed divided by total number of cases planned. Measuring percent complete over time can tell us about the efficiency of the test resources, and can help us predict when all of the test cases will be concluded. A weighted percent complete can also be used, with which test cases are weighted by duration, effort, consequence of failure, or another applicable scaling factor.

Failure rate: Is defined as the number of test failures per test cases. It can give us a quick snapshot of product quality and allow some level of prediction regarding the total number of failures the testing may uncover. Distribution of fault reports by severity level: The higher the severity, the more aggressive the action plan needed to resolve the issues quickly. This information makes it possible to predict a high-quality launch. As an iteration of the product or system is tested, the numbers of failures are recorded, including the severity levels. The numbers of defects found will accumulate at first, but then should decrease due to our corrective actions. Expect to see an ever-decreasing number of failures and elimination of the most severe. If this is not the trend, process problems are likely. This information is valuable for deciding when launch is possible. Rate of test case completion tells the efficiency of the resources and allows predicting of the end date of the project testing phase. The verification portion of the project team should understand the methods, mechanisms, tools of verification, and test procedures, which, in turn, will help with the metrics creation and tracking. Key performance metrics help to make an objective assessment of the product quality, limiting rampant and optimistic opinion with facts.

Consider this example: 30 test cases are completed, but they only constitute 10% of the total scope of the testing. In those 30 test cases, the team has found three serious errors. This means, in the remaining 90% of the test cases to conduct, another 270 opportunities exist for a failure to derail the project. In those 270 opportunities, more failures in the serious category are likely: perhaps even 2-4 times the quantity already found.

Effective product testing has many parts: Customer specification and standard: The project has contractual objectives and requirements recorded in the specification. To confirm that these are met, the verification should record tests that map to the requirements and on to the scope. This provides the proof via demonstration that the contractual requirements for the product have been met. Extreme testing: Testing the product to the design limits and beyond provides the team with some understanding of the product's capability limits. All vehicle states cannot be readily known; standards and the organization's measures and modeling can reproduce the

real world only so far. Pressing the product beyond the standards informs the team of margins for failure. A technique often used for this type of testing is called highly accelerated life testing (HALT). This multiple-stimuli testing stresses the product beyond the material weaknesses to determine what will fail and the nature of the failure. Be prepared that anything that can go wrong may go wrong, and the team will need to understand the consequences of the failures on the vehicle as a system. Ultimately, the project team will need to ensure an honest, objective critique of the product. This may be more difficult than it seems, with chronic time pressures and overly optimistic executives. The project manager must create a work environment where what is often perceived as bad news is welcomed. Test engineers should be able to publish or broadcast the results based on facts and without fear. It becomes more important when there is massive investment and the product starts failing. The project manager should then perceive the testing results as warning signals to fix the root cause with corrective actions. To achieve good testing results requires planned test cases as well as exploration of the product by the test staff within appropriate boundaries. Test cases are the discrete scenarios created to exercise the product performance or to evoke a failure. Test cases are typically, although not exclusively, defined by the product specification and provide some of the evidence that the product is able to perform as specified. These test cases collectively may be as simple as driving the automotive unit and checking the right and left signals, or as comprehensive as accumulating millions of miles in different climates, terrains, and drive cycles. The test requirements range from capability and performance to durability and even failure modes. Test cases are only as good as the experience of the test engineers, knowledge of the product, and understanding of the market as well as human behavior. A simple switch function could pass or fail based on the product environment and driver behavior. In a clean environment, the switch can be manipulated with soft handling; in a rigorous environment such as that faced by the driver in a cold Alaska oil field, the switch functioning will be different with thick, unclean gloves. Test cases should simulate both environments if the product must exist in both environments. Previous tests and standards should be leveraged. For every requirement, there will always be one or more test cases, and interdependencies with the functionality at the system and subsystem levels. A requirements list of 100 unique requirements does not necessarily mean 100 test cases; each of these 100 requirements also feeds into interdependency tests, stress tests, and load tests. For example, if the project introduces a new rear view mirror, a simple installation and clarity check can fulfill the requirement. However, a more comprehensive way of testing is in the different conditions such as fog, rain, night, or highly humid conditions; this leads to additional test cases. The second step will be to test while driving, reversing, or with other different modes of operations,

leading to further test cases. Driving over bumpy roads, exposure to elevated temperatures and obstruction of vision of certain drivers creates even more test cases. Therefore, a simple requirement can generate 5 to 20 test cases, or even more. The test engineers should work with quality teams to understand the amount of risk with each of the interactions, and then define the appropriate test case scenarios. Historical data, warranty failures, and customer complaints are helpful in defining the test cases and setting boundary conditions. Failure rate or defect arrival rate also helps to provide a warning signal about the product quality and to predict the generalized state of the product. However, what can be an interesting metric is the percentage of test cases conducted compared to the number and severity of the faults found. For example, during the development phase, 30% of the test cases are completed for the first iteration of test, and 10 failures of a moderate severity and 6 catastrophic failures are found. From an initial analysis, it can be easily extrapolated that the product is not fit for production, and there is a high probability of more failures. Perhaps twice as many of the high severity faults could be found after the test iteration is complete. In determining the sequence of testing, consider the value of performing the highest risk tests first to learn the results early and take appropriate action. It is also important to not perform any destructive testing without considering the number of available parts for testing. After all the test iterations are completed for the project, a final report should be published and signed as part of contract closure. These reports form the basis of complete agreement between project stakeholders for the product performance and deviations.

6.3 Agile Practices Applied to Conventional Projects Typically, and errantly, in conventionally executed projects, the development phase has testing as the last part of the activities. In some cases, it is also a sacrificed activity if the project goes through multiple delays in development or due to lack of parts availability on time. In such scenarios, the project manager should explore alternative or more efficient ways to conduct testing that produces evidence that would develop more confidence in the product. This often requires adaptation of the development process. The theory described next depicts a few of the best practices in testing and validation process by following quick steps of the Agile Scrum methodology. Scrum is one of the most popular methodologies under the Agile umbrella. Personnel: To make agile practices work for testing requires very strong leadership, often in the form of a scrum master. The scrum master makes sure that product backlog (entire prioritized and estimated list of work to do) and sprint back log (partial prioritized and estimated list of work to do in a time-boxed iteration) are maintained (in this case, test execution). He is also responsible for the daily sprint meetings (scrums) and engaging the team to uncover the appropriate set of activities by asking questions: What has been done? What will be done today? What are the roadblocks? By doing so,

the team is fully focused on the scope of the work, and progress measurements are established to check the success rate. The ideal prerequisite is that the resources are secured and dedicated to the specific project. Scope of the test: All of the requirements, specifications, and applications are identified as the test scope. Based on the expertise and the maturity of the organization, scrum can work either by assigning the work to the team members by breaking the tasks into easily measurable and testable parts or, ideally, defining the scope for themselves based upon expertise. Duration: The team should develop daily work sheets as well as define the duration for the testing of the total work package. Measurements or burn down chart: In the daily sprint meeting, team members deliver measurement data that result in the tracking of the test activity. This can be monitored daily or weekly based on the project's priority. Figure 6.2 shows the graphical snapshot of the Agile Scrum methodology applied to testing.

Figure 6.2 Agile methodology applied to testing.

6.4 Communication during the Test Phases Communication during the test phases is imperative because it provides a feedback loop on the product state that, in turn, inspires confidence in the product or, if needed, provides the project team a mechanism to obtain management support. Tracking report: Scrum master (if Agile is used) or the line organization manager should track the test progress daily to ensure expected testing deadline is met. Often the test and validation activities are seriously time constrained and need to be scrutinized. An example of tracking chart is shown in Figure 6.3 with time on the X axis and percentage of the test cases completed on the Y axis. The solid line shows the expected or the desired rate of completion and the dotted line depicts actual execution. Frequently, the team does not get started immediately due to lack of resources, guidance, test material or tools; this is depicted by the dotted line with the delay. A buffer should be included in the plan if needed to account for this. Once the execution starts, the team works to beat the expectation (or at least reach the planned date) and continuously may struggle due to time constraints (in the graph, the dotted line never hits 100% mark). If the test team finds multiple high-severity problems, test should be stopped until a better iteration of the product is received. Another option, although slightly more painful, is to continue the testing until this iteration is as completely tested as possible. The more failures in the project, the longer the time required to test as test staff must understand the failure and accurately record and report.

Figure 6.3 Tracking chart to establish KPI for rate of execution of testing.

Status report to the project team: The project team should remain in close contact with the test group. Status could be reported as the tracking chart, Pareto chart, and a list of prioritized failures that present obstacles. This report should have a detailed explanation of the failures and their implication to the customer. Figure 6.4 shows the defect rate per week, and based on early results, the project manager should be able to cancel (or request to cancel) the entire testing if the first iteration of the product has numerous severe functionality issues.

Figure 6.4 Defect arrival rate.

Status report to the management: The project manager needs to work quickly if any safety risks are found in the product, and daily reports might be necessary. In other cases, the team can choose to report weekly or after the test iteration has been completed. We can summarize testing information in a single graphic that captures key information regarding the testing, which is the rate of accomplishment, and the defect rates as well as severity (see Figure 6.5).



Figure 6.5 Defect arrival rate and severity.

6.5 Verification vs. Validation Process Verification and validation do not mean the same thing. Verification of the product means conformance to the specifications and standards—Is it built to the specifications? Validation is the customer's perspective—Does this product meet customer needs: Was the right thing built? A product can pass the verification and meet all the specifications, but the customer can still be unhappy because it did not meet the need or the customer's expectation. Both are important to test and confirm the product suitability for customer use. For example, the customer expects a hybrid car to get very good fuel economy (miles per gallon). In the verification process, all the aspects of safety, legal, comfort, and fuel economy are tested, and during the validation process the application is tested for the specific fuel economy requirement. In the validation process, the team pays special attention to how the product will be used by the end customer. For each application, city driving as well as highway driving, the fuel economy is measured and benchmarked against competitors. This demonstrates that the customer targets have been achieved. Product testing ensures that project objectives are met; a few examples are provided below. In engineering, testing activities are deployed to ensure feedback mechanisms to the development direction. The team learns about the prospective product or service as it is developed, altering the developing path to meet the needs. These actions are performed to expose faults [6-1]. Demonstrate that requirements have been satisfied. Assess the suitability of the product to customer needs. Calibrate performance. Measure reliability. Make sure changes have not produced adverse side effects (regression testing). Establish a level of diligence that can be referenced in the event of product liability litigation.

Verification and validation should be part of the product design and development and

not treated as the last look before launch. If the verification is the last activity in the project time plan, make sure to secure sufficient budget for recalls and field fixes.

Verification and validation activities can occur at the same time within the development process. End users can perform the validation because they will often experience the product or process in ways not considered by the formal verification and validation teams. This feedback should be used as lessons learned for future projects.

6.6 Product Validation Validation compares the product against the customer needs. It answers the question: “Does the product or service meet the demand of the customer?” Therefore, validation work requires a way of getting user reviews of the product. Those user perspectives may originate from within the company executing the project, or via a few key customers' critiques. Validation further reduces risk by examining the product or service under conditions that are more realistic, because the assessment of the product is from the customer's perspective and actual use. Sometimes the verification activities will uncover interesting failures, and the team must resist the urge to summarily dismiss then with the “that will never happen in the field” mentality. Experience indicates that is often just not so—it will likely happen in the field. To understand the subsystem and system capabilities, it is important to validate the system from the bottom up rather than throw the pieces together and then try to figure out the failure from the interactions. For example, it is possible to stress a bracket holding the bumper, and to compare it to the requirements. Once that experiment is concluded, the subsystems are put together to see how the components work together. By doing so, the problem areas are identified earlier in the subassembly life, before the final assembly takes place. This approach is aligned with the V-cycle model covered in section 2.3.2. The main steps for a validation plan are to prioritize the combinations of importance, and ensure that time is sufficient to check those applications and run enough miles to deem the product fit. For example, a 100-mile usage of the automotive unit that is intended to last hundreds of thousands of miles should never be considered as a solid test. The following bullets are examples of key items to consider when developing the validation plan. Miles accumulation: Based on the historical usage of the unit, define the target for the validation. For some vehicles, it could be as high as 300,000 miles. While the vehicle is under the company's warranty, it is the company's responsibility to bear the complete or partial cost of fixing the vehicle; this can have a significant impact on the profit and loss for the organization. The team should carefully audit the failures that occur “under warranty miles.” Acceleration techniques may be explored as well. Acceleration

techniques are used to age or stress the product in ways that represent the life of a vehicle in a much shorter time. Essentially, the team compresses the time to accumulate the same amount of stress as a full duration test. Application of the unit: The test scenario should be based on the vehicle application, whether for city driving, rough terrain, or highway driving. Each of the applications will have different modes of operation for the transmission, engine, and overall vehicle. Climate: Climatic condition also should define certain application tests. If the product will be used in North America, the validation program should address the cold climate of Canada and the hot and humid condition of Louisiana. The elevation of the location also dictates the vehicle performance and should be reviewed. Legal requirements for different markets: If the company is selling the product in different markets, the team must understand those local legal requirements and be able to perform tests accordingly. California has much more stringent rules than the EPA, and Mexico or Brazil might have different legal needs; this should all be understood in the design and then tested and validated as part of the product testing process.

6.7 Product Verification and Features The verification process ensures that work packages meet the accepted requirements, particularly given that the customer often demands rudimentary testing in the specification. Verification demonstrates that the work packages conform to the requirements or specifications, and it often includes activities such as testing, analysis, inspection, demonstrations, and simulations. As such, verification is necessary for project closure. This function is conducted at all levels of the design, from the documentation phases to bringing the physical aspects of the design to a mature product line. An important part of verification is the peer review process. These peer reviews can be a short design review of the hardware and software. They can be physical inspections or a structured walk-through. In the development process, peer reviews can be performed earlier in the game than testing, and can reveal defects or failure modes within the documentation or drawings. If the product is modified after the test phase, another iteration of product verification activities is likely required. A seemingly insignificant change can wreak havoc on the project and cause undue stress for the team. Carefully consider the downstream implications of the change, rather than dismissing the consequences of the change as inconsequential. A conservative approach would be to test any and all changes made to the product.

6.7.1 Reliability Reliability of a product is associated with the ability of the product to meet the performance and functional requirements over time. It is the measure of the quality of the product over a specific period and how quickly it may fail. To predict or forecast the failure rate, the team needs to acquire abundant data from the testing of the product. Evaluating the product for reliability requires probability and statistical analysis to assess time to failure and failure rate. This is aided by determining product life in the verification work and determining a correlation between real-world stimuli and the test stimuli. It is important to scrutinize the prototype part capability. For example, the early prototype product is often made from a quick prototyping material such as a 3-D printer using stereolithography (SLA). Of course, it makes no sense to test the durability of an SLA part; it will certainly fail during such testing and not tell the team much about the end product's reliability. The reliability of prototype parts can nearly match that of intended production parts with the use of 3-D printers, making it possible to perform reliability testing earlier in the product life cycle.

6.7.2 Durability of the Product Durability considers the entire lifetime of the product and the various exposures to which the product may be subjected. Durability closely resembles reliability and represents the performance of the product over time with an addition of stimuli. Proof of durability is more than just the mathematical analysis; it also includes the environmental type testing to which the product is subjected. To understand the durability of the product, the project team may employ highly accelerated life testing (HALT). This technique allows the team to ferret out the weaknesses of the product due to design and/or material. The objective is to specifically break or destroy the product to find out where it fails, and to do so, the product is stressed beyond the design limits. The team can then consider the failure and the margin between the expected field stimuli, product performance, and the induced failure.

6.7.3 Extreme Testing Extreme testing includes those tests that push the limits of the product and the vehicle. For example, the vehicle should go through winter testing in the northern climates, such as the northern reaches of Canada, to push the vehicle to the extreme expected performance ranges. Similar testing should be done in the desert during summer seasons to subject the vehicle to that set of extreme conditions. It is pertinent that the test subject, vehicle, and team be ready for these critical test phases. Missing one winter test means one of three things: Reschedule for another winter. This delays the project by one year, if that is acceptable.

Ship the vehicle to the area of the world where winter is happening. In most cases, it is practically impossible to do the test due to shipping cost, regulations, and the specific test environment. Forgo the testing completely. Accept the risk that the product is not verified or validated for cold conditions. Simulate cold. The vehicle is packed into cold chambers, and certain limited performances are tested. These limits are great and the costs are heavy.

6.8 Process Verification Process verification activities will test the ability of the processes for manufacturing the product, as the product verification activities doe for the product. This will happen in two places: the supplying organizations and OEM. Process verification is done in part by confirming that the product built off the manufacturing line is capable and suitable for the customer and OEM. This means that the production is efficient and cost effective, and the quality targets or standards can be met. Manufacturing has targets for the investment cost, cost to manufacture, quality, and throughput of product. These requirements are used early in the project scope, and the project team has defined actions to meet those operational objectives. The process verification activities provide the confirmation or refutation of achieved objectives. Process verification activities often resemble the product verification activities in terms of specific tests, but are done with different goals and expectations. The process must be able to produce the product, as this is just as significant for product quality and project success as the design. To gain the best value of the process testing, the products should be built on the line that represents as close to the intended process protocol as possible. For example, if the intention is for the part to be assembled on the manufacturing line, and during the test phases, the tank is assembled in a subassembly area, the actual manufacturing intent is not properly addressed. That means this area of the product development is effectively uncertain. Also, if the assembly is done on the actual production line, the project manager should ascertain if the assembly is done by the industrial engineers or the actual technicians, as this also represents a difference from end intent. All of these OEM examples or similar types of examples apply to the supplying organization as well.

If the process is not followed, good documentation on the deviation is needed. This deviation should be agreed upon with the project team and then anchored with sponsors.

6.9 Verification through Simulation Early simulations help confirm a course of action or a particular design solution. It is vital for the project manager to understand the benefit to project cost and risk mitigation. The mechanical engineers can use simulation for the mechanics of the design. For example, finite element analysis (FEA) is a simulation tool that helps the design engineer to understand the stresses on the product according to multiple load scenarios. The power of modern computers makes this tool a very viable option to learn about the product and even the processes for manufacturing. Simulation does not come free; a significant portion of the cost is in identifying, creating, and verifying the models for simulation. This effort will require researching the stimuli to which the product will be subjected, building the model, and then comparing those results to real-world results through testing. Learning from this testing will drive alterations in the model to improve the prediction capability. The process takes time, but in the end it improves efficiency and can save money by allowing the project team to start earlier and reducing tooling or prototype part use. In the case of the product development, money is saved by avoiding errant development directions. For manufacturing, simulation can save money by enabling virtual learning without the need to build the actual product on the manufacturing line. Virtual manufacturing is a new buzzword for the automotive world. However, much progress is yet to be made to mature the ability to have the right skill set and right tools to validate the process. For example, if the technicians do not understand the difference between various torque levels and how the system should be tested, the company should be careful in deploying virtual tools.

For cost-efficient simulations and virtual testing, the organization should also spend enough up-front investment in training to develop the right skill sets and validate the models. If any of these elements is missing, there is increased probability of failure, and higher risks to the project and company are likely to happen.

6.10 Continuous Conformance Testing Continuous conformance testing happens well after product launch and, as such, is usually not much of a concern to the project. However, it is incumbent upon the project manager to identify if this would actually be a requirement and set actions in motion accordingly. The contract may require the supplier to perform a prescribed set of testing on the product

every 6-12 months after initial launch to ensure that the quality of the delivered product is maintained as defined by the project and the supplier contracts. This testing certifies that the supplier manufacturing line is still capable of delivering per contractual standards. The testing of the product (and the process) should be linked to the failure mode effects analysis (FMEA). This is true whether considering the design FMEA or process FMEA. In the design world, the DFMEA should evoke from the team by evaluating the content change and degree of complexity. How can the product fail, and why? The team will generate and evaluate (prioritize) the implications of the failure. These ideas are then brought to the testing activities to confirm or refute the theories.

In some projects, testing and FMEA are two different worlds and not connected. Therefore, they do not produce the desired results. With proper connection to the development and end product expectation, testing can be adapted to address prioritized failure modes and improve the robustness and efficiency of testing.

6.11 Different Test Modes 6.11.1 Internal Testing Testing can be done internally in an organization or externally. Internal testing is much easier to manage, as the test engineer and test facilities are often on site. Additionally, internal test personnel are likely to know the intent behind the specific tests conducted on the product, whether it is for a subassembly, subsystem, or the entire system. Internal testing suggests connection to the product in a way that would mean the tests will be conducted to evoke the types of concerns the customer may have. For example, a product has been tested by the supplier, and a near-production level version has been sent to the OEM. The OEM puts the part on the vehicle and performs some tests that may seem redundant to the testing conducted by the supplying organization. Yet, the results of the OEM testing indicate a catastrophic failure. In review, the method used by the supplier to perform the test was inadequate, and on closer inspection, the issue was found to be the gauge of the wires used in the supplier's lab vs. those at the OEM's. Internal testing is necessary, even if there is confidence in the supplier. Anybody can make a mistake—it is best to verify the situation. Inspection of the test facilities and further clarification of the test and the results are more quickly discerned when on site. This basically points out the gap in the testing environment due to lack of correlation between supplier's lab and actual expected vehicle usage.

6.11.2 External Tier 1 or Contract Testing Contract testing is important when there are concerns over the objectivity and capability of the test personnel or when specialized equipment is needed. It can also mitigate certain risks. An example is when there is significant pressure to complete multiple-level (component to system) testing in a short amount of time. Using multiple sites to test various features can expedite the testing process; it amounts to testing around the clock. For successful execution of contract testing, the scope of the test should be understood and frozen, the capabilities of the external team should be evaluated, and the project team should be reviewing the progress via metrics continuously. Subject matter experts should analyze the testing methodology of the contracting company in terms of its process and efficacy.

6.11.3 Inspections Inspections should happen early in the project or product life cycle. In fact, inspections can be applied to both project and product documentation to review the project plan, and possibly discover any potential shortcomings or previously unknown risks. Uncovering and discussion of assumptions is as important as the discourse on the test plan. This quality assuring activity should be done with the project team and sub-teams. Inspections can also happen for customer requirements, design specifications, test documentation, product drawings, bill of materials, process documents, work instructions, and other artifacts needed for a quality product, and take the form of design or document reviews. Projects can include this activity as part of the project audit and question the production dates, maturity of the design, and test results. In conclusion, good data helps the project manager and the project team to make informed decisions. Even in the case of bad test results or failures, do not hesitate to report, escalate, and establish the appropriate sense of urgency for support from executives and sponsors. Failure should be viewed as opportunities to fix the problems before the start of production. With the right type of skill set, each of the quality events can effectively improve the product up to the final audit of the product and thereby reduce project cost.

Reference 6-1. Dunn, Robert H., and Ullman, Richard S., TQM for Quality Software 2E, p. 174. San Francisco: McGraw-Hill, 1994.

Project Management for Automotive Engineers: A Field Guide Chapter 7: Design to Ramp Up Production Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 7 Design to Ramp Up Production

“A collection of best practices does not make a successful production system.” —Michael Maccoby

7.1 Why is it critical? Efficiently and effectively managing technology and customer demand is fundamental for a profitable business. However, the technology transfer needs to be complete and synchronized with operations (manufacturing) for a quality and profitable product. Each year there are numerous examples of unsuccessful product launches due to toothless attempts at controlling the technology to serial production. The worst part is when the product fails during ramp up or the early stages of production either due to low quality or high cost. Activities need to be distinguished between pre-production, ramp up, and full production, and that is why this book breaks these down into individual chapters. Each of these phases will emphasize different objectives and have differing quality tools, logistics, risk management, and production matrix. Each is a function of the product type and the size of the company. In Figure 7.1, “0” month is considered as a start of pre-production builds or start of ramp up, and any build before that is built using prototype parts.

Figure 7.1 Ramp up of the production line.

Vehicles produced before “0” are usually owned by the project and could be used for testing and manufacturing assessments, customer evaluation, or marketing such as trade shows. A start of ramp up is when the vehicles are built for customers per orders or for stock in dealerships. These early units are the first time when the complete supply chain is tested; the supplier starts to see the product forecast from the plant via EDI (electronic data interchange) at volumes that do not represent prototypes. Logistic rules are followed; specifically, production part approval process (PPAP) approved material is shipped into the factory at planned volumes in containers. These parts will go into vehicles that are built online. For the automotive industry, ramp up to production cost is another major cost incurred in the project life cycle, primarily due to heavy investment cost internally and cost incurred by the suppliers. It is also another opportunity for success or failure. It should be remembered that during ramp up we are not building at the regular production rate, which implies reduced revenue. It is also possible that the manufacturing facility is still producing some other models from the line during this

transition time. In the early phases of the project, based on the volume and the complexity of the product, the project manager and team decide on the ramp-up strategy. If the project is introducing a radio, the scope is likely limited to certain variations of select vehicle models. The system is restricted to the radio and its connections with the speaker configurations. The ramp up may be limited to a few vehicles with the new radio to test the production flow, ease of installation, and at the end of the production line, to review the look, feel, and functionality on the vehicle that may be due at end-of-line check out. The purpose of limited production runs is to make manufacturing aware of the changes and associated implications and to get feedback from customers. The ramp-up strategy changes completely when it is an entire vehicle platform project. In that instance, the scale of the ramp up becomes massive from a few hundred to thousands of vehicles. Ramp up may be accomplished in batches, and each of the batches can serve multiple purposes, from engineering evaluation, manufacturing process check, marketing reviews, and product and customer evaluation. With large volumes and rapid ramp up, new tools and vehicle production processes may be introduced as well. All of these changes will likely result in a need for training, safety, and material handling procedure changes, and any of the myriad of other newly introduced factors that will influence the “new” operational efficiency calculation. Changes in the processes of the OEM production line can add to the overall risk to the project. Therefore, it is crucial that during the development of the product, manufacturing representatives study the process, identify and quantify risks, and establish the test plan for the actual ramp up. Many of these activities are executed by manufacturing process engineers, quality auditors, and industrial engineering personnel. Anything related to the new product should be reviewed in design for assembly activities. Industrial engineering should also measure the total time of the operation to understand the delta installation time incurred due to the project content. Delta time is the change, either an increase or decrease, in the amount of time required to build the vehicle. This should be recorded and reflected in the business case and in the profitability calculation of the project. Logistics and current product order should be considered during the ramp-up process. Available slots are allocated to the new product, and industrial engineering should pay attention to ensuring that the current offering is already met or there is a contingency plan to support the order board. The order board is the log of vehicles ordered by the customer and provides a measure of demand and therefore production volumes and type. This can be particularly cumbersome when the new product builds may not be line-sequenced parts. As described in Figure 7.2, during this phase, development work is coming to an end and Tier 1 and Tier 2 supplier involvement is ramping up for early production. The development work does not abruptly terminate, although fewer development personnel are required for this support. The dotted line depicts Tier 2 suppliers, which should ramp up earlier than Tier 1 to

ensure that parts are available at Tier 1 plants to build its assembly, which will subsequently be shipped to the OEM in time for the vehicle build.

Figure 7.2 Ramping up at Tier 1 and 2 suppliers to meet production start.

The Tier 1 supplier then follows logistics rules to make sure that the procurement is complete before the ramp up starts.

If the production parts are not available on time, early build becomes a complete waste of time and money. Expediting material greatly increases piece price as parts are flown into the factory. This will likely have an impact on the ramp up to full volume schedule.

7.2 Activities Needed from Design Board to Production Floor Design information needs to be shared through the project life cycle for a smooth and reasonably uneventful production ramp up. Various product life cycle management tools (PLM) are available to facilitate these connections from the design through production. During the project life cycle, the information flow must happen from production to design and from

design to production, and now the team will see just how effective those plans were. In Figure 7.3, the final design of a bracket gets feedback from engineering, virtual tools, and from early builds. If the design has been well coordinated with other design elements, and the information flow in the early phases of design was successful, there should be little or no change at the end of the project or during the ramp-up phase.

Figure 7.3 Input to the final design via builds and tests.

A simple bracket can become a costly affair if the installation does not consider operator ergonomics or if the bracket holes are misaligned. Beware of passive participation by stakeholders in all stages of the project.

Early engagement of industrial engineering team members to view the product design and understanding the total impact upon production is pivotal for manufacturing feedback to the development process. This is the same concurrent engineering discussed earlier. It does not apply only to Tier 1 manufacturing, but also to the OEM vehicle manufacturing. The easiest

way to check the total scope of the impact of the project content is by reviewing the new parts list and identifying how many parts are getting removed, carried over, and added by the project. Based on the parts list, the complexity of the project scope may be ascertained, and this in turn identifies changes in design, logistics, supplier selection, and operations at the OEM factory. Quality tools such as design for assembly and manufacturing should be used [7-1]. The production team needs to start looking at process FMEA (PFMEA), just like the Tier 1 supplier would do earlier. Any new processes, new or adjusted equipment, and estimated time for installation must be discovered, planned, and delivered. Those same Tier 1 types of activities apply to the OEM as the team prepares the manufacturing line to be able to build the final product. Based on the complexity, virtual manufacturing should be used to address any issue in design for assembly (DFA) and design for manufacture and assembly (DFMA). The feedback should be used early in the project to make design adjustments for ease of assembly and manufacturability. Physical build with prototype parts are also conducted to verify and validate production processes, and ergonomic criteria. These physical builds may not be on the assembly line but at a separate area (sometimes called the methods build area). Sufficient time spent early developing work instructions, and effectively employing quality tools, can address any gaps or failure modes evoked in the PFMEA by the team as a consequence of the ramp up and production. During the early phases of the projects, ramp up verification and validation plans should be established for audits. Risk is reduced by checking all the processes needed for successful production: from parts procurement and logistics to final delivery of the vehicles to the dealer and the end customer. Any documents deemed to be shrouded in secrecy to preserve trademark secrets should be signed off early in the project. Some projects can demand setting up a new protocol for the product handling or packaging to avoid any sneak peek by competitors. In one of the platform projects, for example, the company decided to add packaging inside the vehicle to hide the new dash. Such requirements should be discussed early in the project to answer questions such as, “Where will the packaging be added?” or “Which entity is responsible for the cost?” Understanding the risk to production and implications due to an increase in production volumes for a new platform are essential factors in the launch decision. Does the new product fall into the existing line or is there a need to develop a parallel product line in the plant or off site? There are advantages and disadvantages associated with both cases. The operations manager should uncover and document added risk in the risk register, and prepare the risk response (mitigation or other response) plan in conjunction with the project team and operations. Another consideration is ramp down of an older product line. During the product ramp up, the project manager must also establish criteria such as the length of time the company is willing to support older products. How will the material inside the warehouse be handled if there is waste at the plant or at the supplier's factory? Often, this excess material at the OEM is

diverted to aftermarket as replacement parts, but that is not always true and requires work to achieve this on top of associated risks. An agreement must be established as to what part of the company will absorb the write-off cost. In 2008, during the economic meltdown, multiple companies struggled with new product introduction, but the bigger problem was handling the disposal of outgoing parts in the production line due to the significant and unforeseeable dip in market demand. In general, the write-off cost or the scrap cost will show up as part of the Profit and Loss statement for the manufacturing plant, and is not included in the project's profitability calculation. Figure 7.4 shows the equilibrium point where the same number of units is needed in the plant for ramp up of new product and ramp down of older product.

Figure 7.4 Equilibrium point for parts to reduce waste.

The supplier should be signaled much earlier than the equilibrium point to ramp down steadily to avoid or reduce waste. A steady quantity of old parts is required for warranty purposes. These parts are handled via different logistics and packaging, and do not come to the operation floor.

7.3 Critical Activities to Support Ramp Up 7.3.1 Production Part Approval Process (APQP and PPAP) The Automotive Industry Action Group (AIAG) has developed the Production Part Approval

Process (PPAP) standard as part of advanced product quality planning (APQP) [7-2]. The PPAP documents provide a demonstration of diligence from the respective areas of product development and should not be viewed as just a collection of documents to be signed off to start production. These documents provide evidence that Engineering, Product Evaluation (test), Production, and Quality have performed the necessary actions to secure a good-quality product. The specific documents included are: Part submission warrant Design records and drawings Engineering change documents Design failure mode effects analysis (DFMEA) Process flow diagram Process failure mode effects analysis (PMEA) Dimensional results Material/performance test results Initial process study Measurement system assessment (MSA) studies Qualified laboratory documentation Pre-launch control plan Appearance approval report Process control plan Bulk material checklist Product sample Checking aids (gauge R&R) Master sample Customer specific requirements

APQP is focused on product design during the concept and development phase process design at the end of the development phase, and industrialization and launch focus during the industrialization of the project. APQP should also be done for software development, with focus on project planning review, requirement or functional review, initial design review with specification, final design review with complete set of test plans, and finally, software PPAP. PPAP approval ensures that all the specifications requested by the company have been met with valid design documentation according to the AIAG standards, the manufacturing process has the capability to produce conforming parts in the actual environment, and that the process has the capacity to support production quantities at a consistent quality level. PPAP is one of the very significant milestones in the project time plan. The critical path to meet PPAP and the critical path activities from PPAP to production can determine the time plan in the simplest form. In a nutshell, you can view your time plan as what is needed to secure a capable supplier product design, process design, and ultimately process and product validation. If this is achieved, you get your first PPAP parts on time to meet production.

7.3.2 International Material Data System The International Material Data System (IMDS) is a computer-based material data system used and funded primarily by automotive OEMs (original equipment manufacturers of cars, trucks, heavy vehicles, agricultural equipment, construction equipment, industrial equipment, military vehicles, and other apparatus). Manufacturers use the IMDS to manage best practices related to environmental responsibility. The IMDS (International Material Data System) is the automobile industry's material data system. Initially, it was a joint development of Audi, BMW, Daimler, HP, Ford, Opel, Porsche, VW and Volvo. Further manufacturers have meanwhile joined the community and IMDS has become a global standard used by almost all the global OEMs. In IMDS, all materials used for automobile manufacturing are collected, maintained, analyzed and archived. Using the IMDS, it is possible to meet the obligations placed on automobile manufacturers, and thus on their suppliers, by national and international standards, laws and regulations [7-3].

7.3.2.1 How is it performed or why is it value added? Sustainability strategy begins by the material reporting using a Bill of Materials (BOM). Each of the components (printed circuit board, solder, resistors, etc.) is broken down to its subcomponents. As an example, the terminal used in a connector is made up of a copper alloy

and a plating material. Once BOM is drilled down to the lowest level of the component, the base materials are detailed. As an example, the copper alloy may be composed of cobalt, copper, iron, magnesium, manganese, nickel, phosphorus, tin, zinc, and other miscellaneous metals. Additionally, each material would have to be broken down by its weight and percentage of the copper alloy of a terminal. A tolerance would also have to be provided for each material. Using the IMDS database, the company can review the sustainable materials used for the product and also flag if the materials are coming from “restricted” geographic zones.

7.3.2.2 Why IMDS? (2012 figures: 193,229 users registered from 97,088 companies) As the supply chain is made up of international companies, the IMDS facilitates the understanding of each other's material information and provides critical information on “conflicting material,” parts from a certain region that should not be accepted, gray list materials, and ecological impact of the product. This database is continuously updated; therefore, it is important and is in the interest of all value-creating-chain members that complete disclosure of appropriate data sheets be made to the IMDS.

IMDS is directly connected to Dodd-Frank Wall Street Reform and Consumer Protection Act passed in 2010. This act restricts the use of materials that originate from sources that contaminate the environment. Social responsibility is important for engagement and connection to the worldwide community.

Benefits of the IMDS include the following: IMDS is free. Data for a product can be assembled from suppliers by direct loading from MDS. It can also be manually loaded from the other formats from which suppliers may choose to share data. Detailed database tools for analysis. Database references many of the global rules and regulations. IMDS Material Data Sheets (MDS) are expected to be correct and maintained. Serious legal

and financial repercussions can occur if a company is found not to be in material compliance by a government or regulatory agency. IMDS may help with identifying materials defined in U.S. Conflict Minerals Law. By using the IMDS database, the company can select to keep proprietary information confidential and share details on materials. The cost to maintain, store, and assemble such a database at a global level could be huge; IMDS provides a unique opportunity for OEMs to work together on global regulations and environmental laws.

7.4 Transition from Project to Operations The list of new parts, outgoing parts, or cancelled parts, as well as carry-over parts, should be reviewed throughout the project. With the use of one document, the project manager should be able to analyze the risk to the project during ramp up and early production. Based on the list of new parts is a list of materials or parts that need special handling (safety critical, legal, expensive, or complex parts), parts that have a long lead time, critical or key parts, and parts that historically have had quality issues. With the early analysis of the document, the operation manager should be able to kick off multiple activities related specifically to production. Material flow of each of these parts should be reviewed by the project team. The supplier quality assurance and purchasing organizations play an important role in how the material should be handled inside and outside the plant. For example, how should the fuel sensor be stored—horizontally or vertically? Does it impact the calibration if stored differently? How is it transported to the plant and within the plant? Manufacturing investment should be systematically reviewed at the concept phase sign off: What are the long-lead-time tools needed at the plant? How are the tools depreciated over the years? Is a plan established for validation of equipment and tools? Is a special permit needed to procure the tools? Does the investment classify as the project cost or does it get distributed to the plant maintainability account? These are some of the topics that should be discussed in the project team, and the project management should get early sign off with the stakeholders. Initial assumptions should be challenged to make the best practical decisions related to heavy investment costs.

7.4.1 How many is too many? Prototype or early builds ramp up and production builds; each of these has a different purpose and caters to a different type of consumer. It is dependent upon the project size, content change in the project, and overall impact to manufacturing. For smaller projects, perhaps a simple virtual build and then one or two test build units should be enough. For a platform project, the game plan is completely different. The impact could be as big as: Layout change in the plant Need of special training for operators, industrial engineers, and auditors. This can also include visual drawings of installation or instructions that are available at workstations Testing or proof of design for special IT application in plant For the project, all the cost associated with ramp up and pre-builds should be recorded. Typically, the early builds have prototype parts that are expensive, and end customers may pay a discounted price to test them.

Building an automobile takes a considerable amount of support from development engineers, buyers, and industrial engineers. The parts procurement task, in itself, is an important endeavor. Managing the resources to support such builds needs good coordination between the line organization and project management.

The ramp-up process does not just test the project content but also validates assembly and service standards, tooling, processes, and production systems. Delivery is likely the first time the project team sees the actual interference (if any) due to another project's content. Other project content would be changes in the product due to other project work, such as a project that alters the shape of the bumper or interior trim options. In this case, interference may not be physical but can include other areas or scopes, even though the various projects should have tested and vetted the individual systems. In a perfectly executed world, these systems would be well thought out, planned, and coordinated, and would result in no adverse impact between the project content. However, in the real world, at one point, several projects are being executed worldwide, and quite likely, there will be a surprise. The coordinated project's content should also be tested in early builds and validated on the physical units to capture any interference before the ramp up. Different offerings or options are featured on the base automotive unit (customers are not homogeneous and have different priorities). During the validation phase, it is nearly certain that not all of the combinations were tested, either due to cost or timing.

Ramp up therefore serves as an important step, as it provides the team with the first look at what is likely rare product content, including a variety of combinations or a mix of options before production. In one snapshot of time, as depicted in Figure 7.5, projects A, B, C, D, and E are progressing with different teams and timelines. The sizes of the circles show the different content of the projects, with projects A and B as the big projects, and C, D, and E as much smaller projects. The dotted line shows the ramp up and the production plan for each project. The two megaprojects ramp up at the same time, and the three smaller projects ramp with a lag, getting into production fairly quickly. It is clear from the picture that the first time all the contents from projects are introduced to the product platform is when the ramp up begins. The plan should be to test various offerings and combinations that were previously unable to be tested to ensure a successful production launch.

Figure 7.5 Multiple projects impacting the single product line.

A classic example of this scenario is when project E is delivering the radio and project A is changing the dash size where the radio fits. If the scope from project A is not accounted for in project E, the supplier develops a radio that does not fit the new dash and, similarly, if project E does not use the space limitation defined by project A, the likelihood of project failure culminating in a major risk to the platform project is significantly increased. Nobody wants an empty space in the dashboard of their brand new car. From the lessons of best practices, validation should be done early in the project phase, and ramp up should reaffirm the earlier conclusions.

7.4.2 Validation Validation at the ramp-up process should be without surprises if enough attention is paid in the early phase of projects. The new standard in the industry is to use virtual manufacturing concepts to validate the design in the early phases of the project, thereby reducing the research and development budget. By using virtual tools, the team saves time in terms of resources and parts procurement. Virtual tools are employed early in the process for the following uses and benefits: Use CAD data or the design module layouts to ensure the design is per specification and meets the manufacturing requirements by creating accurate design documentation Evaluate product manufacturability at the very early stage of concept selection Reduce cost during product design process by eliminating the need for building physical automotive units Use virtual ergonomic validation to verify that the process solution is acceptable The methods build is the initial build that is generally developed to check the functionality at the system level. It provides a good opportunity for Industrial Engineering to see physical parts and make sure the installations and manufacturing ergonomics requirements for the project are met. The following are some of the things to watch for: Where is the study done? In the plant facility, look at the proximity to the plant or engineering facility. The main idea is that the audience for the build is to provide the feedback loop to the project on time to make necessary design alterations. A cross-functional team should review the methods built either online or remotely. How is the vehicle assembled? Is the assembly for the complete system or subsystem? Sometimes, the method is only for the subsystem, and that could be based on the project content. Proper documentation is needed on what is covered as the part of study and what the risk is if the specification is not based on the project content. What level of parts is used? Are the parts early prototypes from the supplier, PPAP parts, or a prototype from a third-party supplier simply to review the design? By performing a quality audit on industrialization builds, the team can access the success of the early builds and design intent. There is also a need to establish the quantitative risk to the overall project for each of the issues found. If the ergonomics facets are reviewed, a determination should be made on how huge those issues are to fix and, if they cannot be fixed, if there is an implication of customer acceptance.

Building an automobile takes a considerable amount of hand holding of engineers, buyers, and IEs (industrial engineers) to build the units online. The parts procurement task, in itself, is an important endeavor, and managing the resources to support such builds needs good coordination between the line organization and project management. One missing installation drawing can stop the build.

7.4.3 Software Handling The process for handling software is slightly different than for hardware, but it should have the same attention to material handling as any other component on the vehicle. Is your supplier certified? To ask this question now is too late. Software parts should be verified and validated before the system is launched into production. This should be done at the complete system level and not only at the component level. In the plant, after the software is released, the complete process should be tested at early build for software download, and ultimately at endof-the-line testing, with zero active or inactive fault codes.

Who would want to drive a car if the software controlling the whole vehicle is an early revision that is partially tested at the subsystem level? Also, keep track of how much money is spent each year by the company for software updates and complaints regarding the vehicle performance.

7.4.4 Communication Plan The project manager should establish a process to support pre-builds and ramp up. The line organization and project management should participate in early build meetings to support the manufacturing team. The process of communication is critical because during this phase product launch is imminent, and the production deadline is right around the corner, so we need to ensure that the proper corrective actions are placed quickly. Because Tier 1 or 2 suppliers may also be impacted, good coordination is required between purchasing, supplier quality, and engineering if a deviation is needed for the production phase. For the successful ramp-up process, build meetings should cover the following: Build specification of the vehicles with agreed slots

Discussion on support needed from engineering Parts procurement discussion to ensure appropriate materials are secured on time What is needed to build the vehicle—parts, working instructions, software, installation drawings, and permits needed, if any Logistics on where the final vehicle needs to be audited and repaired Final delivery of the vehicle after the corrective action is in place To establish the best practices, a process should be agreed upon for reporting issues to the project management team. Short daily meetings should take place to update and work on corrective actions on the build issues. The severity of the issues should determine if the project should halt all the activities or continue with the production plan. An agreement should be made within the project management team to fix the issues prior to production, or if a deviation is needed, that deviation should be endorsed by the steering committee, with full analysis on customer impact. Ramp up to production is usually a very stressful period, and each of the open issues should be analyzed for the cost and quality impact to the end customer. All projects are at risk when too many changes happen on the production line. However, given the governmental mandate for the legal projects, there can be considerably greater risk as we cannot delay the product introduction (think vehicle exhaust emission projects that have a hard deadline). It is advisable to freeze the other changes, until the legal requirements are met and full attention and priority can be given for timely resolution of the issues. As soon as the legal project starts to enter into prototype builds, all the other projects should freeze to avoid making changes to the platform to have a smooth introduction to the market.

7.4.5 Measurement of Ramp Up Key performance indicators (KPIs) should be established to capture problems as well as successes of the product introduction. A clear understanding is needed of each of these KPI measures and its effect on production. Severity classification must be addressed per the company's policy to help prioritize the activities and resource allocation.

If the problem is poor fuel efficiency vs. engine shutdown during driving, which issues should be classified as severe?

The following are some key measurements that help clarify the production capability and allow adjusting or reacting accordingly. Control charts: Control charts are used to understand product variations. Details are explained in chapter 4. Fault frequency: For the automotive industry, fault frequency is an important measure that directly relates to customer satisfaction. Fault frequency is defined as the number of faults measured for time or kilometers of the vehicle runs. Fault frequency number tells the team about the product quality over a certain time or distance. If the fault frequency is high, it immediately flags possible downtime for the customers. Efficiency: In the ramp-up phase, efficiency is measured on how the plant uses new tools or the process to implement the changes. Ultimately, the goal should be to reduce the complex workload areas by either realignment of process, training, etc. Warranty repairs in the first six months: This is rather unique and measures the quality cost after the start of production. The project may be closed, but the line organization is often responsible for measuring and publishing warranty information to establish longterm plans to resolve quality issues in the project portfolio. Safety recalls on the full portfolio as well as payment involving the campaigns give the overall perception of the quality of the product introduced and long-term challenges for the company. A campaign is like a recall, only self-imposed (as in, not influenced by the government). The consequences of the imperfection are not dire or urgent and are often addressed in the normal maintenance of the vehicle by the dealership.

7.5 Transition from Prototype to Production The automotive industry is quite different from any other industry when it comes to ramping up the product to mass production. For a successful and good-quality launch, it is essential that suppliers (Tier 1 and 2 included) are on board, and they ramp up their product manufacturing earlier than actual vehicle production. Software suppliers should also have the same deadlines and requirements to meet as hardware suppliers. There is a noticeable tendency of staggered software deliveries resulting in lower readiness for production. The vehicle is a collection of subsystems that require updating in a controlled and cohesive manner, not ad hoc and piecemeal. In most cases, the staggered deliveries send the wrong signal to the market, and eventually the company ends up spending more money in service campaigns or recalls. Here is a checklist for successful ramp up in a nutshell: All the development work is completed, including the corrective actions on early-build vehicles

Supplier has implemented the changes based on the new or corrected design Supplier starts seeing the forecast of the materials electronically Suppliers with cancelled parts should no longer see the forecast. This is one step that is missed many times, and the company has to write off the wasted materials Training for material handling, process, and software handling is complete End of production line test established; quality audits established at the production line Aftermarket solution defined and is in line with the project management strategy. This should include manuals, tools, and KPIs for vehicle uptime and maintainability Tools in place to order automotive units, which include sales tools and commercial documents

7.6 Supply Chain Decisions The decision to manufacture the product is made outside the project and is one of the vital factors determining manufacturing cost. Even if the final product is assembled in one region, more than 3000 parts used to assemble the vehicle could come from all over the globe and should be captured in the operational matrix. Smaller projects, such as adding or replacing a few parts, can have an important role when it comes to managing the logistics of the Tier 1 supplier. For example, in the case of the project to change the fuel tank, the supply chain is limited to securing the right quantity of parts at the right time. If the project is a platform project, which makes significant changes to the complete product, such as introducing a hybrid car, the supply chain decision becomes very significant and complex. Off-shore production—does it make a difference? Many parameters change if the production is done off site. In too many cases, the decision is made outside the project but has an impact on the successful launch of the product. Most companies use the discounted cash flow (DCF) model to make the decisions and do not consider the real transfer value [7-4]. A couple items to be considered under the transfer cost are the training cost and the ability to manage the site as if it were located in the company's backyard. This could be as simple as training supervisors or quality auditors according to the company's policy or as massive as putting control charts at each station, which could be monitored remotely in real time. The

ease or complexity of managing the production issue in the event of an operational problem is another important aspect of transfer cost. This also accounts for how quickly the corrective action can be taken to fix the problem and actually be implemented.

7.7 Environmental Impact Many companies take pride in an environment friendly approach by certifying for ISO 14000 and committing to zero landfill. Important facets are: Where does the material originate? Is your entire supplier base quality certified? How does the material get transferred to the production line? How much material is wasted in handling? Waste and efficiency should be measured as part of product introduction. Can the packaging be reused? Packaging also encompasses how the final product is delivered to the customer. To conclude this chapter, the ramp to production is a critical step to ensure a rapid, costeffective launch of a high-quality product. Up-front involvement of manufacturing, logistics, purchasing, and supply chain is critical to ensure that all the partners are on the same page and equally aware of the changes and their roles. With high investment cost in research and development, the decision on effective ramp up is as important as the right concept selection.

References 7-1. Automotive Industry Action Group (AIAG). https://www.aiag.org. Accessed March 2016. 7-2. APQP: Automotive Industry Action Group, Production Part Approval Process (PPAP), Southfield, MI, AIAG 2006, p. 18. 7-3. IMDS Information pages. https://public.mdsystem.com/web/imds-public-pages. Accessed March 2016. 7-4. Martin, Roger. “Rethinking the Decision Factory,” Harvard Business Review, Oct. 2013.

Project Management for Automotive Engineers: A Field Guide Chapter 8: Early Production Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 8 Early Production

“No one can whistle a symphony. It takes a whole orchestra.” —H.E. Luccock

8.1 Tier 1 and Vehicle Operations The project progresses from the initial ramp up volumes to the full production rates. The product and process development activities have culminated, and a factory is ready to mass produce the new product. However, to maintain continuity and allow for effective transfer of knowledge, the project does not conclude with the start of full production at the OEM's production line. For the product introduction, support after launch is needed for a defined period of time, which could include engineering, specific production development talents, quality, sales and other marketing, and aftermarket activities. Support from finance would be required if costs are higher than planned, and procurement personnel (purchasing and supplier quality assurance) may be involved in fixing any production issues or negotiations with suppliers. During the production line verification and ramp up, the manufacturing line, which includes assembly, logistics, paint, subassembly, audit, shipping, etc., had been tested and validated, but at a much smaller rate of production. Even though the manufacturing line has produced product, and those parts have been verified, this stress is not comparable to continuous full-scale production. The line is now producing at the projected volume, in earnest, for the end customer. These parts will ultimately go through the entire OEM process at this production rate, and make it to the final customer vehicle for shipment. Based on the scope of the project, the team needs to have launch support work for either a few weeks or months from the first date of production start. Typically, another group takes over from the project team. This group, which is often called the “current production team,” ensures the timely delivery of high-quality product to the end customer. It would be prudent to have the current production team be involved in the earlier phases so they understand the intricacies and trade-offs that were involved in developing the product that is now manufactured. It is important to ensure that the project team, or subset of the team, will be available to answer questions and help solve problems that may arise in operations, logistics, and aftermarket.

Even with suitable early-phase project involvement on behalf of manufacturing, opportunities arise for unanticipated problems to be discovered during the launch. A trend toward modular production, wherein the supplier builds and validates subsystems and modules that are then shipped to the OEM factory, is growing. For example, an entire dash can be populated with instrument cluster and switches. This assembly is installed in the vehicle, often line sequenced. Line sequenced means that the build is known well ahead of time, and the supplier ships the part exactly as designed for that specific vehicle. This reduces the subassembly handling and subassembly installation time at the OEM factory and increases throughput, reduces cost, and improves load balancing. However, to take the biggest advantage of this requires line sequencing, which means a stable, well-known production volume and variant combination of vehicle options. As most suppliers use low-cost manufacturing sites (for example, Mexico), this cost benefit is then transferred to the OEM. This approach is not free of issues: SPC of the supplier and potentially 100% end-of-line testing at the supplier of critical components may be required. Although not an optimum solution, this may still be cheaper than working with individual components at the OEM. Any changes in supplier sourcing, location, and equipment will influence the quality of the product, and this effect is often underestimated. The supplier that delivers these subassemblies for installation at the OEM is more logistically connected. Below is the example for Daimler-Chrysler [8-1]. The production of Daimler-Chrysler's “Smart” brand cars in Hambach, France goes one step further by integrating Tier 1 suppliers through conveyor belts, thus eliminating any transport costs. In Volkswagen's commercial vehicle facility in Resende, Brazil, an innovative production concept was developed, which could be a positive example for other production facilities. The suppliers not only deliver the modules, they also assemble them. The production facilities in Hambach and Resende also implement the concept of pay-on-production. Pay-on-production means farming out capital equipment and complete processes to a supplier so the OEM pays per unit and saves tremendous investment costs in its own assembly lines. For example, the Ford Fiesta assembly in Germany is financed, built and run by the supplier Eisenmann as a pay-on-production model. Depending on the different stages of partner integration within car production, it becomes obvious that OEMs can significantly leverage their overall variability since the use of outsourcing transforms fixed costs into variable costs.

The large, centrally located manufacturing lines that are focused on one product line are no longer the only solution to manufacturing. Modular product and manufacturing process designs make it possible to use down times for some products as up times for others. This allows

maintaining the facility capacity at a lower single product capacity and protects the OEMs from risks due to volume erosion. No matter how the product moves through the supply chain, the early production volume will not jump to the total volume or the maximum volume instantly. Often the launch starts a little early and with smaller volumes built per unit time. The introduction of the product, for example, may be on the high- or low-end feature content vehicle, or of a low-ordered variation of the vehicle, or a mild ramp up to the new model year production. In that way, the OEM production line personnel gain time to become familiar with the production and integration of the parts to the vehicle. Additionally, the previously unforeseen instances may come to light without the heavy stress of resolving full production and the impact consequences. The latency in time from production of the vehicle to sale to the final customer can cause the project considerable consternation and exacerbate any technical issues. Unlike cost and delivery date, feedback on the product quality (especially reliability) takes time and comes in fits and spurts from the customer. Typically, when the dealer gets the new product, issues such as flaking of paint, incorrect operation of lights, etc. may be found quickly, but it takes some time before real performance- or safety-related issues can be detected. This is not the time for prematurely congratulating the team or patting of backs. Just because the product is delivered through the OEM's production does not mean the quality of the product is where it should be. Did the team have all of the time needed for the project? Did something seemingly innocuous get missed? It is all but certain that not all variations and permutations of the product have been understood, tested, and accounted for, although the goal should be to do so. Consider the logistical chain of delivery to the customer, as shown in Figure 8.1.

Figure 8.1 Logistics associated for delivering end units to customers.

From the time the first parts arrive at the OEM's door until the time the parts are assembled as a vehicle, sent to the dealership, and purchased and used by the customer, considerable time might go by. In some cases, dealers have the products in inventory for six months. In other words, the units are not immediately commissioned, and the product sits on the lot for a while. Not hearing of problems in the first few weeks or months of the product launch does not indicate there are no problems. As the volume of vehicles built by the OEM grows and vehicles in inventory grow, so too do the monetary consequences for any would be corrective action. This makes it all the more important that the team exercises appropriate levels of diligence prior to vehicles shipping. These types of risks should have response plans that are appropriate for the situation.

8.2 Export Vehicles In some instances, the production facility will build portions of the vehicle and then ship the vehicles to their final destination, where additional parts and features or modifications are applied. These are sometimes referred to as gliders, as often the driveline is one of the elements missing and the vehicle is pushed around. For example, these vehicles can be sent to electric vehicle manufacturers where the electrified drive line is installed. With these kits, a fraction of the assembly is performed at a facility in one location, perhaps another country, and then shipped to another destination or country where the final assembly is completed. Sometimes these alterations are not part of the base project but will be an entirely separate activity. The only connection may be in the setup of the OEM manufacturing facility where the

product is partially assembled. In these instances, the complete packaging work may be handled in another separate project or part of operations. Occasionally, the logistical challenges associated with building these vehicles will be a constraint upon the project. Uncovering stakeholder expectations and the implications therein at the start of the project as a vetting of the scope, even to the product launch, are necessary for success. In some cases, the cost is widely and wildly misunderstood for such glider units. Costs are associated with parts, real estate, shipping, support, documentation, marketing, and warranty. As with any project, an incomplete picture of the cost and business case will become a project headache, and the project manager will struggle to support the logistics and technical solution. One other important manufacturing area is how these parts are assembled in the facility. In most cases, these units skip work stations, and hence may cause overall inefficiency or disruption in the manufacturing line.

8.2.1 Exports to Countries with Regional Regulation The project may have to contend with securing local production content for a vehicle produced globally. Consider, for example, vehicles exported to Brazil. To sell a price-competitive vehicle in Brazil, 65% of the content of the vehicle must be locally sourced [8-2]. If the local content is less than this level, the Brazilian government will place a high tariff on the product, which reduces competitive attractiveness of the final product. Significant numbers of suppliers of those production parts must have facilities in Brazil to be able to sell parts for these vehicles, or suitable local replacement parts must be identified. OEMs coordinate parts for the entire vehicle, and therefore they can more easily discern what percentage makes the best sense to source from within Brazil. Figure 8.2 represents the complexity and variations that exist for automotive assembly. New regulations impacting the supply chain will reduce the probability of success.

Figure 8.2 Complexity of parts coming together in supply chain [8-3].

The Tier 1 suppliers will not likely be in much of a position to decide what portion of the vehicle is to be sourced from within the country and what is sourced globally. This decision will likely also have implications in the supplier selection process and the strategy selection for the project team. Suppliers can be selected based upon the ability to source the parts locally (in this case, source Brazilian parts locally). Sometimes a supplier must work to develop a local sourcing strategy and structure in the locale (e.g., have global parts produced at a build-to-print manufacturing site local to Brazil). The more dispersed responsibility and addition of this type of constraint and scope on the project, the more complicated the project will be, and the less likely that it will succeed. These decisions must be well thought out throughout the project and product life cycle. Selecting a supplier that does not readily have the ability of local production (in this case local to Brazil) will present the project with additional risk due to timing the development of the manufacturing line with the local start of production. Additional risks will also be associated with the material logistics. While the world is smaller from a communications perspective, the longer the logistics chain, the more opportunities there are for supply chain disruption.

8.3 Prediction of Product Production Quality (OEM and Tier 1) Much of the work before the launch should have provided the project team with an understanding of the quality of the part at production. The more thorough the team was in that up-front work (testing, evaluations, and inspections), the stronger the sense of certainty regarding the product. All the verification and validation activities provide a glimpse of the product's capability and limitations, assuming the scope of the test work is valid and attention has been given to key metrics—not manipulated to tell a story other than the facts. Depending upon the variation of product application offered in the final product to the customer, perhaps the verification and testing activities will not address some often small and very specific combination of vehicle variations and vehicle application. For some vehicles, it is not possible to test every permutation and iteration of the vehicle, and the more variation in the vehicle, the less likely testing is conclusive. During the launch, focus should be on those combinations that may not have been a significant part of the earlier rigor.

8.4 Impact of Customization For many vehicles with a variety of options, a multitude of permutations and variations in the final product make testing all incarnations of the system impossible. The more variation in the product, such as building a highly customized product, the greater the risk that the product testing may not have included all the versions or permutations of the product produced. Consider the impact of customization in the automotive industry, studied by IBM Business Consulting Services [8-1]:

Consumers no longer accept standardized products, but want products that satisfy their individual requirements. Target groups thus have to be downsized by companies so consumers will be attracted by the products offered. However, because of the increased global competition with a stronger focus on price and not on brand loyalty, consumers generally do not reward companies for their more individualized products.

Part of the product and process development must have taken into consideration the organization's customer objectives and approach via product customization. Evidence of adverse impact on the product should be sought out early on and continue during the early production phases. The team will have to determine response personnel and corrective actions. During the custom build process, a significant area of concern, or risk, can be the lack of documentation and correct bill of materials for the vehicle. In such a case, supporting these vehicles through warranty becomes a burden for the company, often due to insufficient clarity of scope and impact of the variation.

The overhead cost to maintain custom units should be understood in the unit cost of the vehicles. The company must understand the costs and risks associated with maintaining these vehicles in the portfolio, and may also keep a separate standing group to support these vehicles.

8.5 Statistical Process Control for Tier 1 and OEM Part of the product and process development will have included measurement systems analysis of the Tier 1 and Tier 2 suppliers. This was done to understand and record the overall process performance and product quality at end of the line of these suppliers. These activities will also occur at the OEM manufacturing facility. All of the parts are monitored through SPC. Thus, the overall product quality will be better known. In case of issues at Tier 1 and Tier 2, the impact upon the vehicle will have a cascading effect. The sum of the nonconformance in this chain will impact the end quality of the product and product delivery efficiency. These nonconformities represent waste in the supply chain. This waste can become a serious cost that the OEM will have to bear and attempt to recover through the piece price, or perhaps the contractual agreements with the suppliers will provide via vendor recovery. Vendor recovery can be a contractual penalty for failure to perform per contract. A close partnership with suppliers, developing communications channels, and transparency and willingness to show

control charts, can make it possible to understand the quality of the product throughout the product chain, providing the OEM with a quality product and minimal waste.

8.6 OEM Sampling Strategies (Inspections) Plenty of inspections will occur along the supply chain, including at the OEM. Technology has made it possible to accomplish more with less. Cheap cameras and computers make automation more effective, as computers and cameras do not suffer from fatigue. Additionally, inefficiencies due to human elements, fallibility and repeatability, are greatly reduced. Cameras do not get tired eyes, for example; but, on the other hand, they lack intelligence and are only as good as their algorithm and the software and hardware limits. Inspection will be done at the end of the line or even at the subassembly station to ascertain quality, dimensional, and aesthetics attributes. Many OEMs have an end-of-line check out of the vehicle that consists of driver interactions with the vehicle. The results of these tests are recorded via camera and computer and saved to be traceable at a later date. The process will likely include putting the vehicle on the dynamometer and recording the results of a variety of exercises to which the vehicle is subjected. Functions such as stopping distance, acceleration and torque, and the sounds that emanate from this exercise, are checked out. In addition, there may be external inspections, door and trunk closing tests, and other mechanical exercises of the vehicle. Vehicles that fail to pass these tests will be moved off the line to a rework station. In the early launch phases, this may require the project team member's expertise to assist in the resolution if these problems are not simply part of new production. This may not seem very project related; however, that notion could not be further from the truth. The project deliveries must fit within this context and the systems that are already in place, unless otherwise stipulated at the start of (or throughout) the project. This means that any new features or functions added to the vehicle as a result of the project must not adversely affect the existing system, including the production systems. Additionally, the deliveries from the project to the production line may require alterations at the plant in the inspection approach or perhaps philosophy, resulting in alteration of the production line. The expertise in the product is largely in the product development and project personnel at launch. Disseminating that product knowledge where needed in the organization is part of knowledge management and, at least in part, project management.

8.7 Missing Hardware Strategy Transitioning from prototype parts and small production volumes to full-scale volumes can present challenges, one of which is the electronic data management (EDM) ordering systems, also called electronic data interchange (EDI). Last-minute part or volume changes can play havoc with supplier logistics. It is best to avoid these situations. However, if unavoidable, these scenarios will require close attention just to ensure that the parts arrive at the OEM's

facility in time for production. This is not the only impediment; a number of issues with material or the logistics around the material may compromise the production process. Consider the consequences of west coast United States port closure to cargo vessels on production lines that run lean (or just-in-time manufacturing). The method of response is generally to have express shipped parts. Parts can be shipped directly to the local airport. This is not so difficult, but it is costly. However, when the parts originate outside the country of the OEM, custom's logistics then become a significant risk, and the cost is greatly increased. Getting parts through customs may increase the time to the point where the manufacturing line will have no parts available for the end product. For parts that cannot be expedited, one of the few remaining options is to choose to build as much of the vehicle as possible, or not build anything and shut the plant down. In the instance of build what can be built, the vehicle will perhaps be towed off the end of the line and moved to a place of containment. Either of these two situations is catastrophic and can happen well after the project has been closed. However, while the project is active, the team, and especially the project manager, may have to be a part of developing a solution.

8.8 Labels, Certifications, and Manuals Creating or updating labels, certifications, and manuals may seem like an effort that can be delayed to the end of the project, but this is not the case. Certifications require evidence or proof of achieving the objective of the certification. This work goes hand in hand with the product and process development, especially because the evidence is typically test results and other documentation. Additionally, it is a risk to the project in discovering late that the certification objective has not been achieved and no more time is available to meet the demands. It is important to keep the project team, the certification sanctioning body, and associated stakeholders in close contact and in periodic review of key metrics that illustrate progress. In many cases, labels will have to undergo verification activities. As an example, consider the bar code for a particular part that will be used by the OEM. The OEM will scan the bar code as part of the vehicle assembly process. That bar code will likely have to withstand topical contamination from the fluids to which it may be exposed. For instance, the brake fluid should not smear the bar code in such a way that the bar code reader cannot read it. This may seem trivial, but with line sequenced products (parts matching a specific build), this label is integral to matching specific parts to a particular vehicle build. Vehicle manuals are based in part on the engineering functional and performance specifications. As the product or system is developed, so too are the manuals for the product. That includes manuals for replacing parts that will eventually become documentation with which the service departments at dealers will use to troubleshoot and repair the vehicle. These

documents will define standard repair processes and time allocated. Today, these are digital representations of the paper books from the past and may actually be a searchable database to which dealers have access. When the manuals are digital, more time is available for the delivery because no hard material shipping is involved. Typically, manuals are updated by visiting a website. The customer manuals are a different story, as these are physical books that go with the vehicle at production. There also will be a point in time for educating the dealership sales staff, who will present the product to the customer. This will need to happen before the vehicles are available for sale and, therefore, the manuals must be available before sale as well.

8.9 Post-Vehicle Launch Activities Before the launch phase, key personnel are identified that may be needed during the production, and their availability is secured over a defined range of times and dates. For example, key expertise may provide technical support for a variety of the preproduction and early production areas. Consider the engineers that designed how the wire harness is routed throughout and clipped (strain relieved) throughout the vehicle. This may include troubleshooting what was not discovered during the earlier phases of the project.

8.10 Vehicle and Part Field Failure Recovery The project may be concluded before the final product makes it to the customer (see the earlier discussion on the logistics related to end customer purchase and use). The logistics of vehicle delivery may mean that the vehicle makes it to the customer months after the start of production. This leads to one of the biggest conundrums of automotive project management. There may be yet undiscovered and unexpected problems with the product quality that are not clearly understood until the volume of parts and customer use reach a certain threshold and become known. Therefore, any reports of errant product should be aggressively pursued to learn about these failed products as quickly as possible in an attempt to ascertain and reduce the risk exposure. Failures within the warranty period are especially of concern. Earlier product development (project management) work, including the testing and verification activities, should have been linked to the product use and desired (expected) life of the product. Any early failing parts will be recovered to perform a failure analysis on the part. This usually happens by sending parts back to the supplying organization for a review of the failure. For this to work, it is essential for the project manager to make sure these material handling and feedback loops are identified and committed. This may not end up being a project management function to address, because the project may be closed by the time parts fail. Additionally, an organization will likely have identified processes and personnel to aid in addressing the failure. However, even if the organization has established processes for this activity, the project manager will need to identify the transition and key personnel or departments. For suppliers, much of this will be contained in the contractual agreements, so the actual work may fall more to a company's purchasing or procurement department. Additionally, the supplier quality assurance (SQA) portion of the organization and the material handling aspects of the company will likely have some responsibility. Similar to all the earlier work, it is important to identify the people and the roles they will play in achieving the objective, even at this late phase of the project. Contracts may include clauses in which an expected not-to-exceed failure rate is identified. This failure rate may also include what is often called zero mile (or zero kilometer) failure, or in-plant failure during installation. Any parts that fail within the plant will often have strict procedures for handling to ensure that the symptom and the specific part are traceable. The part is then shipped either to an outside entity, or more commonly, to the supplier, to determine the technical cause of the failure. The supplier may wish to periodically review the OEM manufacturing line to witness the handling of the product through production. This request may be part of the supplier's way of working, or it may originate from the volume of returned parts. The supplier may wish to review the production line to eliminate any concerns of handling corrupting the quality of the

product. Consider, for example, instrument clusters with cracked glass in the manufacturing facility. The supplier's end-of-line testing of the product would have caught such an egregious error with their cameras. The plant personnel, not knowing how the supplier checked the product prior to shipping, believed the quality problem to be a function of the supplier's product manufacturing. Upon review, it was the handling and shipping of the part, internal to the production facility, which was the origin of the cracked glass. OEMs will begin submitting charge back to their Tier 1 suppliers if quality thresholds are “breached.” The implications for the OEMs are that: An early warning detection system is needed to identify quality problems much earlier in the process so that critical factors can be corrected before the issue impacts the overall quality scorecard. Improved techniques to identify root causes are needed to positively determine whether their part is the culprit. Many companies use Excel™ and other manual analysis tools in an attempt to spot emerging complications, but simplistic approaches do not provide the advanced notice that a supplier needs to rapidly identify and fix problems. The solution is not more data. The solution is to better leverage the data to detect patterns earlier in the process, and then rapidly identify the root cause and correct the process. Early in the sourcing process, the contracts should be designed to clearly cover the responsibilities of the OEM and suppliers to enable execution of responses such as those covered here, where applicable.

8.11 Transition from Project to Customer Service Group Part of our project closing is to conclude by moving the product to operations, and a significant portion of that operation is the service group. The service group will have been part of the product development from the very beginning, informing the team in decisions that influenced or impacted their area of responsibility. Any special tools or techniques that were needed would have been noted and developed. Service personnel would have been involved in how the design is serviceable, or maintained, in the case where maintenance of the product is required. The service group is responsible for the standard repair times. These are generated by using early prototype and production vehicles as the source for part replacement. The service group will have considerable responsibility in the maintenance of the product. Some of the areas planned for and now coming to fruition from the service group are: Repair, replacement and maintenance methods Service documentation and processes

Repair times Tools Customer problem response (time) Warranty exceptions

8.11.1 Maintenance At a point, the project must end. This end date may be somewhat arbitrary, as in a finite duration after start of production such as three to six months. The date may be somewhat empirical based upon a metric such as volume of parts shipped, or even perhaps the achievement of certain objectives including quality targets (metric based). At any rate, the project plans are made and development progresses toward the transition from the project performing the work to the product being produced and maintained by the line organization.

8.11.2 Vehicle Documentation One of the major components of the hand over to operations is the documentation of the product, which includes the aforementioned service documentation. However, in this case we are referring to the customer documentation and manuals. As the product development and production processes progress, a clearer understanding of the product is known. This clearer understanding is translated into vehicle documentation and marketing material. This material will end up in the vehicle, on line, at dealerships and marketing events, and at service centers.

8.11.3 Other Key Performance Indicators In plant warranty, tracking is of interest as the project departs the scene and operations take over. Contractual obligations are frequently, if not always, existing with the Tier 1 suppliers. The end-of-line yield is similar to the first-pass yield at the supplier and is a measure of the ability of the production facilities to repeatedly make a working product. That is, how many and what percentage of vehicles leaving the OEM production line do not require rework. It is important to firmly establish these KPIs and the method of measurement early in the project. Experience suggests that finding the appropriate measurement and gathering the data to assess capability is a nontrivial task. Combine this with self-preservation mechanisms, human nature, and the “information” that can be inaccurately collected, inaccurately reported, or inaccurately interpreted. Any problems that are due to the project implementation will be subject for negotiation for resolution as the project works to transition from a project to deliver the

product to the operations to maintain the product.

8.11.4 Time Dependent If metrics are not used for the transition from project to operations, an arbitrary date can be employed (e.g., six months). The transition responsibility can be a source of difficulty, because over time, the line organization will take more responsibility for how things work. Any problems found in this transition to production are often tossed between both entities as root cause and responsibility, project or operations, and will be debated or negotiated until a final solution is found. Root cause analysis tools, such as the 5-Why, 8D, and A3 techniques, can be helpful.

References 8-1. Gallasch, Andreas, Grafe, Jörg, Hans, René, and Salter, Brian Neil. “Challenges for the automotive industry in an on demand environment: Seven areas of strategic action,” IBM Business Consulting Services, 2004, ftp://ftp.software.ibm.com/software/plm/de/challenges_automotive.pdf, Accessed July 9, 2014. 8-2. “Brazil,” United States Trade Representative, http://www.ustr.gov/sites/default/files/2013%20NTE%20Brazil%20Final.pdf, Accessed 6/30/2014. 8-3. “Lakes and Rivers: A Middle Class Task Force Visit to the Chrysler Toledo Assembly Complex,” The White House. Image adapted from https://www.whitehouse.gov/blog/2010/08/23/lakes-and-rivers-a-middle-class-task-forcevisit-chrysler-toledo-assembly-complex-1, Accessed 5/20/2015.

Project Management for Automotive Engineers: A Field Guide Chapter 9: Project Closure and Something More Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 9 Project Closure and Something More

“There is an end to everything, to good things as well.” —Geoffrey Chaucer

9.1 End of the Game By definition, a project must have an end point or come to a conclusion. This is the time to ramp down and close out the project activities and assess the project performance in meeting targets of scope, time, features, and cost. It is also the time to celebrate the roller-coaster ride that was the project life cycle. Often, the celebration is downplayed or outright skipped as the team is disbanded or reassigned to new projects. Before accepting a new project, take a moment to acknowledge the work and sacrifices the team has made to reach the end of the project. Review the fruit of the team's labor; maybe visit a customer/dealer to get some feedback on your product. It is important to reward the project team and other professionals who played a pivotal role in the project execution and support. A sense of accomplishment can create a good closure and provide team spirit for the next project. In some cases, teams are fragmented with various people supporting the project from different parts of world; as a project manager, take time to thank each team member for their specific contribution to the project execution and results. The project closure is as important as the kickoff meeting, and the team should feel a sense of pride in its accomplishment before moving on to the next project. It helps establish confidence in the team for future projects and strengthen the core values for the company. What happens at project closure? User Acceptance: Stakeholders should accept the deliverable or the deviation, and documents should be signed off by clients. This includes the list of change requests that invariably result from the work. In the automotive world, acceptance could be as simple as agreement over the features demonstrated in a few automotive units or as complex as complete review of performance of the units over a few months with production failure rates defined. Transfer of Ownership: Product development engineering will transfer the product to the

maintenance engineering organization, which takes full responsibility for the product design and for future modifications. If there is no maintenance engineering, the product responsibility will be transferred solely to production. Any subsequent product changes will necessitate another project team formation to deliver. The supplier quality, logistics, and supply chain organizations are fully functional and provide the desired quality of product in a timely manner. The manufacturing organization, including the plant and other supporting divisions, takes ownership of the day-to-day production and ensures adherence to process and quality standards. The project team stops supporting the production and ensures that an action plan is established for all open items, with a clear responsibility transition to the line organization. Critical operations support processes are identified and documented. Introspection: Lessons learned should be recorded and disseminated with the top-level management, project managers, and team members for any related projects and other stakeholders. Establish a clear plan of action based on the recommendations to improve the long-term goals for the company. The best solution is to have your project team provide continuous feedback along the way, but many companies focus on this review at the end of the project. The next section discusses documenting the lessons learned, which falls under the bigger topic of knowledge management.

9.2 Lessons Learned There are two ways to handle the lessons learned in a project, and both are important. The first one is to document the learning process throughout the project life cycle. This should have happened, at least in part, as an item during each of the phase gate reviews. This method of self-calibration can be used by the project team to monitor the team's progress by using this information as a feedback loop to tailor the project processes to meet the project demands. This method is directly beneficial to the project but should be used cautiously to avoid making too many or too large changes, which can cause confusion. In many instances, the white book is not used as a tool to improve the project deliveries, but it is treated more as a log of what is going wrong, without the follow up required to improve the situation. Experience suggests that this book is seldom reviewed at the start of a project to understand what can go wrong and plan accordingly. In those cases, subsequent projects continue to suffer from the same problems we have had on our previous projects, such as repeatedly burning a hand on the same hot stove, adding no improvement of performance. This lack of exerting of control over the project will result in no recovery or correction loop, and at that point project management becomes “hope management,” and the team continues hobbling along, wasting time and money. The second method is to spend time periodically throughout the project and do a reflection. For

example, split the session into various categories: Planning, Concept, Requirements, Change Management, Suppliers and Interfaces, Verification Process, Organization Structure, and Communication to evoke best practices. This method is subject to the memories of the individuals along with what supporting documentation can be found. Although this review frequently happens after the project is finished, it is more desirable to learn and improve all along the way. Still, having the review at the end is better than not having it at all. Simple tools like the 5-why technique would help uncover the issues, and affinity diagrams can be used to see a pattern for problem areas. The reflection process becomes very stressful in platform projects or for cases in which the project has consumed more than the planned hours. Stress also creeps into legal projects where the project cannot be cancelled, and acting on the lessons learned may not be really possible. Projects that have fixed delivery time constraints and the pressure of a tight schedule delivery continue to do the patch work, seemingly with no time for this review.

The venue for lessons learned review is very important, especially if the review has many organizations participating (think home field advantage). An unconventional meeting structure helps establish good rapport and will erode the appearance of a witch hunt or activity to pin guilt, as well as creates a positive environment for critical feedback.

A failed project or not so successful project is just as important, if not more, to be critically reviewed as the successful ones. The idea is not to find the scapegoat or a guilty party, but to serve as a STOP sign to think and plan changes before the next steps. The input into the white book helps to avoid future missteps via lessons learned—provided these documented lessons are able to be easily recovered by future project managers. The longer the project runs, the more likely there will be organizational changes that may disrupt the project. There could be multiple changes such as introduction of new processes or organizational restructuring. The project manager and the project undertake additional risk in the midst of these types of changes. The white book serves as a guideline for project managers to identify risks early in the project that are based upon historical record. For example, through reviews of the white book, the team may learn that duration estimation is routinely errant or incomplete. Perhaps the team learns that the quality assurance activities are insufficient in the early phases of the product. The white book activity should be periodically updated throughout the project life cycle, and serves as the platform for the project team to discuss open issues and mitigating actions. It should also be seen as an opportunity to fix issues within the team or for the project processes and deliveries to be adjusted. The lessons learned activity also is a good time to reflect on the positive events and outcomes in the project and try to build on it, to learn

what worked and why. This will allow the application to similar situations in the future. To be effective, these evaluation sessions should be handled with care and could benefit from the support of an experienced facilitator. Each “negative comment” should be seen as the opportunity to improve the project and organization with concrete action plans. Open discussion from the participants helps build trust within the team members. Continuous improvement activity should assist the knowledge management initiative within the company. For the best outcome of the lesson learned session, a few pointers are provided: Specific: What went well? What went wrong or poorly? How it can be improved? Who is responsible to initiate and complete the change? Look for some measure of evidence. Although opinion is not to be neglected, specifics and measurements substantiate or clarify different perspectives. Up-front preparation: It is important to get the team pondering and uncovering these areas of improvement before the meeting starts. Category and subcategory outlines can help the team to provide more tangible input in the way of evidence. For example, in the case of product change vs. process after ramp up, topics would include the clarity of the process itself, areas for potential improvement, team efficiency and effectivity, levels of difficulty when it came to working with suppliers, and how well (or not) the implemented solution met cost, features, time, and weight constraint requirements. Environmental changes impacting project: Did issues such as organization changes or new process introduction during the project add complexity to the delivery, or perhaps make the delivery easier? Make sure to note these events and present to the executive management the challenges these changes may have inflicted upon the project. It is also important to make the organization's management aware of the consequences of any new process or organization change. This can help to enable adjustments to future process and organization introductions to be less traumatic on the project work. A new or existing process in one part of the organization can cause confusion in another part of organization. Sometimes the complexity of an existing process makes delivery impossible. Experience suggests that the interactions between departments or suppliers are a significant area of project trauma and failures. Stakeholder disagreement: Is there something that the project team members thought was good but other team members did not agree with? If development engineering took too much time to develop the product, was there sufficient time provided for product or systems testing? Dynamics between different stakeholders is important to be understood for best outcomes from the session. Did the escalation process for the project work as planned?

Premortem [9-1]: Using a premortem approach, the team assumes that the project has failed, and the team members' task is to generate plausible reasons to explain it. This exercise is a form of risk identification. With such a review, the team focuses more on failure discussion than risk analysis; it helps to prioritize those areas of possible failure appropriately and establish an action plan to develop the best possible solution to eliminate or mitigate them. Start the session: The team leader informs the team of the project failure, and team members spend time reflecting upon what could have gone wrong. Because it is all hypothetical, the team can remain honest and predict the future based on the success in the project so far, or on past experiences with similar themed projects. If at the time, the team is struggling with scope, one of the reasons for failure may be scope freeze or lack of it. The scenarios are hypothetical, but risks are very real. Review the input from team members either by placing all ideas on the wall (sticky notes or white board) or reading them out loud. Rank the reason for failure: With the input of the team, rank the failures using probability (likelihood) and severity (impact). Future course of action: Summarize how to predict (what metric) and change the outcome as well as who is responsible for monitoring and follow up. For all the identified changes and action plans, a follow-up plan must be established. This can be done within the project team participants or line management, or the project management office can take responsibility to ensure that the changes make their way into the line organization. An organizational environment that does not encourage speaking up or pointing out problems will have many issues in the effort to achieve continuous improvement. Unwillingness to acknowledge and escalate problems causes the project deliveries to suffer and, at a certain point, the project cannot be revived even by throwing more resources at it or adding money to it. For lessons learned to be beneficial, it is crucial that this activity ends up benefitting this and subsequent projects. Discussing negative lessons learned, real or hypothetical, has the potential to take an energetic, positive team and make it less enthusiastic. This should be managed during lessons learned sessions. Starting and ending the meetings with discussions of positive accomplishments helps to keep a motivated team while applying the lessons learned.

9.3 Knowledge Management So, you finished lessons learned—what do you do next?

An effective knowledge management tool is to build a repository for explicit and implicit knowledge in the organization, not just from the project organization but from outside the project team, to build the knowledge base for the company. Very few organizations manage knowledge as an asset, mostly because it is difficult to manage and measure knowledge transfer. Project management may tend to treat all the human resources (talent) as the same. This is a very a risky assumption. During the project life, there is typically a shuffling of human resources, and this causes dips in productivity. In Figure 9.1, the solid line shows the efficiency in the project team during the early phase of the project, and the dashed line is the efficiency during the development phase. A team is the result of deliberate and consistent actions, and not the result of throwing a group of people together. That is not to say that a team is easy to create. In fact, many aspects go into team creation, all of which are beyond the scope of this book. It is important to note that throwing people at the problem often will not work. In the early phase of the project, it takes the team time to ramp up to reach 70 to 80% of efficiency. Reshuffling of the resources drops the team efficiency; it takes a while before the team can reach (or attain) the optimum performance point. Points A, B, C, D, and E are instances when the human resource is changed, and based on their expertise, and the amount of time it takes for the individual to learn the project and process specifics, the dips are larger or smaller. Points F and G illustrate the dips during the development phase. Some of the drops in efficiency can be drastic to the project, as shown in point G. High turnover in the project should be avoided during concept selection, supplier negotiation, or testing phases.

Figure 9.1 Drop in efficiency due to lack of knowledge management.

Capturing the myriad of experiences the organization experiences over time, and making these available to future projects, is the role of organization's knowledge management. For each change, whether specifically a project encounter such as strategy and risk or resources reshuffling, information needs to be preserved in a practical way. The organization should not learn the same lesson repeatedly. Knowledge management, in the project context, works to retain and disseminate lessons. These lessons can be from the project approach and concern organization-specific or project-specific events and personnel expertise that should be captured to reduce these dips in efficiency and throughput. Each efficiency dip is associated with the time lost and costs incurred. For example, if human resource turnover in a project is high, the company should analyze the cost associated with attrition and turnover rate.

What happens to the curve if the changes in the project team occur during supplier negotiations or concept selection?

Knowledge management is a powerful tool that can trigger process change and integrates action from the many opportunities presented to the organization to learn, including the white book. These triggers are essential elements in refining strategic actions and execution through continuous improvement. Tacit information embedded in the organization becomes more visible with successful knowledge management. This will often include some tools and establishes the network connection between technology, market, and internal strengths of the company.

9.4 Something More The following sections discuss the unique nature of specific projects such as value projects, soft skills for the project manager, and, finally, how to revive a failing project.

9.4.1 Projects to Watch For Megaprojects or platform projects are not usually conventional projects. These projects are complex ones with a host of interfaces, both vehicular and supply based. Therefore, the long- and short-term planning should be handled with appropriate levels of diligence. Statistics from the line functions in the company or industry benchmarks can provide critical information on how many times such projects have cost overruns. The Suez Canal, in Egypt, experienced a 1900% overrun, while Troy and Green Field Railroad, in the United States, had a 900% overrun [9-2]. The point is that one should not expect the numbers provided at the earlier phase of mega projects to be accurate. Wherever

and whenever possible, use quantified ways to estimate the risks of such projects and generate as accurate an estimate as possible. Projects that have no merit, such as: Low profitability products: Some projects show a clear trend of decreasing profitability as the project moves from one phase to another as project and material costs steadily increase. However, there will be sponsors holding the project manager on a tight rope for the project delivery. Escalation with the facts is the best tool in this case, so a rational decision can be made. Poorly aligned project or product strategy between different stakeholders is another source of failure. Such projects are heavily dependent on other projects for delivery. Establish a complete business case of the product portfolio to show gaps in the strategy and investment risk. Pet (strategic) projects: Every company has one of those pet or strategic projects that, even though the endeavor looks bad for payback and accounts, there is a strong push from executives to deliver. As time goes on, sunk cost keeps increasing and eventually, the project manager is requested to put all the money on a horse with three legs hoping it would win. Stay away from those horses! Poorly matched strategy to objective is another significant source of failure, experience indicates. A lack of prioritization of the objective and selecting a strategy that is high risk can be damning for a project. The company will find that many resources, both talent and financial, will be required to make the project “successful.” The project will be over the planned budget and probably late, as the scope is not prioritized—everything is important. Legal project: Project managers have very stringent deliveries and expectations in legal or regulatory projects of a country. The team should perform a recurring risk assessment for any addition or alteration of scope (strong connection to configuration management) to such projects, even though it might seem small or beneficial to the customers. Any regulatory project should have one simple rule: Scope of the project is the driver for the business tomorrow. Any other quality issues or nice-to-have features should be managed via other projects or initiatives. The end goal is to meet the regulatory requirements, not close the factory door at the introduction of the regulation. Consider the consequences of a large heavy vehicle manufacturer's failure to meet emission standards in 2010. Not only did this impact the products that were sold, including penalties, but this also created an environment of uncertainty for the customers. This cost the company hundreds of millions of dollars, and the root cause was the strategy selected to achieve the emissions target objectives.

Organization change or shakedown: An organization may consider internal activities to improve efficiency after a “not so successful” mega project. This can add confusion to the existing projects already underway and can cause unnecessary chaos with roles, responsibility, and processes. This is particularly true for a larger organization, and suddenly “who-does-what” is a mystery that negatively impacts the project organization and team. Change management, including process or organization shakedown, does not necessarily add positive impact or improve efficiency in the short term, and this may just be the thing that pushes a project into a failure mode. Recall the old adage about changing horses in mid-stream. Work with sponsors to minimize the environmental effect on the project execution. Global technology vs. local application: In a global organization, the push can be strong to use different geographical sites for a low-cost and quick-to-market strategy. As a project manager, work closely with knowledge managers and human resource networks within your team to identify the strengths and weaknesses of the different sites as a means of understanding risks. Proper training must be in place before the actual work package transfer, and this can be the difference between success and failure. Local country adaptations are another obstacle of which the project manager and team should be aware. Sometimes a required technology change is significant to meet the project objectives and product requirements. Wrong assumptions (without critique) can cause dire consequences on the project and the product. Value project: Made in XXXXX Multinational companies often take advantage of low-cost business units to develop a part of the solution or a full solution. Another trend is to develop a cheap solution for the lowcost market, resulting in a product that is similar in look but for which the focus is completely on the price of the product. The competition to keep the price low to capture the market share is so intense that cost is the major factor in the project profile. The success factor should be to have a pragmatic approach to both quality and cost. If the quality gets low marks by the customers, the product has a small chance of survival, and the reputation of the company can become tainted, potentially impacting future products. To achieve a low-cost solution, the product development process needs to have a shorter life cycle and should perform with a lean project team. Agile methodologies help to reduce the product development cycle, delivering smaller increments of value in frequent iterations. Instead of design releases for different revisions during the project phase, the project can target smaller development cycles (define, design, test) in quicker iterations. Agile methodologies provide quick feedback for design changes and enable faster development of product from specification to the required functionality. One other important aspect is the collaboration with suppliers. Partnered suppliers should become an integral part of development.

9.4.2 Soft Skills for Project Managers Project managers can find a variety of literature on how to manage time, cost, and scope, but managing the less tangible is a huge part of the project execution. A few key points are listed here: To please or not to please: Project managers have a classic dilemma to please or not to please certain stakeholders and project participants. This includes upper management. From the beginning to the end of the project, the project goes through a multitude of product and process tradeoffs, which often generate emotional responses originating from being very close to the product, project deliveries, or customers. Project managers do not just face the challenge to meet project expectations but also the need to maintain emotional connection to the project; however, limit emotional damage to team members or stakeholders. If the project members perform like a team, it is easier to keep them focused. However, in the case of a highly charged disagreement on technical, commercial, or organization politics, the team meetings can become emotionally energetic, and the project manager will need to de-escalate emotions and keep the momentum on the project execution by aligning the teams quickly. This is critical, because the project manager gets a collection of individuals to work on the project, and these individuals are not a team just because they are assigned to this project. The project manager is responsible for creating an environment that is conducive to team development. Complete focus should remain on the project objectives, although likely not everyone will be pleased with the manner of delivery. It is important to not sugar coat the decisions and the respective consequences. The project manager will need to keep the sponsors and stakeholders involved regarding what is delivered, or when (scope, quality, time, cost), and work toward the best decision and subsequent execution for the company. An energetic personality can have a domino effect on the rest of the team, creating an emotionally charged environment. The project manager needs to be aware of psychological traps: “We have always done it this way”; “Do not question the internal suppliers”; “Trust us”; “It is ok to be late in an early phase of the project.” Power or status quo: Knowing when to challenge the status quo is a skill the successful project manager will need. Asking the right questions can help enlighten the project manager and the team. By questioning the status quo, the project manager is in a better place to deliver a more effective mode of execution and ultimately deliver improved value for the customers. Do not just agree, ask questions. Sunk cost trap: There is always a project that continues to march in spite of a predicted low or no profitability. The argument goes something like this: “It is not possible to kill the project; too much has been invested in it.” As time progresses, the sunk cost increases, and there inevitably becomes a point of zero profitability—forever. This is especially

valid if the project is one of those mentioned pet or “strategic” projects. Penalties may even be severe for making the seemingly harsh decision to kill the project or show unfavorable results. The project manager then has no recourse but to continue by providing information and escalating to those that can effect a change. Until that moment, the project manager must, as best possible, manage using “hope management” to resurrect the project. Sponsors and key stakeholders may also start practicing “hope” by throwing dollars or reshuffling of people to somehow transform the project into a success. Projects are not standard operations; they are unique and uncertain. With uncertainty and risk, there is always a chance of failure no matter how good the concepts are or how well the team executes. With an open and trusting environment, the project team should not be afraid of escalating and getting the company and the project team out of the unprofitable endeavor. In Figure 9.2, it is very clear that, as the time progresses and as activities are completed, the project keeps consuming the allocated project budget. The sunk cost increases over time. In such projects, the profitability also tends to go down, because cost keeps going up; there is a very small area of profitability (shown in the patch). The longer the company delays terminating such a project, the longer the project manager continues to struggle to deliver, and the more that is added to the sunk cost. Profitability shown in the graph is the predicted profitability, and it is never realized because the project never reaches the stage where the actual product is sold, or in some cases, where the project actually delivers. The company never recovers the return of the investment. In the figure, profitability should be assumed as hypothetical.

Figure 9.2 Sunk cost for low profitable project.

Sometimes terminating a dead-end project is very difficult and can take considerable time until the sunk cost becomes as massive as millions of dollars. How many times has your company stopped the project due to low profitability or low probability of achieving the objective?

Reporting defects: How easy is it to report problems? Does the organization fear conflict? Generally, human nature (and some organizations' desire) is to find positive information and deliver only the good news. The project manager then has a difficult task to report defects and issues, and ask for help. A well-defined escalation process for the project is important for success, and for getting executive support for quick problem resolution. Do not underestimate the power of organizational politics to fix or damage the project. How you influence the organization will impact the organization's ability to react to the project needs. Do you have too many mailbox project managers and reactive sponsors? Both of these are dangerous and can have a serious dampening effect. Mailbox project managers are generally new project managers who wait for the inbox to fill and then summarily forward emails, without really contributing to the value of the project. Everything is an escalation event or somebody else's problem to resolve. There is a clear distinction between managing the emails and proactively leading activities to make a difference, which requires team interactions. Ask questions and engage the team in the beginning and throughout the project. Push the team for results by developing metrics and key performance indicators and monitoring with the team's help. Learn from these measurements. Even if the team does not meet these key performance metrics, they informs the project manager that perhaps the objective is too much of a stretch to meet. The role of the steering committee or sponsors can be a difficult one. In fact, this may be more associated with the organizational culture. The project manager cannot change the culture easily or quickly, but recognizing the style of support can help to develop a sound communication strategy. Confrontation is not necessarily bad and can be constructive pressure to uncover a real solution. The project manager needs to maintain a good balance between confrontation and compromise, and know how to not let the confrontation irrevocably damage the players. When you see the bad signs: Pause, look left and right, and then start. Prioritize the problem areas; use a systematic approach every time there is a roadblock. The team needs to assess the complete impact to the product delivery. Has the newly discovered failure in the axle caused impact only to design or to the cost and delivery too? In many instances, the answer is yes, there will be collateral damage or need for the project to create a new plan of action for these areas. Any change in design, in short, pushes the timeline. The failure calls for a pause to understand the reason for failure, and perhaps consider a more rigorous test procedure and possibly additional tests. The project

manager should ponder, prioritize, and address all of the depending implications that will likely require altering the project plan to lead to success.

9.4.3 How to Recover a Failing Project There are times when a project manager inherits a failing project or the project is already in bad shape, and well on the way to failure. The project manager must quickly establish a positive influence on the project. The failing project should be remedied simultaneously in two ways: fix the internal core issues and work on the external support issues. Figure 9.3 shows one such example in which a technical problem in the product creates secondary issues such as parts availability for the customer, and technical and commercial response from the company. The project problems are divided into technical core issues and outside environment with multiple sponsor complaints. A critical issue can arise from anywhere within the project, and in some cases errant information or lack of communication will cause more frustration than the actual problem. Uncovering the true root cause in the midst of the pressure to execute is not easy, especially in an emotionally charged situation.

Figure 9.3 Breakdown of a failing project.

A bad ignition switch can cause serious problems for the customer. That is the core technical problem that should be fixed with highest priority. However, an action plan should be developed to uncover the reasons for the bad ignition switch occurring on the vehicle. Were there communication challenges? Was there sufficient testing, etc.? It is not enough to solve the switch problem; rather, it is important to solve the items that made the switch problem occur in the first place.

As a project manager, try to emphasize defining and addressing the core problem, but also make sure the customer (or project sponsor) is immediately aware of the actions planned to reduce tension. Some quick steps, with results leading to a solution, can help jump-start the process and provide confidence internally and externally. Set up clear objectives: Review the delivery requirements for the customers; review the white book for the project. Clearly define the root cause and associated change needed. Also define any containment actions needed until the change is effective. Discuss the objective with sponsors and publish the objectives and measures to be taken to rescue the project. Obtain agreement on a common direction. Interview team members and stakeholders: Make sure that there are clear roles and responsibility splits. Get the prioritized list from each stakeholder of what and how they are trying to fix the problem. Based on the objective and interviews, set up a coordination and agreement on the prioritized list of tasks. Set up short- and long-term goals: Chart out low hanging fruit (quick wins) and bigger issues with a schedule of those activities. Communication: Review existing communication plan and change as needed. Set up rules for communication, reporting mechanisms, and frequency. Managing how the information flows inside and outside the team is crucial for any project success, and is often the reason for the project failure. Develop a clear and repeatable approach to communication that includes frequent reports to senior management as well as good communication flow within the team. If the customers are involved, the communication manager should be consulted on the content and frequency of the shared information. Upon resolution of the issue, clear communication should inform key stakeholders of the issue. Customer visits and weekly communication: Do not hide behind the wall but be open to customers with how the company is prioritizing the issues, and constantly seek customer feedback. Do not obfuscate. A technical failure occurring after the product is launched in the market creates an even more challenging communication conundrum. This is especially valid if the failure were possible to predict. As a project manager, if you are

aware of any risks, document them for legal purposes as well as for developing the plans and actions taken to eliminate the risk to public safety. If the team and customers are spread all over the world, the communications strategy should be different: Invest in a travel budget for some face-to-face meetings. Establish leaders for different sites and ground rules for communication and decision chain (a resource allocation plan is especially important). Develop a strength and weakness matrix for each site and, based on feedback, establish a collaboration plan. For example, one site may be weak in marketing; the project manager should identify where and which skill set is used. Resource allocation should be based on capability in such “failing” project; there is no time for developing and training in firefighting mode. With these outlined steps, the project manager will be able to highlight the necessary actions to revive a failing project, and with the appropriate support from the organization, should be able to put the project back on track.

References 9-1. Klein, Gary. “Performing a Project Premortem,” Harvard Business Review, Sep. 2007.

9-2. Flyvbjerg, Bent, “What You Should Know About Megaprojects and Why: An Overview,” Project Management Journal, 02/2014; 45(2), https://www.researchgate.net/publication/261411676_What_You_Should_Know_About_Megaproject

Project Management for Automotive Engineers: A Field Guide Chapter 10: Closing Remarks Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Chapter 10 Closing Remarks

“There is only one thing more painful than learning from experience, and that is not learning from experience.” —Laurence J. Peter As we conclude the book, we would like to reconnect to the Toad and Frog story described in the preface. Each project or task has certain risks of an unexpected wind disrupting the work. With this field guide, we have illustrated the major traps in projects based upon our experience. However, by definition, projects are unique and contain considerable intrinsic variability. Even projects that have similar deliverables will vary in terms of cost and development time. The project office creates standardized templates, communication documents, and time plans for project managers in an effort to streamline the project management burdens. There is certainly some benefit to these tools and templates, but it does not prepare the project manager for the unexpected disruption. Standardized training or templates do not help when responding to unexpected risks. So, is there no hope? Yes, there is. Each crisis is the opportunity to learn, succeed, and for you and the team to shine! Many practices from agile methodologies can help the conventional project manager. Resist any urge to attempt to manage the project from the comfort of your cubic domicile. Walk among the project team members; you can call it Gemba walk or manage-by-walking-around, but stay in contact with the team. Gemba is the Japanese word for at the site, which for project management means spending time with those doing the work, not in a meeting but the location at which the work is performed. Work to discover the potential risks, and avert the course where possible before these risks become full-fledged traumatic events on the project, product, and organization. Work on the problems as they arise, and do not dismiss any of your team members' comments without careful consideration.

10.1 Prioritize and Plan When projects are crunched for time, it is especially useful to have the scope of the work prioritized. There is often the mistaken belief that the customer, or sponsor, values each

attribute of the target equally. Asking questions and prioritizing allows the project manager to focus the team on features that are most valued. Experience suggests this lack of prioritization to be responsible for many a poorly delivered product. Countless meetings with the reluctance to ask the project sponsor, “What is most important?” while simultaneously lamenting the lack of resources results in the final product becoming less than what was desired. Prioritization goes for the planning as well. The further out in the future the plan goes, the more risk is associated with the veracity of those plans. Therefore, the planning should be developed for at least two levels, the immediate and the long term. Take time to consider both of these planning horizons. It is not productive to have a collection of discrete project wins that will not wend to the desired objective. Avoid hyper focusing on one to the exclusion of the other. Project management requires a balance of attention to the immediate needs to keep a project from leaving the trajectory of success, with that of the long-term objective—what constitutes success. Gate reviews and pauses between sprints are not the only time to consider the longterm objectives. Take time to consider the consequences of the short-term actions and planning on the long-term goals.

10.2 Use Fact-Based Metrics Call it like it is; do not sugar coat or obfuscate in an attempt to make your life “easier.” The truth is, anything you say to make things better at the moment that is not factual or is based largely upon hope will likely come back to do twice the damage due to that obfuscation. The executive that hears a project manager tell them all is well, and a week later hears the project manager recanting, does not feel confidence. Base project decisions as much as possible on the facts found on the ground. Make extensive use of metrics, and base decisions on these tangible metrics where possible. The project manager must know what tool to use for each specific situation. There are people that believe Agile is the only way to run a project. Similarly, there are those who believe stage gate is the only way to work. The reality is that both of these methods work, and any method that is poorly executed will likely produce poor results. It is even conceivable to deliver certain parts of the project using agile methods. For example, the testing of the product, or even better, the development of incremental iterations, is essential no matter the project philosophy. Experience also suggests that some of the agile practices can keep a project under control. For example, consider the daily sprint team scrum meetings from Agile; these can easily be employed in conventional projects to monitor the state of present actions and evoke any newly found risks. The project success hinges upon the talent and competency of the team. Take the opportunities to encourage team learning. Improving the competence of the individuals, and as such the team, is best served by making the most of these opportunities to not just solve the problems as they

arise, but to distribute this learning throughout the team. This may sound like it is time consuming, but it is less time consuming than solving the same problem many times over. It is best to avoid the problem altogether, and that is done by spreading the learning around and improving standardized processes. “Good judgment comes from experience, and experience comes from bad judgment.” —Rita Mae Brown

10.3 Review of Chapters In the first few chapters, we emphasized evoking and controlling the scope and managing requirements. This is more like an art in dealing with stakeholders and a science when it comes to prioritization of tangible vs. intangible characteristics and metrics. The business case for the projects should be monitored continuously to ensure that the return on organization investment and corporate objectives are met. In all cases, the project manager should remember that the work is not occurring in a vacuum. The project manager must have a systems perspective, considering how all of the pieces and interactions resolve around each other. Nevertheless, the project environment may sometimes resemble a hurricane with many unexpected risks. For these risks, the project team must prepare a response, and be assured, there is likely a life to any risk response (that is, the risk response will likely generate depending situations that will require effort and attention, and perhaps more risk mitigation). It is incumbent on the team to monitor for the efficacy and for other risks that will require mitigation actions. The project will take its own shape based on technical or commercial challenges (a.k.a. risks), and the team must adapt quickly and prepare a response. This work happens early in the project, as well as recurs as new actions are taken and new things are discovered. Planning ahead saves the project team time as opposed to developing a response when the risk is imminent or has already impacted the project. To be successful, use the company's knowledge base (talent), project reviews, open discussions, and escalation when needed. You can certainly reduce the probability of the risk and subsequent impact. All risks cannot be predicted but, with proper planning that includes response and monitoring, the risks can be reduced and managed to improve the probability of success. In chapters 3, 4, and 5, we discussed the product development processes and schedule. Each of the processes has an objective. Carefully ponder the consequences when considering deletion of processes. Experience suggests that during schedule crunch, there is considerable pressure to deliver the project to the schedule. This puts pressure on the project team to be more

efficient and, in the absence of that, to delete some of these processes outright or cut corners. To be sure, there is more than one way to achieve an objective. It is also possible that the objective and process are not necessary for this project. However, acting on this assumption is a reckless approach. Careful review and understanding of the process and the objective, rather than blithely removing steps, is required. Consider the following example: purchasing spends too much time in negotiating, which in turn reduces time for product development when the schedule is fixed. Purchasing might be following the company's defined process to meet the due diligence required. However, this diligence becomes an obstacle in the execution of the project, as the product development work is connected to the supplier selection. As a project manager, know the need for each of the processes or be connected to subject matter experts that understand these consequences. Models of processes and products are only as good as the facts surrounding each. Creating and confirming or refuting the hypothesis requires challenging the different concepts and justifying the recommendations with facts. By the way, confirming the hypothesis does not make the hypothesis necessarily true, but one refutation requires a rework of the hypothesis. Therefore, look for opportunities to disprove what you believe rather than support. Products, processes, and organizational structures can become more distributed and more complicated, as organizations work to optimize profits by outsourcing or sharing portions of the work globally. When these events occur in the midst of a project, reconstruction may be in order. It may be in the project's best interest to not disrupt the present ways of working. However, if the organization demands, this will likely require re-planning and reassignment of responsibilities for objectives and tasks, which can be a major disturbance to the project. Addressing complexity with yet more complexity is seldom the answer. This is perhaps one of the reasons for the success of agile methods, as complexity is met with fundamentals and simplicity. Even if the organization's preferred method of project delivery is not agile, the project team will benefit by execution and delivery of the project objectives early and often. It is also certain that the more knowledgeable and motivated the team members are, the more likely it is that the team's success rate will go up (barring just bad luck). The impacts of reengineering of the organization (often a euphemism for reducing head count) will require each player on the team to fulfill a variety of roles and often causes confusion in roles and responsibility in the project structure. All these things will complicate product development, sourcing, and manufacturing. Remember that conflict is not necessarily bad. It is one of the roles of the project manager to use conflict constructively to find solutions, not for brow beating or forcing a group of people to act together in suppressing dissent or conflict. Use this tension to find alternative solutions to problems. Decision matrices help to review and assess the value that each of the scenarios creates. Success of the project is not limited to the date of launch or production of units. The project extends beyond the logistics fence, and the proof or confirmation of success lies with

the end consumers. For any industry, the customer should be able to successfully use the features and benefits of the product. For the automotive industry, this is measured in terms of parameters such as fuel economy, convenience features, aerodynamics, or time between maintenance intervals or reliability (often referred to as up time). Value realization is the true measure of successful project execution. An organization that works as if the value realization is the ultimate goal over series production has a substantial advantage. This approach enables a more proactive project environment. Chapters 6, 7, and 8 discuss the verification and validation work, and the transition from prototype parts to full-scale production, passing through the ramp up phase of manufacturing. Verification is fundamental and should be integrated with the development work. Metrics from the verification work inform the development staff and project manager of the possible quality of the product. As such, these measurements suggest the next set of actions and an estimate for the safe delivery of the product. Chapter 9 provides some interesting information on what a project manager should watch for, soft skills, and how to revive a failing project. The project manager should be able to relate to some of the examples in the book. For the activation energy, feel responsible for the end customer, adapt, learn, and enjoy the challenges in the project execution! The more complicated the project is, the more opportunities there are for innovation and out-of-the-box execution.

Project Management for Automotive Engineers: A Field Guide Back Matter Print ISBN: 978-0-7680-8077-3 eISBN: 978-0-7680-8317-0 DOI: 10.4271/R-437

Index advanced product quality planning (APQP), 29, 117-118 agile methodologies, 148 agile practices applied to conventional projects, 100, 101f agile scrum methodology, 32, 33f antilock brake specification, 34 APQP. See advanced product quality planning (APQP) assembly line, 81, 81f assumptions, 84, 148 Automotive Industry Action Group (AIAG), 117 standards, 29, 30f bottom-up approach estimation, 7 multi-layer time plan, 61 budget estimation, 6-7 build-to-print manufacturing site local, 133 burn down chart, 32, 32f business case and phases, 35-36, 36f business justification, 40 cash flow impact, 26-27 internal rate of return (IRR), 27 legal demands, 27-29, 28f legal projects, 25 model accuracy for, 26, 26f payback period, 27 profitability, 25 project manager, 25-26 return on investment (ROI), 26 shareholder, new market and strategic projects, 29 capacity planning, 53 cash flow impact, 26-27 CC. See critical characteristics (CC) cell form, assembly, 81f certifications, 136-137 change management, 43-46, 44f, 45f, 148 Cloud, 62 co-location, 56

communication challenges, 20 failing project recovery, 152 plan, 20-21 plan revision, 21 project communication protocol (PCP), 20 project manager, 20-21 protocol, 17 reports and documentation, 21-22 risk register, 21, 22f during the test phases status report to management, 103, 103f status report to project team, 102, 103f tracking report, 101, 102f transition from project to operations, 124 competition, 54, 76, 148 competitive intelligence, 38-39 complexity, 4, 54, 62, 93, 126, 158, 939 computer-aided design (CAD) tools, 56 configuration management plan, 47-48, 48f confusion, 10, 16, 62, 80, 96, 144 constant turmoil, 72 consultancy, 73-75 continuous conformance testing, 108-109 contract, 138 testing, 109-110 types, 22 control charts, 125 control plan, 89f cost management, 6-7 cost of the product, 76 critical characteristics (CC), 76, 87 critical deadlines, 59 critical path, 61-62 time and schedule, 13 critical requirements., 75, 76f “current production team,” 129 customer. See also voice of customer (VOC) delivering end units to, 131, 131f specification and standard, 98 visits and weekly communication, 152-153

customization impact, 134 cycle time, 87 3-D printer, 106 Daimler-Chrysler production, 130 defects, 80 reporting, 150 delta installation time, 113 dependencies, 8, 9f, 59, 60, 68, 73, 85 design for assembly (DFA), 113, 115 design for manufacture and assembly (DFMA), 115 development models Toyota model (or set based), 35 V (W) model - prototype models, 34, 34f waterfall model, 33 development mules, 64 DFA. See design for assembly (DFA) discounted cash flow (DCF) model, 126 durability, 106-107 early production customization impact, 134 export vehicles, 132-133 labels, certifications, and manuals, 136-137 missing hardware strategy, 136 OEM sampling strategies, 135-136 post-vehicle launch activities, 137 product production quality, prediction of, 133-134 tier 1 and OEM, statistical process control, 135 tier 1 and vehicle operations, 129-132, 131f transition from project to customer service group, 138-140 vehicle and part field failure recovery, 137-138 EDI. See electronic data interchange (EDI) EDM. See electronic data management (EDM) effective product testing. See product testing efficiency, 14, 46, 56, 64, 71, 81f, 92, 98, 125 electromagnetic compatibility (EMC), 65 electronic data interchange (EDI), 112, 136 electronic data management (EDM), 136 EMC. See electromagnetic compatibility (EMC) empowerment, 31

end-to-end process, 84 escalation, 20-22, 147, 150 estimated time of arrival (ETA), 12 evaluation team, 52, 55 export vehicles, 132-133 extreme testing, 98, 107 failing project recovery. See also project management breakdown of, 151, 151f communication, 152 customer visits and weekly communication, 152-153 interview team members and stakeholders, 152 project manager role, 151-152 root cause, 151-152 set up clear objectives, 152 set up short- and long-term goals, 152 failure mode effects analysis (FMEA), 29, 109 failure rate, 99-100, 138. See also vehicle and part field failure recovery fault frequency, 125 FEA. See finite element analysis (FEA) feedback, 29, 39, 49, 50, 64, 68, 84, 96f, 104, 116, 152 financial and earned value reporting, 21 finite element analysis (FEA), 43, 108 firefighting, 72 fit, 84-85 floor plan layout, 88 FMEA. See failure mode effects analysis (FMEA) form, 85 front loading, 69 full-vehicle electromagnetic compatibility (EMC), 65 function, 85 Gantt chart, 11-12, 12f gate criteria, 63-64, 63f gate reviews and pauses, 156 Gauge R &R, 89, 90f gauge repeatability and reproducibility (Gauge R & R), 89-90, 90f Gemba walk, 155 gliders, 132 global positioning system (GPS), 12 global technology vs. local application, 148

goof-proof, 90 HALT. See highly accelerated life testing (HALT) hard equipment, 73 hard features of the product, 76 highly accelerated life testing (HALT), 98, 106-107 hiring and training, 72 historical and analogous estimation, 7 human potential, 80 human resources, over-utilization, 11 hyper focusing, 156 IMDS. See International Material Data System (IMDS) information description, 21 distribution, 21 schedule, 21 inspections, 110 interchangeable item, 85 interdependencies, 59 project, 62, 63f types, 8, 9f interface, 85 control, 85 internal rate of return (IRR), 27 internal testing, 109 International Material Data System (IMDS) automotive OEMs, 118 benefits, 119 Bill of Materials (BOM), 119 Dodd-Frank Wall Street Reform and Consumer Protection Act, 119 Material Data Sheets (MDS), 119-120 material information, 119 sustainable materials review, 119 tolerance, 119 interview team members and stakeholders, 152 inventory, 80 key control characteristics (KCC), 87 key milestones, 60

key performance indicators (KPIs), 125, 139 key product characteristics (KPC), 75-77, 76f, 87 knowledge management, project closure efficiency dip, 145, 146f process change trigger, 146 project management, 145 strategy and risk, 146 labels, 136-137 lean manufacturing approach (5S), 88 lean project management (agile), 30-32, 32f, 33f legal demands, 27-29, 28f legal project, 7-8, 25, 147 line organization and project managers, 71 line sequenced, 130 list of work packages, 59 live prototyping, 68 local country adaptations, 148 logistics and current product order, 113 low profitability products, 147 low-cost market, 148 mailbox project managers and reactive sponsors, 150-151 maintainability, 76, 77, 126 maintenance, 54, 83, 139, 142 manuals, 136-137 manufacturability, 76, 116, 122 manufacturing facility, 92 manufacturing line, 81-82 manufacturing process development, 82 manufacturing specific deliverables, 86 characteristics, 87 floor plan layout, 88 gauge repeatability and reproducibility (Gauge R & R), 89-90 packaging standards, 92-93 Poke Yoke, 90 process control plan, 88-89 failure mode and effects analysis, 88 flow chart, 87 instructions, 89

product/ process quality system review, 86 run at rate, 92 trial production run, 91-92 matrix organization structure, 70 matrix vs. line organization balanced, 16 decision-making process, 16 functional organizations, 15 line manager, 16 matrix models, 15, 15f project manager, 14-16, 16f project-driven organization, 16 resource managers, 15 risks and conflicts, 17 MBR. See model based requirement (MBR) measurement, ramp up production design, 125 measurement system assessment (MSA), 29 megaprojects, 147 methods build area, 116 missing hardware strategy, 136 model based requirement (MBR), 43 motion, 80 muda, 79-80 multi-layer time plan, 61, 68, 69f multiple projects, 9-10 mura, 80 muri, 80 net present value (NPV), 27 network diagram, 11, 11f OEM. See original equipment manufacturer (OEM) OEM and Top-Tier supplier selection statement of work, 53-54 supplier quality, 55-56 supplier selection cost, 50 employment plunge and automotive establishment, 50, 51f evaluation process, 52f, 53-53, 53f financial failure and the interrelationship, 50, 51f relationship, 50

risk, 50 supplier procurement, 49 off-shore production, 126 operations manager, risk assessment, 116 organization change or shakedown, 148 organization size and footprint, 17 organizational influences executive’s role, 19-20 matrix vs. line organization, 14-17, 15f, 16f organization size and footprint, 17 stakeholder and sponsor management, 17-18 roles and responsibility, 18-19, 18f, 19f original equipment manufacturer (OEM), 118 product handling, 84 part numbering revisions, 84-86 sampling strategies, 135-136 outsource testing facility, 75 over-committed resources, 72 over-processing, 80 over-production, 80 packaging standards, 92-93, 93f parametric estimation, 7 payback period, 27 pay-on-production, 130 PCP. See process control plan (PCP); project communication protocol (PCP) pet (strategic) projects, 147 phases and delivery, time plan, 60 pilot run, 91 Poke Yoke, 90 for electrical connector, 91f poorly aligned project, 147 post-vehicle launch activities, 137 power or status quo, 149 PPAP. See production part approval process (PPAP) prioritization and plan, 156 problem areas prioritization, 151 process change, 86f defined, 73

flow chart, 87 instructions, 89 verification, 107 process control plan (PCP), 88-89 process development, 79 activities, 82 manufacturing line, 81-82 process areas of focus, 82-83 product and process synergies, 82 waste, 79 muda, 79-80 mura, 80 muri, 80 process failure mode and effects analysis (PFMEA), 88, 115-116 product backlog, 31 design personnel, 8 process quality system review, 86 and process synergies, 82 production quality, prediction of, 133-134 profitability, 5 validation, 105 product development key product characteristics, 75-77 processes and schedule, 157-158 project schedule, time plan, 59-64 prototype delivery and risk, 64-65 resources allocation, 70-75 virtual testing and prototype in, 66-70 product life cycle and testing agile practices applied to conventional projects, 100, 101f communication during the test phases, 101-103, 102f, 103f continuous conformance testing, 108-109 fundamentals, 95-97, 96f pillars of, 95, 96f process verification, 107 product validation, 105 test modes contract testing, 109-110 inspections, 110 internal testing, 109

testing process, 97-100 verification durability, 106-107 extreme testing, 107 reliability, 106 through simulation, 108 vs. validation process, 104 product life cycle management (PLM) tools, 96, 114 product testing customer specification and standard, 98 extreme testing, 98 failure rate, 99-100 test cases, 99 product verification and features durability, 106-107 extreme testing, 107 reliability, 106 production line, ramp up production design, 111, 112f production part approval process (PPAP), 29, 91, 112, 117-118 profitability, 25 program management, 62, 63f progress reporting, 21 progressive elaboration, 30 project coordination or program management, 39, 40f leadership, 71 profile, 4-5, 5f, 60 schedule, 71 scorecard / vitality report, 21 project closure accomplishment, 141 confidence, 141 introspection, 142 knowledge management, 145-146, 146f lessons learned evaluation sessions, 144 hope management, 142 premortem, 144-145 self-calibration, 142 specific, 144 STOP sign, 143

stress, 143 up-front preparation, 144 white book, 143 5-why technique, 143 ownership transfer, 142 user acceptance, 142 project communication protocol (PCP), 20 project life cycle Automotive Industry Action Group (AIAG) standards, 29, 30f lean project management (agile), 30-32, 32f, 33f phases concept, 30 project management, 156. See also failing project recovery cost management, 6-7 project scope, 4-6, 4f, 5f risk management, 13-14, 14f three dimensions of, 5f time and schedule, 7-13, 9f, 11f, 12f project management office (PMO), 71 project manager (PM), 157 business justification, 25-26 conflict, 158 decision matrices, 158 logistics and technical solution, 132 project scope, 4 role, failing project recovery, 151-152 soft skills for defects reporting, 150 mailbox project managers and reactive sponsors, 150-151 to please or not to please, 148-149 power or status quo, 149 problem areas prioritization, 151 sunk cost trap, 149, 150f time plan, 61 virtual testing and prototype in product development, 67, 69 project scope definition, 5 goals and constraints, 4 impact matrix, 4, 4f product profitability, 5 project management, three dimensions of, 5f project manager (PM), 4

project profile, 4-5, 5f scope creep, 6 Work Breakdown Structure (WBS), 6 project team responsibility, 157 time and schedule, 7 prototype, 159 delivery and risk, 64-65 testing, 56 Pugh matrix, 28, 28f quality, 85 system, 29 tools, 115 quality system assessment (QSA), 29 quantified requirements, 38 ramp up production design activities from design board to production floor, 114-117, 117f cost, 112 delta installation time, 113 electronic data interchange, 112 environmental impact, 127 International Material Data System (IMDS), 118-120 logistics and current product order, 113 production line, 111, 112f production part approval process (PPAP), 112, 117-118 scale of, 113 supply chain decisions, 126 Tier 1 and 2 suppliers, 113-114, 114f transition from project to operations communication plan, 124 manufacturing investment, 120 material flow, 120 measurement, 125 risk analysis, 120 size and purpose, 120-122, 122f software handling, 123-124 validation, 122-123 transition from prototype to production checklist, 126

suppliers, 125 recurring risk assessment, 147 reliability, 106 requirements and change management, 43-46, 44f, 45f traceability, 40-41 traceability plan, 46-47, 46f, 47f resources allocation, product development hiring and training, 72 line organization and project managers, 71 matrix organization structure, 70 outsource testing facility, 75 project leadership, 71 project management office (PMO), 71 project schedule, 71 resource utilization, 71 tools, 72-73 work packages transfer for consultants, 73-75 utilization, 71 responsibility, time plan, 60 retrospective, 32 return on investment (ROI), 26 right skill set and motivation, 73 risk management, 13-14, 14f register, 21, 22f run at rate, 92 5S (lean manufacturing approach), 88 sales and marketing team, time and schedule, 7 scope creep, 6 for the supplier, 52 shareholder, new market and strategic projects, 29 simulation, 69-70, 70f simultaneous engineering, 82 smooth drive, 38 soft equipment, 73 soft features of the product, 76 software handling, ramp up production design, 123-124

speed bump effect, 46, 47f sprint, 31 sprint backlog, 31 stage gate process, 63 stake, 3-4 stakeholders expectations, 132 and sponsor management, 17-18 roles and responsibility, 18-19, 18f, 19f standard templates, 73 Standish Group International, 3 statement of work, 53-54 statistical process control (SPC), 29, 56 stove pipe, 15 strategy to objective, 147 subject matter experts (SMEs), 42 sunk cost trap, 149, 150f supplier quality, 55-56 supplier quality assurance (SQA), 138 suppliers partnered, 148 requirements, 52 selection, timing of, 52-53 supply chain decisions, 126 support/ recommendation/ escalation, 22 Takt Time, 87 talent erosion, 10 team’s assumptions, time plan, 60 technical and business requirements, 52 technical reviews, vehicle concept development and selection, 48-49 technology readiness, 73 test cases, 99 test modes contract testing, 109-110 inspections, 110 internal testing, 109 test mules, 64 testing process attention to time plans, 97

automated, 97 effective product testing customer specification and standard, 98 extreme testing, 98 failure rate, 99-100 test cases, 99 key performance metrics, 97-98 project team verification, 98 third-party consultants, 74-75 services, 73 tier 1 and OEM, statistical process control, 135 tier 1 and 2 suppliers, 113-114, 114f tier 1 and vehicle operations, 129-132, 131f tier 1 production line and prototypes, 83-84 tier 1 supplier, 87 time and schedule critical path, 13 estimated time of arrival (ETA), 12 Gantt chart, 11-12, 12f global positioning system (GPS), 12 government role, 7 human resources, over-utilization, 11 interdependency types, 8, 9f legal projects, 7-8 multiple projects, 9-10 network diagram, 11, 11f priorities, constant juggling, 10 product design personnel, 8 project team, 7 sales and marketing team, 7 talent erosion, 10 WBS method, 8 time dependent, transition from project to operations, 140 time plan critical deadlines, 59 critical path, 61-62 dependencies, 60 gate criteria, 63-64, 63f interdependencies, 59 interdependency project, 62, 63f key milestones, 60

list of work packages, 59 multi-layer time plan, 61 phases and delivery, 60 project manager, 61 project profile, 60 responsibility, 60 team’s assumptions, 60 TIMWOOD, 80 top-down approach, multi-layer time plan, 61 estimation, 7 Toyota model (or set based), 35 tracking report, 101, 102f training, 148 transportation, 80 trial production run (TPR), 91-92 use fact-based metrics, 156-157 V (or W) model - prototype models, 34, 34f validation, 66 ramp up production design, 122-123 verification vs., 104 value project, 148 value realization, 159 vehicle and part field failure recovery, 137-138 vehicle concept development and selection competitive intelligence, 38-39 configuration management plan, 47-48, 48f OEM and Top-Tier supplier selection, 49-57 project coordination or program management, 39, 40f requirements and change management, 43-46, 44f, 45f requirements, specifications, and drawings, 40-43, 41f, 42f requirements traceability plan, 46-47, 46f, 47f technical reviews, 48-49 voice of customer (VOC), 37-38 vehicle documentation, 139 vehicle integration, 53 verification, 159 durability, 106-107 extreme testing, 107

reliability, 106 through simulation, 108 vs. validation process, 104 virtual manufacturing, 108 virtual testing and prototype in product development CAD tools, 66 incremental product growth, 67 iterative testing, 67, 68f limitations, 66 live prototyping, 68 modeling, 66, 69 multilayer time plan, 68, 69f performance, 66 project manager, 67, 69 purpose of, 66, 67f simulation, 66, 69-70, 70f validation, 66 voice of customer (VOC), 37-38. See also customer waiting, 80 warranty repairs, 125 waste, 79 muda, 79-80 mura, 80 muri, 80 waterfall model, 33 Work Breakdown Structure (WBS), 6 method, 8 work package leader, 75 zero mile, 138

About the Authors

Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. Jon has served in many capacities in developing automotive products, the last of which was as Process Manager at Volvo Trucks North America for the Electrical / Electronics department. Jon has an Engineering Degree from the University of North Carolina at Charlotte, and two Master Degrees from City University of Seattle, and twenty-six years of product development experience, with twenty-one years of automotive experience. Jon has won awards such as the Volvo-3P Technical Award in 2005 going on to win the 2006 Volvo Technology Award, and has ceded seven US patents. Jon is on the Western Carolina University Masters of Project Management Advisory Board as well as Forsyth Technical Community College Advisory Board. Jon holds PMP certification and teaches Project Management classes at university and colleges, and speaks on these topics. Jon has co-author or contributed to more than ten other the books on various project, product and quality management topics (software) including product testing, agile project management, cost management and configuration management. In addition to numerous books and e-books, he has co-authored scores of magazine articles that appear in more than twenty magazines. He has also given numerous presentations at product development conferences on a variety of aspects of product development including testing and project management. Jon enjoys the beauty of nature, hiking in the woods and plays the bass. Jon lives in Lexington North Carolina with his wife Nancy, and son Jackson. Email Jon at [email protected].

Roopa Jha Shenoy is currently working as Chief Project Manager at Volvo Group North America. She has over nine years of new product development experience at Volvo, delivering product features, cost, and quality. She has successfully led projects, cross functionally working with the global teams, and has managed project budgets over $250M. During the project phases, Roopa has used both traditional as well as agile methods in the project execution. She has led new product introduction, commercialization, and brand management as well integrating the right strategy for communication. Prior to Volvo, she worked at Intel Corporation and Cree Inc., where she worked on continuous improvement efforts and managed new products. She worked in research and development as well as supervised the operations for the company, managing quality by using statistical process control. She also has three years of IT project management/agile experience as a consultant in the software industry. During multiple project execution, Roopa successfully used lean methodology to achieve quick time to market. By using a pragmatic approach to the project management principles, she simplified the most complex projects and thereby lowered the risk of failure. She has an MBA from University of North Carolina at Chapel Hill and an MS in Electrical Engineering from North Carolina State University. At NCSU, she was awarded a fully-funded fellowship by Semiconductor Research Corporation to pursue cutting edge research in semiconductor technology.