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.

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.