Implementing the concepts outlined in this book is a major program that will affect and involve people from all areas of the company. The purpose of this chapter is to examine the people-oriented side of planning, organizing, developing, and implementing the changes outlined in this book. Implementing broad-based change to the engineering process represents one of the highest cost/potential payback improvement programs that can be undertaken at any company. A successful product development improvement initiative is the result of careful planning and organizing by the people responsible for deploying the new system. Most engineering executives know the theory of IPD and Concurrent Engineering, but few successfully deploy the concepts efficiently.On top of that, the company doesn't realize the commercial benefits. It is critical that sufficient planning occur before deployment.

The process of planning involves setting goals, selecting and developing methods for achieving those goals, and presenting the plan to begin its execution. These steps are discussed, along with other points necessary to begin the implementation.

INITIATIVE PROGRAM ORGANIZATION

The process of organizing consists of

1. ❍ Specifying the task to be performed

2. ❍ Breaking down of the total task into manageable segments

3. ❍ Establishing clear responsibilities

4. ❍ Selecting people to execute the task

Because success of the program is directly related to how it is managed, executive management should be involved in program organization. They should guide the development of the strategies to implement the changes at the company.

One of the greatest benefits of applying process management to engineering operations is its ability to help build quality into the product development program. As mentioned earlier in this book, the methodology does this through a combination of people process and technology. It encourages user involvement and effective communication and applies techniques and results in complete documentation. In short, it helps focus on one of our most important goals: to provide high-quality engineering focused on customer needs. In this chapter, we look at the program review process and its role in ensuring product and process quality.

QUALITY ASSURANCE FACTORS

The quality assurance process helps ensure that work gets done correctly the first time, by assisting you in addressing those factors that are essential to a quality assurance (QA) effort. They include

1. ❍ Focusing on the customer/partner expectations

2. ❍ Doing the right task the right way the first time – First, concentrate on making sure that the right work is being done correctly, then focus on doing it faster.

3. ❍ Following a proven approach to integrated product development, a way of building quality into the process and the product from the start

4. ❍ Using proven program planning and tracking techniques – Framing a well made plan and then monitoring its execution is a way of infusing a program with quality from the start.

5. ❍ Providing for training and education – Training is an essential part of improving quality in the product development process.

This book is intended to help you implement a more rigourous approach to the practice of engineering management. In our consulting work, we have seen many attempts to improve this management process. Mostly we have been called in when previous initiatives have failed. We believe that these initiatives have failed for one simple reason. They were narrow, one-dimensional solutions to problems that had many facets. Additionally, the people who offered the consulting services quite often had very little practical background in engineering. In this book, we will look at the engineering process from a holistic approach.

Typically, we see the scenario play out as follows: a firm finds that its development projects are taking too long or costing too much money to complete. A senior manager in engineering has read a book, attended a course, or acquired considerable experience in one particular approach and recommends that the organization simply implement this new way and the problem will be solved. In the best case, a year later the performance in the one area at which the solution was aimed has improved, but there is no broad-based financial measure of improvement. In the worst case, the organization is in upheaval with pockets of resistance firmly entrenched against the change.

The reason for this failure is the application of improved methods in isolation from one another. These solutions typically originate from one of six bodies of knowledge.

The vision of engineering management presented by Stephen Armstrong is one that is both broad in its context and deep in its coverage. He offers the engineering project manager an extensive set of management tools that, when used in total, will assure project success while improving overall project engineering effectiveness. Managers that employ this methodology will soon find this to be their indispensable desktop reference manual as they progress through the phases of product development.

The demands on the modern engineering manager are greater than they have ever been and the challenges to program success continue to grow exponentially. The rapid growth of technology has resulted in most of the products being developed by current and future companies – large and small – being inordinately complex systems of integrated technologies. This complexity is exacerbated by the complicated interdependencies among the technologies of the various product components. The availability of highly capable e-design, e-analysis, and e-prototyping tools and the growth in new methods that better integrate design and manufacturing are both wonderful benefits and potential burdens to the engineering teams using them. The move to virtual prototyping changes the planning and staffing profiles from that of the traditional project engineering organization. Added to these changes are the increasing demands for shorter and shorter engineering span times accompanied by the further expectation that engineering costs must be reduced by factors of 30 to 50 percent for businesses to remain competitive, and in some cases these reductions are expected to be recurring.

In this chapter, we will study an engine manufacturing company we will call ACME Engines as it begins to adopt a new integrated product development process based on concurrent engineering and integrated product teams around 1998. There are risks in implementing sweeping changes within an organization. One very real risk comes from thinking of the implementation in too narrow a context. One of the fundamental bodies of knowledge upon which this book is based is concurrent engineering (CE).Many managers will confuse a simple CE implementation with the holistic approach to engineering process management discussed in this book.

In implementing the changes, ACME observed that CE and IPT theories are being embraced across the aerospace and automotive industries. However, they also observed that implementation requires changes to howthey organize, manage, and perform the engineering activities. These changes were not well understood nor accepted. As described in a Fortune magazine article, “The Trouble with Teams” (September 5, 1995), many other companies have also found the transition to teams to be much more difficult than expected. The director responsible for leading the changes at ACME emphasized, “Our biggest blunder was to underestimate the impact of organizational resistance to change.” They indicated initially that the team approach may not seem to be as efficient as the old approach but that they are beginning to see now that it eventually provides superior results.

An advanced engineering program requires the efforts of many professionals. Although no single contribution is ever responsible for a program's success, a project cannot hope to be successful unless it is managed well, unless all the personnel and resources involved are coordinated and directed toward a common goal.

In any organization, having people play their roles and take defined responsibilities plays a critical part in ensuring success. For example, it is very important that a functional manager take responsibility for running the organization and controlling the utilization of the resources.

This chapter focuses on the processes of program management. Reflecting on the program management workplan template, these pages discuss the major responsibilities that the program and functional directors have throughout the program. Also included is information on the interrelationship of roles.

The objective of this chapter is to outline the approach to managing a project. We stress that planning and control is an important component of any program management technique, but we will also look at specific leadership issues facing the program and functional directors, the importance of creating executive commitment to your program, and the interrelationships of key roles.

WHAT IS PROGRAM/PROJECT MANAGEMENT?

The complexity of program/project management makes it difficult to describe in a few words. Basically, however, it can be defined as planning, organizing, directing, and controlling resources to meet a specific business goal.

One of the most challenging aspects of an advanced product engineering program, especially from the program manager's perspective, is managing change. Although most changes are ultimately for the good of the program, some may seem frivolous, while othersmaycause delays that raise questions as to just howmuch they actually benefit the program.

A clear plan for managing change on any program will make managing it significantly easier. This chapter suggests an approach to engineering change management, in addition to providing insight into the concept of change as it pertains to integrated product development. One of the hottest topics in engineering management is product data management or PDM. PDM is a software application used to help manage the engineering process and related data. We will cover the key concepts of PDM and the relationship to process management in this chapter.

WHAT IS ENGINEERING CHANGE?

Engineering change is the addition to, deletion from, or modification of a product during its design, development, or manufacture. It is a normal occurrence during the progress of a program, most often caused by an evolving business environment or an advance in product technology. Regardless of the reason behind it, a change can have a serious impact on a program's scope, cost, or schedule.

Changes are not synonymous with problems. A change is an alteration to the specification or design of a product, whereas a problem is a variance between the expected result and the observed result.

Answer each question to the best of your knowledge. You have the option to answer “Not Applicable” to any of the questions, but do so only if the question does not apply to your program, not because you cannot answer it. If you do not have sufficient information, you may overlook a significant risk and run into unpleasant surprises later in the product development effort. Some questions, of course, cannot be answered at the beginning of the program, for example, questions about the use of new CAE technology such as computational fluid dynamics software. In such cases, reassess the risk when the facts are known.

A.1 PURPOSE OF THE EVALUATION TOOL

This section contains an IPD Maturity Self-Evaluation Tool for assessing the status of integrated product development best practices on a program, as well as the overall maturity in IPD within a business. The results an be used to provide feedback to program managers, integration team members, integrated product team members, functional managers, and other site IPD stakeholders for process improvement activities. The survey can also help to identify new best practices in IPD by sharing lessons learned.

A.2 SCOPE OF THE EVALUATION TOOL

The evaluation tool/survey appears in Table A-1. It is structured in the form of statements of reality rather than questions of perception. It is also important to note that duplication between the sources has been eliminated, resulting in a single set of statements. Therefore, to receive an accurate assessment, a response to all the statements, regardless of their origin, is necessary. Additionally, at the end of the statements the assessor is given the opportunity to express subjective opinions, comments, and suggestions about the implementation and effectiveness of IPD in an essay-type format.

The user may choose to use this tool as a checklist to determine what IPD techniques are or need to be implemented; as a survey, responding to the statements in a “yes/no” fashion; or as a maturity indicator, where a specific response to each statement contributes to an overall measure of maturity.

In an engineering product development program, risk is the likelihood that the new product will not meet the customer's needs, be completed on time, or be completed within budget. This chapter focuses on these risks. It presents an overview of the risk assessment procedure and discusses the risk assessment questionnaire. Then it takes a detailed look at some risk factors common to engineering development programs and offers some strategies for managing them. The risk assessment questionnaire, summary sheet, and risk management strategy tables can be found in Appendix E.

PERFORMING A RISK ASSESSMENT

Advanced product development engineering programs are among the most complex activities conducted by mankind. They often involve millions of dollars of investment and thousands of hours of work by highly educated people. Risk is therefore high. Shareholders are willing to accept the risks involved in such an effort providing the potential returns are high. Yet even under the guidance of an experienced director, a program may fail because of inherent risks. By actively assessing a program's risks, however, you can reduce the likelihood of failure.

Risk assessment is a systematic method of identifying a program's risks and then determining appropriate strategies for managing them. It is also a mechanism for communicating the program risks to the customer/partner and to corporate executives. It sets the stage forworking with the customer/partner to reach agreement on risks that are acceptable and in line with the organization's tolerance.

As the frontiers of technology advance and the work of engineers takes on an increasingly important role in our economy, companies with effective product development and engineering processes will be poised to create value for their shareholders. Those without the will to improve engineering and product development processes will be destined to lag behind.

Our university engineering programs focus on graduating technically sound engineers. Students study the disciplines of structural design or fluid mechanics. However, in both North America and Europe, little attention is paid to teaching the practice of engineering management. Engineering programs typically contain a fourth-year course on engineering economics, where students are taught the mechanics of discounted cash flows and budgets. The courses do not deal with the challenges of managing complex engineering-driven companies. With this gap in the training of engineers, it should come as no surprise when a graduate engineer practices engineering for two or three years and then leaves the profession to take an MBA. Many of these bright young engineers cut all ties to engineering. However, MBA programs are not designed to create engineering managers. The best of them teach the integration of management disciplines to teach general management; however, the worst provide the engineer with little more than a few specialized tools to apply in the area of marketing or finance. Generally speaking, the practice of engineering management is not taught in our universities.

Theoretically, steady-state flow is fully established in a given domain Ω when, for any spacial point in Ω, all the mechanical and physical variables that are necessary to describe the problem are independent of time t. Of course, the position of a material point is not constant, but follows a fixed trajectory as shown in Fig. 9.1.

From the practical point of view, the steady-state idealization is always an approximation, as a true stationary flow would require an infinite time to be established. However, in industrial processes such as rolling, extrusion, drawing, and so on, the steady-state assumption is a rather accurate approximation as soon as the length of the deforming zone is less than half of the rigid parts lying before or after this zone. At this stage the end effects, that is, the discrepancies from the stationary shape that occur at the beginning and at the end of the process, have a vanishingly small influence on the flow. In the sheet-rolling process, the length of the deformed zone is of the order of a few centimeters, and the length of the rolled sheet is several hundred meters. Conversely, during the extrusion process, the length of the billet is only of the order of ten times the diameter so that the steady-state part of the process is more approximate, and represents a smaller percentage of the whole process.