In Chapter 1, we introduced the six bodies of knowledge that are the foundation of good engineering management. This chapter outlines the key elements and critical steps necessary to implement process management concepts. We will use a process framework to structure the product definition engineering (define) process. Tailoring these processes should be based on customer, program, and business needs. However, certain fundamentals such as multifunctional teams, timely communication, integrated master plans, integrated master schedules, team colocation, and empowerment, should be applied on all of your company's programs.

This chapter looks at how to structure the Define process to help achieve business objectives. To this end, we discuss the work breakdown structure, the process framework, the structure of customer deliverables, the use of product maturity gates to control design quality, and the organization of engineering documentation.

ENGINEERING PROCESS FRAMEWORK

The approach to engineering design is based on aligning activities to the process framework. Years of experience have shown that every engineering project follows a similar path from initiation to completion. We know that no two projects or programs follow exactly the same path; however, defining this general process framework provides the foundation for engineering process management, upon which the detailed components have been developed.

Table 2-1 (see Appendix B) shows a process framework with its objectives and major deliverables (ex: Design Documentation) for each of the phases, and Table 2-2 (see Appendix B) identifies the descriptions and deliverables for each of the subphases in the process framework.

D.1 PROGRAM SCOPE AND ENVIRONMENT CONFIRMATION

❍ Confirm program scope and objectives

➮ Review charter, proposal, and existing workplans

❍ Confirm cost and schedule constraints

➮ Use planning assumptions worksheet

❍ Confirm engineering and work practice guidelines

➮ Use planning assumptions worksheet

❍ Interview corporate executives

D.2 PROGRAM STRUCTURING

❍ Select and tailor subphases

➮ Use IPD process architecture diagram

❍ Select and tailor subphase objectives

➮ Use IPD subphase objectives chart and IPD workflow diagrams

❍ Determine customer deliverables

➮ Use subphase objectives chart

❍ Select and tailor customer deliverables sections

➮ Use deliverables definition worksheets and IPD workflow diagrams

❍ Determine key deliverables

➮ Use IPD workflow diagrams

❍ Identify CAD/CAE tools constraints

➮ Use program planning assumptions worksheet

❍ Select design techniques and tools

➮ Use program planning assumptions worksheet

❍ Select design hardware and software

➮ Use program planning assumptions worksheet

❍ Determine design standards and procedures

➮ Use program planning assumptions worksheet

❍ Determine replanning points and planning windows

➮ Use program planning assumptions worksheet

❍ Select program management techniques and tools

➮ Use program planning assumptions worksheet

❍ Determine program reporting procedures

➮ Use program planning assumptions worksheet

❍ Determine issue logging and resolution procedures

➮ Use program planning assumptions worksheet

❍ Perform risk assessment

➮ Use risk assessment questionnaire

❍ Determine strategies for managing risk

➮ Use risk management strategy tables

❍ Determine program risk assessment points

➮ Use life cycle checkpoints worksheet

❍ Tailor the IPD program review process

This chapter is written specifically for the team member. It explains how the team member can use the documentation that supports the product development process to understand and perform the required work. Program and functional directors should read this chapter to understand the details of the process.

INTEGRATED PRODUCT TEAM MEMBER RESPONSIBILITIES

The program and functional directors will give IPT members various assignments from the project plan, and this chapter will show a team member how the process documentation helps to complete them. Understanding how the project plan is organized is critical to allowing a team member to find and assimilate quickly what he or she needs to know and how to complete an assignment.

PERFORMING A SPECIFIC TASK

Performing a specific task means doing work that contributes to the development of the customer's product. The program director bases the assignment of these tasks on the program plan and his or her judgment of how resources should be allocated. Because the program plan is developed from the workplan templates, most assigned tasks are described in the process documentation. Completing a task involves

1. ❍ Understanding what the task involves, howit fits into the process integration framework, and to which customer deliverable it contributes

2. ❍ Understanding the individual work products that result from completing the task

3. ❍ Gathering the materials necessary to complete the task

4. ❍ Performing the task

In this chapter, we will examine an approach to top-down planning involving three principal activities:

❍ Confirming the program scope and environment

This activity includes understanding the program objectives and scope, the technical and work practice requirements, and the cost and scheduling constraints. All of this is critical for product and functional directors.

❍ Structuring the program

This activity involves defining the general approach to organizing and managing the program and developing a high-level program plan.

❍ Developing the detailed workplans

This activity includes planning and estimating, at a detailed level, the outputs required to fulfill each of the program's subphase objectives.

We will also describe these planning activities and showthe important linkages and considerations in using a top-down planning methodology. Figure 7-1 illustrates the results of these activities. The remainder of this chapter describes them in more detail.

Planning an advanced engineering program effectively is an essential prerequisite to delivering a quality product definition. With a firm understanding of the customer's business and a well-thought-out program plan, the product and functional directors can maintain perspective and a clear direction in the midst of rapid change. They can also remain flexible enough to accommodate requests for changes to the product's specifications or modifications necessitated by changing technology.

Program structuring and planning is accomplished by tailoring the Define process to fit the unique characteristics of the program. It defines the work that must be performed by identifying which tasks and worksteps in the workplan templates are required to complete the project.

The successful implementation of an advanced engineering program is a team effort. To be effective, the program team must be more than just a collection of individuals. The team must have the management, technical, functional, and product skills necessary to address the variety of challenges typically encountered on an advanced engineering program. Moreover, your company's partners and subcontractors must work well together to provide an effective solution for the customer.

As organizations growlarger, hierarchical structures, specialization, and facility dispersion make it more difficult to communicate across functional boundaries and to coordinate activities. Integrated product teams are a way to organize into smaller units to facilitate communication among customer, suppliers, partners, and your company; to develop a multifunctional perspective; and to develop wellbalanced, consensus decision making.

The organization of the team members on the program is a critical aspect of the proposal and program initiation processes. Before the program can get under way, it is necessary to identify the major program roles and responsibilities. Individuals should then be selected to fill those roles based on their skills and experience in solving similar problems.

Customer personnel, operational/program management, and partners play specific roles in the management and execution of an engineering program. The organization for a specific program depends on the product design, the particular program responsibilities of your company, customer and partners, and other program characteristics. However, certain roles are common to every program.

Managing the transition from the current to a new product development process is a difficult job. One of the most critical elements of that transition is implementing a newteam-based approach. Realizing tangible benefits from a team-based approach does not come easily. Resistance to change can emerge from all areas of the organization.

This aspect of the management process has consistently been a weakness for engineering-driven companies. Engineers are notorious for resisting cultural change. Traditionally, engineers focus on scientific concepts and “things” rather than emotions and people. The transition to top management is not an easy road for the typical engineer. In this chapter, we discuss the “soft” side of management. At the heart of any change initiative is balance between business needs, individual needs, and organizational politics.With the right help, this balance can be found by a company undergoing change. The organization can be improved by “engineering” the right processes, measures, technologies, and culture. Collective behavior can be predicted by the trained mind. Politics can be engineered to allow the improvement initiative to succeed. But these skills are rarely taught in engineering or business schools.

ORGANIZATIONAL POLITICS

The approach to changing the culture will need to be outside the normal project approach for an organization. To capture the organization's attention will require choosing methods that stand in stark contrast to standard operating procedures.

This chapter explains the organization of tasks using workplan templates within the task guidelines (see Section 6.2). Within this structure, you will be able to see how a task fits with your program plan and to know how to find detailed information about it.

Tasks depend upon two other elements – resources and schedule. Understanding the resources required to perform a task and the schedule within which the task must fit allows us to manage costs effectively. All three elements must be managed in concert with one another. A change in one element has an impact on the others. Prior to a formal process management, these elements, in many organizations, were managed independently. This imbalance would lead frequently to internal power struggles. Functional directors would assign resources as they saw fit without a view of the impact on other tasks within the integrated master schedule.

Tasks are always organized into the processes that define the business process framework, and processes overlap phases. In addition, developing reference manuals that capture the knowledge you gained on previous programs and that document new or established approaches offers tremendous benefits. They describe the worksteps of howto carry out a task, including technical rules. The documentation of these rules allows the organization to “learn.” The process of maintaining design rules lends itself well to intranet application because it allows distributed access to all members of the collaborative project. Further, an intranet permits ease of update and version control. (See Chapter 11 on utilizing product data management.)

ERP and PDM have different origins and different purposes.

MRP (materials requirements planning) came into being in the 1960s as a methodology or practice for maximizing the efficiency of production through production schedules and inventory control. Even though the definition has evolved with the addition of financial information to MRP II to ERP (enterprise resource planning), the basic functions remain the same – tell me how much inventory and manufacturing resources I will need to produce x amount of product over y period.

MRP software systems evolved to handle the large amounts of data and the complex calculations required to answer this question. They have served as planning tools for production, and accounting tools for reporting inventory status. The late Oliver Wight led the MRP II crusade in the United States beginning in the early 1980s. Practically all ERP gurus today learned the ERP body of knowledge through APICSand “Olie” Wight.

PDM (product data management) came into being in the early 1980s, originally as a means to manage engineering documentation. It offered a number of new concepts just now emerging as mainstream capabilities for general use, such as document management, workflow, and distributed repositories. These “services” were put together to answer questions such as:

1. ❍ What does the configuration for the current active revision look like?

2. ❍ What did the prior revision of this product look like?

3. ❍ What changed between that revision and the current one?

4. ❍ How many engineering change orders are outstanding against this product?

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.