Project Management for Mobility Engineers: Principles and Case Studies [1 ed.] 9780768093612, 9780768093575
Project Management for Mobility Engineers: Principles and Case Studies provides the latest training, workshops and suppo
220 122 8MB
English Pages 289 Year 2020
Polecaj historie
![Practical Project Management for Engineers [Illustrated]
1630815853, 9781630815851](https://dokumen.pub/img/200x200/practical-project-management-for-engineers-illustrated-1630815853-9781630815851.jpg)
![Conflict Prevention in Project Management: Strategies, Methods, Checklists and Case Studies [1 ed.]
354077436X, 9783540774365](https://dokumen.pub/img/200x200/conflict-prevention-in-project-management-strategies-methods-checklists-and-case-studies-1nbsped-354077436x-9783540774365.jpg)
![Project Management Case Studies [5 ed.]
2016056664, 2016057574, 9781119389156, 9781119389163, 9781119385974](https://dokumen.pub/img/200x200/project-management-case-studies-5nbsped-2016056664-2016057574-9781119389156-9781119389163-9781119385974.jpg)
![Project Management for Mobility Engineers: Principles and Case Studies [1 ed.]
9780768093612, 9780768093575](https://dokumen.pub/img/200x200/project-management-for-mobility-engineers-principles-and-case-studies-1nbsped-9780768093612-9780768093575.jpg)
Citation preview
Project Management for Mobility Engineers Principles and Case Studies An SAE Handbook
Angelo Mago
Project Management for Mobility Engineers: Principles and Case Studies
Project Management for Mobility Engineers: Principles and Case Studies ANGELO MAGO
Warrendale, Pennsylvania, USA
400 Commonwealth Drive Warrendale, PA 15096-0001 USA E-mail: [email protected] Phone: 877-606-7323 (inside USA and Canada) 724-776-4970 (outside USA) Fax: 724-776-0790 Copyright © 2020 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; e-mail: [email protected]; phone: 724-772-4028; fax: 724-772-9765. Library of Congress Catalog Number 2018962425 SAE Order Number R-470 http://dx.doi.org/10.4271/R-470 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. ISBN-Print 978-0-7680-9357-5 ISBN-PDF 978-0-7680-9361-2 ISBN-ePUB 978-0-7680-9359-9 ISBN-PRC 978-0-7680-9360-5 ISBN-HTML 978-0-7680-9358-2 To purchase bulk quantities, please contact: SAE Customer Service E-mail: [email protected] Phone: 877-606-7323 (inside USA and Canada) 724-776-4970 (outside USA) Fax: 724-776-0790 Visit the SAE International Bookstore at books.sae.org
contents Foreword xv CHAPTER 1
Project versus Program Management
1
1.1 Defining Project Success for Mobility-Based Projects 1 1.2 Issues Facing the Automotive Product Manager and the Project Manager 3 1.3 Defining the Automotive Project 4 1.4 Beginning and End of the Automotive Project 6 1.5 “Beginning” Documentation Requirements for an Automotive Project 7 1.5.1 Contract 7 1.5.2 Feasibility Assessment 8 1.5.3 System Level FMEA 10 1.5.4 QFD Matrix 12 1.5.5 Project Charter 12 1.6 “End” Documentation Requirements for an Automotive Project 12 1.6.1 Product 13 1.6.2 PPAP 13
1.6.2.1 They Begin the Process Too Late
13
1.6.2.2 The Delivered Product is Not a Fully Production Intent Product
14
1.6.2.3 Lack of Understanding of the Term “Saleable Product” 14
1.6.3 Lessons Learned (LL) Report 1.7 Defining Project Management 1.8 Project Management Models 1.9 Project Manager Competencies 1.10 Governing Standards for Automotive Project Management References
©2020 SAE International
15 15 16 16 18 20
v
vi Contents CHAPTER 2
Introduction to Project Management Body of Knowledge
21
2.1 Life Cycle Models 2.2 PRODUCT Life Cycle 2.2.1 Conceptual Phase 2.2.2 Definition Phase 2.2.3 Production Phase 2.2.4 Operational Phase 2.2.5 Divestment Phase 2.3 PROJECT Life Cycle 2.4 Common PROJECT Life Cycle Models for Automotive 2.4.1 Concurrent Engineering Product Development 2.4.2 V-Model 2.4.3 Evolutionary prototyping (EP) 2.4.4 Spiral Model 2.4.5 Agile (SCRUM)
21 22 22 22 23 24 24 24 25 26 27 28 29 30
2.4.5.1 Components of Agile
31
2.4.5.2 The SCRUM Team
32
2.4.5.3 Challenges Associated with Agile
32
2.5 Project Management Life Cycle
33
CHAPTER 3
Introduction to Robust Design Techniques
37
3.1 Project Manager’s Guide to Robust Design 3.2 Why RDM? 3.2.1 Threshold Attributes 3.2.2 Performance Attributes 3.2.3 Delighter Attributes/Exciters 3.3 When RDM? 3.4 What Is RDM? 3.4.1 Quality Function Deployment (QFD) or House of Quality
37 38 39 39 39 40 41 41
3.4.1.1 Benefits of QFD
41
3.4.1.2 Deployment of QFD
43
3.4.1.2.1 QFD Application Case Study
3.4.2 (Functional) Block Diagram 3.4.3 Parameter (P) Diagram 3.4.4 Interface Matrix
43
44 45 46
Contents
3.4.5 Failure Mode and Effects Analysis (FMEA)
48
3.4.5.1 FMEA as Risk Management
48
3.4.5.2 FMEA as Product Liability Protection
49
3.4.5.3 Types of FMEAs
49
3.4.5.4 When Is an FMEA Used?
49
3.4.5.5 FMEA Review of PMs
49
3.4.6 Design for Manufacturing/Assembly
51
3.4.6.1 What Is Design for Manufacture and Assembly?
52
3.4.6.2 Objectives and Benefits of a DFMA study
52
3.4.6.3 Types of Design for Manufacture and Assembly Methods 53
3.4.6.4 When Is DFMA Applied?
54
3.4.6.5 Challenges of Applying a Robust DFMA Process
54
References
56
CHAPTER 4
Managing Stakeholder Influence
57
4.1 Stakeholder Management 4.2 The Stakeholder Management Process 4.3 Identifying Stakeholder and Their Roles 4.3.1 Case Study 4.3.2 Stakeholder Members 4.3.3 Unique Role of the Project Sponsor 4.4 Stakeholder Management Techniques 4.4.1 The Stakeholder Register - Identification 4.4.2 The Stakeholder Engagement Matrix - Management 4.4.3 The Stakeholder Power/Interest Grid - Monitoring
57 58 58 59 59 60 61 61 61 63
CHAPTER 5
Project Integration
65
5.1 Introduction 5.2 Project Charter 5.3 Organizational Process Assets (OPA) 5.3.1 Case Study for Design Review as an OPA
65 67 69 69
5.4 TGR/TGW (Lessons Learned Database) 5.5 Engineering Change Management 5.5.1 Engineering Change Management as a Line of Defense References
72 74 75 75
vii
viii Contents CHAPTER 6
Project Scope Development 6.1 Introduction to Scope Planning and Development 6.2 Scope Planning and the Scope Management Plan 6.2.1 PM: Account Manager Project Transition Meeting 6.2.2 Automotive Project Contracting and Technical Feasibility Assessment 6.2.3 Basic Contract Types Used in Automotive Scope Development
6.2.3.1 PRODUCT Scope Definition Documents
6.2.3.1.1 6.2.3.1.2 6.2.3.1.3 6.2.3.1.4
Requirements and Traceability Matrix (RTM) Product Definition Specification (PDS) Statement of Requirements (SOR) Statement of Work (SOW)
77 77 78 78 80 81 82 82 82 82 82
6.2.3.2 Letter of Intent–Letter of Agreement (LOI/A)
83
6.2.3.3 Relationship between Statement of Work (SOW) and Statement of Requirements (SOR)
84
6.2.3.4 Case Study: Contrasting Use of the SOR versus SOW
85
6.2.3.4.1 Customer SOR 6.2.3.4.2 SOW Statement 6.2.3.4.3 WBS (Individual Task Statements) 6.2.3.4.4 SOW Statement 6.2.3.4.5 Individual Task Statements (WBS)
85 85 85 86 86
6.3 Detailing the Scope—Work Breakdown Structure (WBS) 6.3.1 WBS Definition 6.3.2 WBS Purpose and Advantages 6.3.3 WBS Structure and Types
87 87 87 87
6.3.3.1 PRODUCT WBS
88
6.3.3.2 Organizational WBS (OWBS)
90
6.3.3.3 Hybrid WBS
6.3.3.4 Phase WBS
6.3.4 WBS Decomposition 6.3.5 WBS Levels 6.3.6 WBS Work Package Size 6.3.7 Assignment of WBS to Project Team Personnel 6.3.8 WBS: Additional Considerations 6.4 Scope Validation 6.5 Monitoring and Control of Project Scope Changes References
91 91
92 92 92 93 93 94 94 97
CHAPTER 7
Design Review Process for Mobility
99
7.1 Introduction 7.1.1 Defining the Design Review Process 7.1.2 Why Have Design Reviews?
99 99 100
Contents
7.1.2.1
Customer and/or QMS Requirement
7.1.2.2 Low Cost Insurance Against Product Liability
101
7.1.2.3 Knowledge Transfer Leading to Best Practices
102
7.1.3 Design Review Process as Risk Management 7.1.4 Design Review Planning, Protocol, and Roles 7.1.5 Design Reviews: Categories Peer Reviews
101
102 104 106
7.1.5.1
7.1.5.2 Technical Design Review
7.1.5.3 Phase or Gate Review
107
7.1.5.4 Executive Review
109
7.1.6 Design Reviews: Types and Timing
106 107
109
7.1.6.1 SRR—System Requirements Review
7.1.6.2 PAO or Project Kick-Off Meeting
111
7.1.6.3 CDR: Critical Design Review
111
7.1.6.4 TRR: Test Readiness Review
111
7.1.6.5 PRR: Production Readiness Review
112
7.2 Case Study Design Review Issue: Challenger Mission References
110
112 114
CHAPTER 8
Identifying and Managing Costs/Procurement and Supplier Quality 8.1 Introduction and Overview 8.2 Cost Management Plan 8.2.1 Develop Project Cost Mapping 8.2.2 Selection and Administration of Supplier Contracts
115 115 117 117 118
8.2.2.1 Factors to Consider in Determining the Type of Contract
119
8.2.2.2 Categories of Contracts
119
8.2.2.3 Sub-Categories of Contracts Specifically Used in Automotive
119
8.2.2.3.1 Letter of Intent/Agreement (LOI/LOA) 8.2.2.3.2 Statement of Requirements (SOR) 8.2.2.3.3 Engineering Statement of Work (ESOW) 8.2.2.3.4 Special Case Contracts—BPA and BOA
8.2.3 Closing Thoughts on Contract Selection 8.3 Cost Estimation 8.4 Determination of Project Budget 8.5 Control of Project Costs 8.5.1 Documenting Cost Management
119 120 120 120
121 122 123 125 125
8.5.1.1 Project Budget Report Form
125
125
8.5.1.2 PM Dashboards
ix
x Contents CHAPTER 9
Communication Management 9.1 Introduction and Overview 9.2 Case Study 9.3 Communication Planning 9.3.1 Inputs to Communication Planning 9.3.2 Outputs to Communication Planning
129 129 130 132 133 133
9.3.2.1 Communication Management Plan
133
9.3.2.2 Stakeholder Register and Engagement Matrix
134
9.3.2.3 Special Considerations for Communication Security
9.4 Managing Communications 9.5 Controlling and Monitoring Communications 9.5.1 The Four Areas to Monitor and Control 9.5.2 Hard vs Soft Communication – the Push – Pull System 9.5.3 Engineering Change Management (ECM)
134
135 136 136 137 137
CHAPTER 10
Human Resource Management 10.1 Introduction and Overview 10.2 Organization Structures 10.2.1 Classical or Line Staff 10.2.2 Matrix 10.2.3 Projectized or Silo Structure
10.2.3.1 Spider Web
10.3 Acquiring and Staffing the Resources 10.3.1 Availability and Proficiency Matrix
10.3.1.1 Data Driven Request for Resources
10.3.2 Typical Automotive Project Team Makeup
139 139 139 140 141 143 144
145 146 148
149
10.3.2.1 PRE and POST Core Team
10.3.2.2 Account Manager to PM Transition Meeting Guidelines 150
10.4 Organizing the Project Team and Establishing Performance Metrics 10.4.1 Roles and Responsibilities Matrix (RASI) 10.4.2 Establishing Team Performance Metrics
10.4.2.1 Team-Based Metrics
10.4.2.2 Individual-Based Metrics
10.5 Managing the Project Team 10.5.1 Understanding the Difference Between Leadership and Management 10.5.2 Understanding the Management Continuum 10.5.3 10.5.4 Creating and Documenting Methods of Motivation References
149
153 153 155 155 155
157 157 158 159 160 161
Contents CHAPTER 11
Project/Product Risk Management
163
11.1 Introduction to Risk Management and Product Liability 163 11.2 Historical Background for Product Risk Management 164 11.3 Categories of Product Liability 165 11.4 Communication Protocols for Product Liability 166 11.5 Product Liability Terms 166 11.5.1 General Product Liability Terms 166 11.5.2 Automotive Specific Product Liability Terms 168 11.6 Project Team Responsibility with Regard to Product Liability 169 11.7 Risk Management in PMBOK 171 11.7.1 The Risk Management Plan (RMP) 171
11.7.1.1 Critical Risk Assessments During Scope Development
11.7.2 Risk Identification and Analysis—Basic but Effective Methods
11.7.2.1 Product Risk Analysis Techniques
11.7.2.1.1 Fault Tree Analysis (FTA) 11.7.2.1.2 FMEA 11.7.2.1.3 Hazards Operability Analysis (HAZOP) 11.7.2.1.4 Case Study—Applying the FMEA and HAZOP Process to an Automobile Battery
11.7.2.2 Project Risk Analysis Techniques
11.7.2.2.1 Checklists 11.7.2.2.2 Pros and Cons of Checklists 11.7.2.2.3 Case Study for Lessons Learned—ECM Checklist Linkage Example 11.7.2.2.4 Risk Register and Quadrant Mapping 11.7.2.2.5 Probability–Impact Matrix (P–I Matrix)
11.7.3 Risk Response Planning
171
172 173 173 173 174 175
175 175 176 176 178 180
181
11.7.3.1 Risk Response Strategies
181
11.7.3.2 Risk Response Opportunities
182
11.7.4 Risk Control
183
183
11.7.4.1 Typical Risk Control Formats for Automotive
11.7.4.1.1 Comparison of Problem Solving Methods for Risk 183 11.7.4.1.2 Methods to Evaluate Risk Strategy Alternatives 184 11.7.4.1.3 Expected Value Matrix (EVM) 185 11.7.4.1.4 Production, Pre-Launch, and Prototype Control Plan 188
11.7.5 Writing Effective Corrective Action Statements
189
CHAPTER 12
Automotive Advanced Product Quality Planning
191
12.1 APQP: Introduction 12.2 APQP: Background
191 193
xi
xii Contents
12.3 APQP: Overview 12.3.1 Who Is Involved in APQP? 12.3.2 When Is APQP Applied? 12.3.3 Document Deployment of APQP 12.4 Phase-by-Phase Review of APQP 12.4.1 Concept Phase
12.4.1.1 Quantify Preliminary Voice of the Customer Requirements
12.4.1.2.1 Special (KEY) Characteristics (SC) System
12.4.1.3 Identify Suitable Historical Product(s)
12.4.1.4 Conduct an Initial Assessment of Project Feasibility and Risk
198
12.4.1.5 Investigate New Product Design and Processing Technology
199
12.4.1.6 Identify All High-Risk Sub-Suppliers
198
199
12.4.1.6.1 Determine Product Confidentiality Requirements 200
12.4.2 Program Approval Phase 12.4.2.1 PROJECT Level Tasks
197
196
12.4.1.2 Establish Preliminary Targets and System Level Special (Key) Characteristics 197
194 194 195 195 196 196
12.4.2.1.1 PRODUCT Level Tasks
12.4.3 Prototype Phase 12.4.4 Pilot Phase 12.4.5 Launch Phase
200 201 201
202 203 205
CHAPTER 13
Production Part Approval Process (PPAP) 13.1 PPAP: Overview 13.2 PPAP: Background 13.3 PPAP: Purpose 13.3.1 Purpose of Run @ Rate 13.3.2 Timing of the RUN @ RATE or LINE RATE Event 13.4 Know Your OEM Contacts for PPAP 13.4.1 CUSTOMER Design Release Engineer/Lead Design Engineer 13.4.2 The OEM Level Purchasing Agent 13.4.3 Customer SQA/STA 13.5 Categories Requiring PPAP Submission 13.5.1 When a Formal PPAP Submission is Required 13.5.2 Situations When the Customer Should Be Notified 13.5.3 Special Case PPAP Submission 13.5.4 Situations Where Customer Notification or PPAP Submission is Not Typically Required
207 207 208 209 210 211 211 211 212 212 213 213 214 214 215
Contents
13.6 PPAP Submission Levels 13.6.1 Level 1 PPAP Submission 13.6.2 Level 3 PPAP Submission 13.6.3 Level 5 PPAP Submission 13.6.4 Submission Status 13.7 PPAP Record Retention Requirements 13.8 Discussion of Individual PPAP Requirements 13.8.1 Design Records
215 215 216 216 216 217 218 218
13.8.1.1 Saleable Product
218
13.8.1.2 What is “Black Box”?
219
13.8.1.2.1 A. Black Box 13.8.1.2.2 B. White Box 13.8.1.2.3 C. Gray Box
219 219 219
13.8.1.3 What is the Structure of a Design Record FILE?
13.8.2 Qualified Laboratory Documentation 13.8.3 Appearance Approval Report (AAR) 13.8.4 Sample Product Versus Master Sample Appendix A: Template for the Statement of Work (SOW) Document Appendix B: Sample Project Charter Appendix C: CMP Sample Appendix D: Requirements Traceability Matrix Sample Appendix E: Design Review Types About the Author Index
219
222 222 222
225 237 243 249 253 265 267
xiii
foreword One only needs to scan the shelves of most bookstores and will find there quite a few textbooks that offer the generic “what” and “why” of Project Management (PM). This handbook, however is meant to build on those generic techniques and tailor them to the particularities of the Mobility Industry. The intended audience is the product or design engineer with about 2-3 years of experience in the Mobility Industry, or a project manager, design engineer, or manufacturing engineer who is new to this Industry. The APQP and PPAP processes, which are central to the Mobility Industry, and specifically the Automotive Industry, present unique challenges many of which do not become truly apparent until the project manager or engineer experiences a complete project life cycle, that is, from concept through production. The principles that will be presented here are basic PM principles adapted to address the particularities of the Mobility Industry. My experience as an engineer and project manager in the Department of Defense (DoD) provided me a solid foundation in the operating principles of PM. When I transitioned to Supplier Development for a large OEM responsible for managing and developing suppliers to meet the rigors of the APQP and PPAP processes, I quickly realized I was not prepared for flexibility and pace that PM is applied at the Automotive (OEM) level. The methodologies, the terminology, and mainly the pace of the Automotive Industry are distinct and unique. This handbook therefore is meant as a guide and a template from lessons learned during seemingly endless days and nights in an Original Equipment Manufacturer (OEM) plant during a production launch ramp-up, cleaning up problems that should have been solved at the design phase, or more correctly the quote phase. Or knowing that a supplier will not be paid for large portions of the extra “scope” they have done since the engineering change requests were not properly processed. Add to this the fact that many automotive projects provide the supplier with vague and constantly changing scope of work, which must be delivered against often unrealistic schedules. Having worked on a wide range of products and customers from weapon system programs for DoD to automotive programs for major automotive OEMs, I have had the opportunity to see first hand excellent PM accomplished by both large companies (>1000 employees through small companies (40°C) and poor airflow circulation while the vehicle was idling caused underhood temperatures to spike to a level that exceeded the operating parameters of the battery, resulting in destruction of the battery and leakage of corrosive materials. While this particular incident did not result in harm to the vehicle operators as they were away from the vehicle at the time of the incident, there was certainly warranty and repair costs associated with this failure which potentially could have been avoided through a redesign of the airflow ducting to include the vehicle battery had the project team investigated the full range of fleet operators.
4.3.2 Stakeholder Members Executive and functional level Stakeholders are typically not part of the core project team however they are included on the distribution list for project information. Typical Automotive level stakeholders include, but are not limited to the following. Also be aware that stakeholders can change during the course of the program depending on the nature of the scope or other conditions mentioned earlier. •• Executive Level (any of the following can operate as a project sponsor) ▪▪
VP of Operations
▪▪
Engineering Director
▪▪
Program or Platform Directors (as opposed to Project Managers)
▪▪
Plant Manager
▪▪
Customer
CHAPTER 4
4.3.1 Case Study
60
Project Management for Mobility Engineers: Principles and Case Studies
•• Functional Level ▪▪
Engineering Manager
▪▪
Manufacturing Engineer
▪▪
Tooling and Equipment
▪▪
Purchasing and Supplier Quality
▪▪
Quality Manager
▪▪
IT
▪▪
Test Lab Manager
▪▪
Human Resources
▪▪
Legal
▪▪
High Impact Suppliers
4.3.3 Unique Role of the Project Sponsor Within the realm of stakeholders there is the Project Sponsor. Sponsors fit all the definitions of stakeholder given above with the addition that the sponsor provides project resources and is the signatory of the Project Charter.ii The sponsor, also referred to in the Automotive Industry as Project Champion, is the funding authority for the project and thus oversees spending levels and allocation of funds during the project life cycle. As was mentioned in a previous chapter most Automotive Supplier level project managers do not have total funding authority for their projects as is the case in other industries such as DOD, Aerospace and Construction. This, coupled with the fact that most Automotive Suppliers do not have the concept of “obligated funds” iii can cause severe hardships on the progress of a project since the funds that were originally “committed” to the project can be easily reallocated to another project. In DOD, Federal Acquisition Regulations (FAR) require that funds be identified and committed to distinct projects. When federal approval is received to begin the project those committed funds become obligated and cannot be used for purposes other than the designated project without formal review and redistribution. In this case the Supplier level project manager on a DOD project is confident that the funds requested to accomplish the project will be available when needed. This level of security is not present in the Automotive Industry as most organizations do not necessarily adhere to this “obligation” of funds. An Automotive project manager who does not actively communicate with the project sponsor and stay aware of the status of his project in the scheme of other ongoing projects, can suddenly find himself short or absent of critical funding when needed. This is especially critical in situations where the parent company of an Automotive Supplier is a financial holding company that assesses project continuation on its ability to generate profit for shareholders and product design is a secondary consideration. The project manager, in this situation, must cultivate a close and continuous relationship with the project sponsor to determine where his project stands with respect to the organization’s financial and market objectives. This is why the Project Charter is such an essential document for the Automotive Project Manager since it establishes the documented contractual relationship between the project sponsor and the project manager. Additionally most suppliers conduct monthly executive level ii iii
Project Charter will be discussed in detail in chapter 5, Integration Management. The terms “obligated” and “committed” funds will be defined in Chapter 8 – Cost Management.
4.4 Stakeholder Management Techniques
61
program reviews to evaluate all ongoing organizational projects.iv Typically the project manager from each project will brief the executive staff on their progress and voice concerns regarding resourcing needs. Thus this forum provides the project manager the opportunity to see where his project ranks with respect to other projects.
4.4 Stakeholder Management Techniques Each of the aforementioned stakeholders need to be identified and understood in terms of their level of power and level of interest. This assessment of each stakeholder should be performed in an organized manner to promote data-driven discussions on who is to be managed, how they are to be managed, and to what extent this management needs to be. To aid the project team in managing stakeholders there are several easy to use techniques that have proved valuable in assisting the team to identify, organize and develop an action plan to address stakeholder concerns and are given in Table 4.1.
4.4.1 The Stakeholder Register Identification CHAPTER 4
The Stakeholder Register (figure 4.1) offers three distinct pieces of information. First the register identifies, by name, each project stakeholder, both internal and external so that each member of the Project team is aware of the stakeholders they will be potentially interacting with. Second the register documents what the Project Team’s expectations are with regards to each stakeholder. Third, the right hand of the register is a SWOT analysis from which the Core Project Team would then develop an action plan with regards to how each stakeholder needs to be managed. The time spent to develop the Stakeholder Register will offer significant benefits towards understanding the motivation factors of each stakeholder thus helping the PDT achieve proper and complete communication among all levels of stakeholders.
4.4.2 The Stakeholder Engagement Matrix - Management From the information collected in the S/H Register, the team can then develop a picture of where each stakeholder is with regards to project involvement and where the team needs them to be. This can be graphically accomplished through use of a Stakeholder Engagement Matrix (Figure 4.2) where “C” stands for the current level of engagement of that stakeholder and “D” indicates the desired level of engagement. Referring back to the Stakeholder Register in Figure 4.1, TABLE 4.1 Stakeholder Management Techniques you notice that in the case of B. Carmen, according to the Engagement Matrix (figure 4.2) he is currently RESISTANT Management Technique Purpose and Objective to the project but the expectation is for him to be Project Stakeholder Register Identification and SWOT Sponsor and to be LEADING since as Engineering Director analysis of stakeholders his area will be providing the design support for the project. Stakeholder Management of stakeholders Engagement Matrix In the case of Barb French, VP of Operations, she needs to become aware of the project and become supportive since Stakeholder Power/ Monitoring of stakeholders Interest Grid the “expectation” is that her office will be providing both © SAE International. All rights reserved iv
Chapter 7 provides more information regarding the Executive Program Review.
62
Project Management for Mobility Engineers: Principles and Case Studies
FIGURE 4.1 Sample Stakeholder Register.
© SAE International. All rights reserved
4.4 Stakeholder Management Techniques
63
© SAE International. All rights reserved
FIGURE 4.2 Sample Stakeholder Engagement Matrix.
financial and resourcing support to the project so this is something that the project manager wants to address quickly to get a “read” on where she stands with regards to this project. In the case of Art Freeman, Quality Manager, no effort is required since his current and desired levels of engagement match.
Finally, the PDT needs to assess the level of control or monitoring that each of the identi fied stakeholders needs to have. The Power/Interest Grid works as a quadrant map upon which is plotted the team’s numeric assessment of both the level of influence or power the particular stakeholder possesses and the level of interest the team decides that same stakeholder has in the project. (see figure 4.3)
© SAE International. All rights reserved
FIGURE 4.3 Sample Stakeholder Power/Interest Grid.
CHAPTER 4
4.4.3 The Stakeholder Power/Interest Grid - Monitoring
64
Project Management for Mobility Engineers: Principles and Case Studies
The Matrix breaks out into four (4) specific quadrants c orresponding to the risk and level of control each stakeholder presents. (see Table 4.2). In some cases it is necessary that the Risk Stakeholder stakeholder have a high degree of interest (e.g.) and control Presents Action to be Taken while other situations require that the level of control exerted High Risk Manage Closely over the project is minimized. This technique is the Power/ Medium Risk Keep Satisfied Interest grid which plots these two factors graphically and Keep Informed provides the team an ongoing picture of where each of the Low Risk Monitor – Minimal effort stakeholders are and what level of monitoring or control required is required. © SAE International. All rights reserved For the example grid provided in figure 4.3 our stakeholder monitoring breaks out as follows:
TABLE 4.2 Stakeholder Power/Interest
Grid – Risk Assessment
Keep Informed - B. French, VPO Manage Closely - B. Carmen, Eng Monitor - A. Freeman It is important to keep in mind that each of these documents will need to be updated as stakeholders are added or removed or their level of interest or involvement changes.
C H A P T E R
Project Integration
5
5.1 Introduction
CHAPTER 5
Before a project can begin, the organization must have a Project Management platform from which the project team can operate. This platform identifies those processes, methods, and techniques that are integral and critical to effectively plan, execute, manage, and control all aspects of the project. Typically, these are expressed as Product Development policies and procedures and, for ease of communication with the customer, are often built in alignment with the organization’s principle customer base. For example, if the organization does a significant amount of business with FORD then in addition to an APQP Product Development Model and PPAP acceptance process that are industrybased (AIAG), the organization would also have reporting formats in accordance with FORD’s FPDS Status Reporting format and use the Phased PPAP acceptance process, while a GM supplier will adhere to the GM Global VDP process and use the reporting formats outlined in their GM-1927 Supplier Handbook. The organization would then most likely use these formats for customers who do not specify any specific product development methodology. This improves workflow and communication within the organization by: •• Creating a Best Practice policy standard for product development for use by all project teams •• Avoiding confusion when communicating between various project teams •• Minimizing and standardizing the amount of project level documents and improving document flow •• Creating an easier reporting method when conducting executive review of all projects within the organization
©2020 SAE International
65
Project Management for Mobility Engineers: Principles and Case Studies
Of course, there will be some level of customization by the organization when applying established customer formats to other customers. However, the use of existing platforms that have a proven track record of success helps the organization quickly build workable and scalable templates and helps to avoid labor expended unnecessarily by “reinventing the wheel.” As a starting point, let us identify the basic components of Project Integration as defined by PMBOK: 1. Project Management Plan 2. Project Charter 3. Project Plan Execution a. Direct and Manage b. Monitor and Control 4. Establishing Change Control mechanisms The Key Output of Project Integration is a documented Project Management Plan (PMP) that identifies the high-level project requirements, business goals and objectives, project risk management methods, and essential organizational processes, including software, which will enable the project team to manage and document the project through its life cycle. The PMP is project-specific and is a combination of the Project Charter and the Organizational Process Assets to be used during the conduct of the project and also refers to organizational applicable policies and procedures, the contracted specification, and customer reporting formats (as applicable). Table 5.1 summarizes each of these elements. Note that the elements listed under Contracted Specifications is covered in Chapter 8. TABLE 5.1 Sample integration elements of a Project Management Plan
Contracted specification
SOR or ESOW document, which defines the Voice of the Customer (VOC) such as project performance goals, shared tasks, master timeline with critical milestones, cost estimates, resourcing and testing requirements, and deliverables.
Project charter
Describes PM responsibility, authority, and organizational commitment. Identifies basic organizational requirements to support the project as well as project objectives, success criteria, and deliverables often by phase.
Organizational process assets (OPA)
Governance — Organization Policies and Procedures Project formats as required by the organization. This could be a reflection of Industry standards such as APQP and PPAP and/or customer specific processes such as GM VDP or FORD FPDS. Examples include procedures such as conduct and content of Design Reviews, Supplier Rating, test reporting (DVP&R), software (Microsoft Project), Engineering Change Management, etc. Organization Knowledge Base A listing and description of the controls, methodology, and organizational roles and responsibilities (RASI) needed by the Project Team. Chief among these is the Project Management Plan template. Many of these systems track integrity of project outputs. Examples of some essential databases and methods include: RMP, CMS, LL, EVA, FMEA, CMP, HRP, AVL, 7M, 7QC, etc.
© SAE International. All rights reserved
66
5.2 Project Charter
67
5.2 Project Charter The Project Charter is a high-level document that serves as a roadmap and establishes boundaries, and authority for the project. This document is widely used in the DoD, Aerospace, and the Construction Industries to clearly define boundaries and responsibilities between the supplier and the customer. Recall, however, the discussion in Section 1.5.5 of Chapter 1 where the Project Charter was described as the “internal” contract that exists between the PM and the Organization. The Project Charter, when signed by the project sponsor, (i.e. the person(s) who will provide the necessary resources for the project) establishes a “contractual” obligation between the PM and the Organization (as represented by the Project Sponsor). This level of formality establishes the high level project objectives expected of the PM against which his performance will be evaluated at project end AND helps ensure that the PM has an advocate who commits to provide the necessary resources and will act to intervene as necessary to negotiate internal conflicts regarding resource availability and external conflicts such as runaway scope creep by the customer. All too often in Automotive the PM is “verbally” promised the full support of the organization at the project kick-off meeting only to later discover that this support has quickly evaporated leaving a small group of core team members working late hours and weekends performing the bulk of the project scope. By having the Project needs, authority, and boundaries clearly spelled out in a written format, as it is done on DoD and Aerospace projects, all stakeholders are able to appropriately plan for the allocation of required resources and gives the PM a degree of leverage when resources change during the course of the project. An example of a simple yet concise one-page (mini) Mobility type Project Charter is shown in Figure 5.1. A more extensive Project Charter for larger projects is given in Appendix B. The elements of a detailed level Project Charter include:
•• Goals/objectives: Specific, measurable items the project team is focused on to help achieve stated customer expectations. •• Metrics: A list of progressive metrics which serve to indicate acceptable progress towards critical success factors and goals/objectives of the project. •• Critical success factors: Actions the team must perform to ensure acceptable attainment of customer objectives in terms of product functionality, validation, and manufacturability •• Stretch goals: Areas that can provide added value to the project such as improvements that would be considered value-added by the customer such as advances in design or processing technology. •• End products/deliverables: Describe the item(s) the team is responsible for delivering, both products and documentation •• Authority and accountability: Describe what team members are allowed/not allowed to do without authorization from a higher level. •• Project schedule: This is the customer’s Master Timing Schedule, not internal schedule •• Team membership: List both core team and auxiliary members and contact information. Be sure to include customer and key supplier, and project sponsor contact information.
CHAPTER 5
•• Formal authorization to proceed with the project and permission for the project team to expend resources.
68
Project Management for Mobility Engineers: Principles and Case Studies
FIGURE 5.1 Sample one-page Project Charter.
Project Charter - CS-345 Bracket Assembly Project Project Manager
Air Cleaner Bracket Assembly
Project No.
GOCAR CS-345
Silvia Dody
Sponsor
VP of Automo ve Products
Project Scope
This project covers all ac vi es and contractual performance requirements for our organiza on to design, develop, validate and manufacture and deliver the CS-345 Air Cleaner Bracket Assembly. This project is our first a empt as a Tier 1 supplier directly to an automo ve OEM. While we do expect a reasonable ROI on this project our main focus is on demonstra ng to GOCAR our capability to successfully deliver all SOR requirements with a vision to increased Tier 1 level contract s
Project Budget
TOTAL - $800,000 (see complete budget breakdown in SS-FIN-609)
Key Milestones
See GOCAR SOR, sec on 2 (GOCAR MTS) Deliverable Item
Key Performance Objec ves
Key considera ons
Alternate Material Study Minimum BSR Weight Target for Bracket Assembly
Hi Med Low
Dimensional
Med
Strength/Durability Use of Returnable Containers Ease of Installa on at OEM plant
Med Hi Low
Demonstrated Cpk
Hi
Zero (0) TGW at Launch Ramp-up
Hi
Test Support IAW Sec on 4.3.4 Meet Warranty Target Constraints No target value provided for BSR No customer funding provided for gaging No in-house capability to conduct material studies Ability to meet JIT requirements set by GOCAR
No in-house exper se with Unigraphics Cri cal Success Factors
Risk Level
Hi Low
Brief Descrip on of Risk No experience with material other than steel Customer approval of requested waiver No data on dimensional stability of proposed alternate materials No data on dimensional stability of proposed alternate materials Customer is on Cri cal Path Current CpK capability below SOR requirement No experience with the requirements of an Automo ve Launch event Customer controls tes ng facili es and planning
Assump ons Minimum BSR target value to be set at 40dB for prototype demonstra on Gage funding to be set at 12% of project tooling budget No addi onal employees will be hired for this project but contract help is authorized Parallel Path schedule to be developed for final bracket material selec on to address inability to qualify alternate materials Procure a Unigraphics license for four (4) seats for this project
Properly define a Best-In-Class product according to GOCAR standards Maintain program cadence in accordance to GOCAR master ming Procure skilled resources to conduct a valid alternate materials study Secure a staging facility to deliver brackets Achieve warranty targets specified in the GOCAR SOR Signatures
Sponsor Project Manager
Signature
Date
Signature
Date
© SAE International. All rights reserved
Business Need
5.3 Organizational Process Assets (OPA)
69
•• Roles and responsibilities: List specific assignments for improving team performance (e.g., timekeeper, recorder or scribe, scheduler). Also, list specific tasks and/or action items the team is assigned to complete •• Resources required: Describe the funding, materials, equipment, support, etc., which the team needs to complete its mission •• Project organizational structure: Define how the project team will be structured; classic, matrix, projectized, or other •• Project constraints: Listing of any factors that limit the project team’s options in terms of schedule, resources, test capability, manufacturability, etc. •• Project assumptions: Listing of any assumptions that must be made by the project team to allow project completion, which can include assumptions to address performance gaps or undefined metrics, or identified constraints. •• Operating agreements/ground rules: List agreed-upon guidelines describing how team members will interact, what processes they will use, and what they expect of one another.
Once the project is defined and authorized by the Project Charter, the project team, in order to have any chance of project success, must have at their disposal key assets that are provided to them by the organization, which provide the team processes essential to effective and timely execution of the project deliverables. Hence, PMBOK refers to these elements as Organizational Process Assets (OPA). The formal PMBOK definition for OPA is “plans, processes, policies, procedures, and knowledge bases specific to and used by the performing organization.” Handbooks and standards such as the IATF-16949, AIAG APQP, and PPAP are generic in nature and do not contain adequate detail to serve as an organizational policy or procedure and only serve as guidelines from which an organization would build their specific Quality Management System. Recall the example provided in Chapter 1, where a generic feasibility assessment was tailored to address the specific requirements of an Engine Control Module supplier. Another example of an OPA generated from a generic source is the procedure for conduct and documentation of a Design Review process. Figure 5.3 identifies additional areas where organizational policies and procedures specific to an automotive project should be developed. These policies and procedures, namely design checklists and Best Practices form the organizational knowledge base for ECM design which can be used by both product engineers new to the organization as well as senior engineers.
5.3.1 Case Study for Design Review as an OPA While the Design Review Process is covered extensively in Chapter 7 it would be beneficial here to present an example of how the DR process can become an effective OPA.
CHAPTER 5
5.3 Organizational Process Assets (OPA)
70
Project Management for Mobility Engineers: Principles and Case Studies
Using again the example of the Engine Control Module (ECM) we can demonstrate the evolution of a Design Review Process. Most policies and procedures start from a generic requirement based on a standard or customer specification. As a starting point we begin with the DoD based IPPD definition of the objective of the Design Review which is “a means to search out design weaknesses, faulty designs, or designs that may be cost drivers.” IPPD identifies the following as minimum documents: •• Requirements Traceability Matrix (RTM) •• Hardware Design Documentation •• Software Design Documentation •• Interface Design Description •• Test Plans •• Risk Assessments and Mitigation Plans Next, using the AIAG APQP handbook Design Reviews are defined as regularly scheduled meetings led by the organization’s design activity to prevent problems and misunderstandings and a mechanism to monitor progress, track design verification progress, report to management, and obtain customer approval. The APQP handbook identifies similar documentation as does DoD with the addition of automotive-specific items such as: •• Reliability and confidence goals •• Computer simulation and bench testing results •• Component/subsystem/system duty cycle evaluations •• System and Design FMEAs •• Design of Experiments (DOE) •• Design Verification Plan and Report (DVP&R) Either of these is not of sufficient detail in and of itself to be useful or effective as an organizational level Design Review format but can provide a basis from which an Organizational Process Asset (OPA) can be constructed. The Engine Control Module supplier would use the DoD and APQP handbooks as an outline and add to it the specific requirements as ECM designs. Figure 5.2 represents an extract of a Design Review Agenda for a System Requirements Review (SRR) that has been tailored from the DoD and APQP guidelines to address specific concerns of the ECM designers. This format serves not only as a format for conducting SRR Design Reviews but can also serve as a Best Practice for new designers, as well as part of the quotation process used by the sales department, in absence of technical support, to ensure the proper input information has been received by the Engineering group to allow for a successful design. Notice that this tailored DR agenda utilizes the DoD concept of a Require ments Traceability Matrix (RTM) and questions specific to hardware, software, and interface, but written in a manner specific to the ECM design. Also notice that elements from the APQP handbook such as Project Schedule, FMEA, DVP&R, and Reliability goals are in a similar manner identified but tailored to the design concerns of the ECM.
5.3 Organizational Process Assets (OPA)
71
© SAE International. All rights reserved
FIGURE 5.2 Sample SRR Design Review tailored to ECM projects.
© SAE International. All rights reserved
CHAPTER 5
FIGURE 5.3 Listing of additional policies and procedures for an automotive project.
72
Project Management for Mobility Engineers: Principles and Case Studies
5.4 TGR/TGW (Lessons Learned Database) One of the sources of this organizational knowledge base that was referred to above is the Lessons Learned (LL) database and is therefore another OPA. Although the term Lessons Learned (LL) is very common in most industries, within the automotive industry the term most commonly used is TGR/TGW. This stands for Things Gone Right-Things Gone Wrong. The idea behind this is not just to create a new acronym but to emphasize the fact that every project needs to be evaluated not only for Things Gone Wrong, which will lead to corrective actions, but also to identify Things Gone RIGHT on the project, which then become Best Practices. Yes, every project has things that go wrong, but equally so, every project has things which have gone right. Most times it is very difficult for the PDT to identify the TGRs. TGWs are easy since they will become corrective actions and most companies have a well-developed process for tracking and validating corrective actions. TGRs are equally important since they become company best practices. If the design group for a current project, for example, uses a new method of deep well stamping, or a new program for conducting a Design Rule review for a PCB layout, and it is successful, this needs to be identified as a TGR, which can then become a best practice for future projects. Other examples include such things as new materials that were evaluated and offer a higher degree of durability, a simpler and more effective method for tracking man-hour expenditure, or use of a new piece of test equipment that has the capability of adding several more critical test features. For this reason, TGR/ TGW inputs must include both DESIGN issues, captured in the Technical Design Reviews, and RESOURCING issues captured through the Phase (or Gate) Reviews. The following represents typical policies of the automotive industry with regard to the TGR/TGW database: 1. At the beginning of any project the Project Team should select a product that, as close as possible, matches the design and manufacturing characteristics of the proposed or quoted project. 2. The TGR/TGW database information from this project must be used to analyze the initial Feasibility Assessment, prior to contract award or start of the project. 3. The TGR/TGW database must be updated at each critical milestone of the project development life cycle and at the end of each project phase to ensure all levels of product and project issues are captured. The reason for this is that if the project team waits until the end of the project they have forgotten most of the issues that occurred upstream of the product development process so that most of the issues they capture will have a manufacturing or production focus. 4. To the extent possible, the TGR/TGW database must accurately reflect design and manufacturing Lessons Learned and that data must be accessible at an organizational level, such as on a company share drive, so that data can be effectively accessed and sorted by the project team. While there are several software programs that can create sophisticated databases, it is suggested to start out with a simple system such as a field-driven EXCEL based format. Once the PDT becomes comfortable documenting LLs, they can work with the IT department to build an internal LL database system that meets the specific needs of the organization without the high cost of implementing a generic software package that needs to be modified. The database should reside on the companywide share drive, which can be password protected to avoid unauthorized use. Figure 5.4 shows an example of a simple EXCEL-based TGR/TGW format.
5.4 TGR/TGW (Lessons Learned Database)
73
Before we close the section on TGR/TGW, it is important to note the stages of development of a TGR/TGW knowledge base. Another reason to maintain and update a TGR/TGW database is to increase Knowledge Management, which leads to Best Practices being deployed throughout the organization. This objective is not obtained instantly and requires an understanding of the stages through which an organization progresses in the management of design knowledge. To this end, a distinction must be made between information, data, and knowledge: •• Information relates to description, definition, or perspective (what, who, when, where). •• Data is information that is structured, but has not been interpreted. •• Knowledge is information that has a use or purpose to which an intent has been attached. Information collection is the first stage the organization goes through when beginning to assemble a Lessons Learned database. This INFORMATION stage translates to individual project teams identifying and collecting bits of product information particular to their projects obtained from multiple sources; production floor, testing,
CHAPTER 5
© SAE International. All rights reserved
FIGURE 5.4 TGR/TGW Lessons Learned summary report format.
74
Project Management for Mobility Engineers: Principles and Case Studies
simulation studies, warranty and filed analysis, suppliers, and the customer. At this stage, however, it is difficult, if not impossible, for the organization to benefit from knowledge sharing since there is no requirement other than to collect data. At the DATA stage, the organization begins to appreciate that individual projects can benefit from data sharing and thus begins to consolidate this data into an organizational level database accessible to all project teams. Unfortunately, most supplier organizations make the use of these databases optional and at the discretion of the project team. Another issue is that the data, which stored in a structured manner, is not INTERPRETED, meaning that there is no easy way to sort or manipulate the data for ease of use by a project team. For example, if the project team needs to know specific past issues regarding dimensional concerns or styling concerns, the TGR/TGW database cannot present the data in this “sorted” format, creating difficulty in using the database information, such that the project team tends to avoid using the database. At the final or KNOWLEDGE stage, the information has been structured into a database and can be categorized and sorted to meet the specific needs of the project teams. There is also an organizational requirement in the Product Development life cycle for the project team to select a similar product and extract data with regard to identifying and avoiding past issues, identifying company best practices that should be adhered to, and opportunities for design for manufacture and assembly. There is now a specific INTENT with respect to use of the TGR/TGW database and this creates a desire on the part of project teams to populate the database with useful information.
5.5 Engineering Change Management Engineering Change Management, or Configuration Management, is defined as the control and recording of changes made to a product throughout its Project Life Cycle with respect to the product’s hardware, software, and related documentation. The specification document(s), engineering release, and drawing discipline are managed by documentation requirements established by the change management plan. An effective change control system contains the following features: 1. It is tailored from an effective set of guidelines and standards. 2. It is streamlined, yet encompasses the entire life cycle of the project, recognizing the requirements of each phase of the life cycle. 3. It establishes the mode of operation and interface relationship among the company, subcontractors, and customer(s). 4. Dynamic change control boards and resource tracking systems are linked and updated in a timely fashion. While most organizations have some type of Change Management process, for maximum effectiveness the change management plan should be tailored by the project team to fit the nature of the project. For very large projects the Change Management Process is initiated at the Quote Phase. This is because the time invested in preparation of a system level quotation could result in a significant number of man-hours expended. For some DoD projects this could be anywhere from 500-5000 man-hours which could be costly to the organization providing the quote so there are allowances for the supplier to recover some of these preparation costs. For the vast majority of Mobility contracts,
References
75
however, the Change Management process begins when the contract is signed but certainly no later than the beginning of the product development phase, typically before the Theme Selection baseline is stabilized. Proper allocation of staffing, authority, and responsibility are essential to the success of change management within an organization and an effective change management system recognizes need for discipline regarding the process of documenting and controlling project scope change. To this end, training of all team members in the use of the change management system is essential for a complete and timely transfer of data to affected stakeholders during the project.
The Engineering Change Management System (ECMS) must be understood as the first and most important line of defense in identifying and controlling project scope creep. Data reports from the ECMS feed the project performance reports such as Earned Value Analysis (EVA) and aid the PM in rapid identification of problem areas such as man-hour overages, resourcing cost overruns, and managing project budget burn rates. Many PMs try to control scope creep but making themselves the focal point for all project scope changes. This quickly becomes ineffective, time-consuming, and burdensome, especially in Automotive where scope change can occur at a rapid pace and require significant resourcing, which can quickly consume the project budget or worse this bottleneck can dramatically affect a smooth design evolution. Rather, the PM should enforce a discipline of adherence to proper processing of engineering changes, especially those that originate external to the organization, such as from the customer or supplier. This allows for the smooth flow of communication between organization-customer-supplier team members since communication occurs among peers, that is Customer Engineering talking with Supplier Engineering, Test with Test, and Production with Production. Customers and Suppliers prefer to not waste their time talking about design or production issues through an intermediary. With regards to the processing of Engineering Change requests the rule of thumb in Automotive is as follows: 1. Within 24 h—Change request is generated with required minimum information for analysis and a GO-NOGO decision is provided to the change originator. 2. Within 2 weeks—Change request is fully costed and an implementation date is determined with all required resources identified. Finally, PMs are responsible to ensure that Manufacturing is properly interfacing with Change Management system during every phase of the project and not just after Prototype phase. This includes assessment of any impacts to the organizational ERP systems and the customer APN systems.
References 1. Contracted Specification will be covered in Chapter 6 on scope development. 2. See Chapter 1 Introduction to Automotive Project Management.
CHAPTER 5
5.5.1 Engineering Change Management as a Line of Defense
C H A P T E R
Project Scope Development
6
6.1 Introduction to Scope Planning and Development
CHAPTER 6
Critical to any project is the development of a scope document that reflects the totality of the project being developed. In the early days of Automotive Product Development, scope development for the supplier was fairly simple in that it was the automotive OEM who developed the complete scope package and the supplier provided a design that met the almost cookbook format of the design specification. Recall this is the “threshold” attribute of the Kano model. The financial and timing impacts of the ongoing responsibilities on the part of the OEM for warranty costs, redesign efforts, scope changes, not to mention the time and effort involved in the continuous monitoring of supplier progress resulted in the upward shift of the OEM along the Kano continuum. Engineering Project Managers in Tier 1 organizations today are faced with the requirement to accomplish all of the scope planning effort in addition to the financial and resourcing impacts once carried by the OEM. This chapter covers the steps and methods involved in Scope Planning as it applies to the typical Tier 1 supplier by presenting first the components of scope planning identified by PMBOK and then discussing the nuances and particulars of scope planning within an Automotive project. PMBOK identifies six parts to the Scope Management Process and includes: a. Scope Management Plan (SMP) b. Collecting Voice of the Customer (VOC) Requirements (covered in Section 3 of Chapter 3) c. Defining and Differentiating Product and Project Scope ©2020 SAE International
77
78
Project Management for Mobility Engineers: Principles and Case Studies
d. Detailing the Scope—Work Breakdown Structure (WBS) e. Scope Validation f. Monitoring and Control of Scope Changes
6.2 Scope Planning and the Scope Management Plan Scope planning involves “providing guidance and direction on how [project] scope will be managed throughout the project.” The components of a Scope Management Plan (SMP) will depend on the type of project but for a typical Automotive project the SMP should, at a minimum, include the following: SMP contents description
Chapter coverage
Project Contract—SOR, ESOW, or Letter of Intent/Agreement
5
Intended Product Development Process
2
Signed Project Charter
4
Requirements & Traceability Matrix
12
Roles and Responsibilities Matrix (RASIC)
10
Human Resource Plan (HRP)
10
Work Breakdown Structure (WBS)
6
Facilities Identification and Management Plan
12
Although there could be some degree of documentation overlap, the SMP is not to be confused with the Design Record file that is required as part of the PPAP submission. The Design Record file contains documentation specific to the product performance requirements and the actions taken by the design team to design and validate the product or system [1]. This includes design drawings, CAD files, Design Review records, test plans and results, identification of product risks and mitigation actions, and associated RDM documentation. This is distinct from the SMP, which contains details of the project requirements such as project funding, roles and responsibilities, project resourcing, and project schedule progress and identification of project risks and mitigation actions. PMBOK refers to this distinction when they state that “the term scope can refer to either product scope or project scope.” [2]
6.2.1 PM: Account Manager Project Transition Meeting As with the Project Charter, the SMP should be reviewed and signed by key project stakeholders, especially sponsors, to ensure that there is senior executive buy-in to the project and to determine the level of support, mainly the providing of resources, throughout the project life cycle. This review is usually done in conjunction with a market analysis of the profitability of the customer request with respect to alignment with the strategic business objectives. Most industries on the order of magnitude of the automotive industry have the Project Manager assigned and actively involved in the contract negotiation process and market feasibility analysis. However, among automotive supplier organizations, the norm is that customer Requests for Proposal/Quote (RFP/RFQ) are
6.2 Scope Planning and the Scope Management Plan .
79
evaluated by a core APQP team wherein the Account Manager (working in the Sales & Marketing group) serves in the role of Project Manager. While it is critical for the project team to have some degree of involvement in the technical and resourcing feasibility analysis of the proposed project, it is more important that the Project Manager have some forum, at the outset of the project, to know where he or she stands with respect to organizational support since they will be the one held primarily accountable for the success or failure of the project. Most projects do not fail due to project manager incompetence; they most often fail due to two significant root causes: a. Diminished support by the stakeholders over the project life cycle b. Failure by the project manager to appropriately manage risk and keep stakeholders appraised of these risks in a timely manner The second reason is discussed in the section on the Design Review process. However, in the case of the first reason it is important that once the project manager is assigned to the project the first question he or she should ask the sponsors is; “How does my project fit in with respect to the business strategy of this organization?” There are really only three answers to this question:
Case 1: Here the PM can expect a reasonable amount of support since this product line currently represents ongoing cash flow into the organization, which in addition to supporting ongoing business operations, also provides funding to support other growth and expansion efforts. In this case, the PM has a reasonable expectation of authority over resources allocated to him or her and access to some funding to explore value-added improvements. He or she will most likely not be able to hand-pick their project team but will have them assigned at the discretion of the various departments. Also since this product is most likely stabilized and performs well, it will be difficult to secure funding for major manufacturing changes or design changes that have any possibility of negatively impacting safety, regulatory, or current customer satisfaction. An example of this is the Toyota approach where changes to manufacturing and design occur at an extremely slow pace and only after much analysis and consideration. This type of project is well suited to a new project manager transitioning from Engineering or other department since the new PM can follow a well-documented project “template” and can work under the direction of a seasoned mentor. Case 2: In this case the PM can expect a significant amount of support since this is a new product line that represents a potential increase in cash flow to the organization and a potential expansion of brand identity both for the current and new customer base. These projects are usually the result of an ongoing Research and Development (R&D) effort that has matured sufficiently to bring to market. Oftentimes the PM can tap into additional project funds available from R&D to help ensure the success of design and testing as the product transitions from R&D to production intent. This type of project also gives the PM wide latitude in the selection of project team members since there will most likely be a requirement to hire external talent to address areas new to the
CHAPTER 6
1. This project is associated with the core business of our organization and we expect that the customer base will continue to request this product and/or service. 2. This project is a key part of our overall business strategy expansion and could represent a significant area of growth and market share of our overall business portfolio. 3. This project represents a close-out of this particular product, which has seen reduced market share and orders and will be phased out.
80
Project Management for Mobility Engineers: Principles and Case Studies
organization. Due to the high visibility of this type of project, there are typically few issues regarding authority over the project team resources and scheduling of equipment resources. The downside is that there is a very heavy burden on the PM to make a good “first impression” to the customer and therefore this project is NOT well suited to a new project manager. Selection of a PM should come from the ranks of seasoned PMs and should be someone who is politically astute, can skillfully adapt to rapidly changing situations, and can effectively manage rapid and numerous changes to scope since there will most likely not be a well-documented project “template” to follow. Case 3: Finally, in this case the PM can expect very little support from the organization since any expenditure of funds in excess of the allocated budget will most likely be rejected as it is expected that this product line will be phased out. In this type of project, the PM can expect a minimum number of resources allocated to his or her project and that these resources can be pulled at any time to support more profitable projects such as Case 2 above. He or she will also have difficulty with resource availability in areas such as CAD time, Test Lab time, and prototype build since priority will be given to either current production or new product. With these disadvantages comes the advantage that the PM has more control over limiting scope creep from the customer since the organization does not place a high priority on resourcing of the project. Although this project probably has a well-documented project “template” to follow it is not advisable to assign a new PM to this project since the roadblocks mentioned can be demoralizing to someone who is not ready for them and presents project management in a poor light.
6.2.2 Automotive Project Contracting and Technical Feasibility Assessment With a clear understanding of stakeholder support, the PM and the project team can now focus on assessing the viability or feasibility of the proposed project. In industries such as DoD, Aerospace, and Medical Devices, proposal viability is determined via a fairly exhaustive and comprehensive technical, logistical, and financial feasibility assessment process, which can involve multiple departments and can take up to several months to evaluate before securing a contract. In contrast to this, Automotive Suppliers typically perform abbreviated versions of these feasibility assessments, which are conducted by a Core APQP team led by an Account Manager. There is limited direct involvement of stakeholder departments such as Engineering, Production, Testing, or Quality. This results in poor and incomplete analysis of the technical and resourcing requirements identified in the RFQ/P. By the time the Project Manager and the full project team receive the contracted Statement of Requirements, it is too late to modify difficult or unachievable requirements without incurring significant contract penalties. It is especially problematic and potentially costly when this occurs with customers who either through lack of technical expertise or deliberately submit a vague technical specification. The reasons for conducting the RFQ negotiations in this manner are understandable as it is time and resource prohibitive to allow an in-depth feasibility review of each RFP/Q received by an organization by a full project team, especially when the organization is evaluating multiple contracts on a weekly basis. However, as was presented in Chapter 1, Section 1.5.2, it is possible for the Functional departments such as Engineering, Test, Quality, and Manufacturing, etc., to develop a customized template which would be completed by the Core APQP or contract negotiation team. This template would outline key technical elements that must be present in the RFP/Q to permit a reasonable chance for success by the full project team. Source templates from which to build these
6.2 Scope Planning and the Scope Management Plan
81
technical review formats are the Team Feasibility Commitment Form and the Design Information Checklists provided in the AIAG APQP handbook [3] in conjunction with the customization techniques presented in Section 5.3 of Chapter 5. The PM is responsible to ensure that: 1. The Lessons Learned and Engineering Change databases are effectively capturing emerging concerns and Best Practices, in the areas of design, production and operational issues in the field 2. Project Teams and Functional Department are updating the Feasibility Templates appropriately and in a timely manner 3. Sales and Marketing is using the Feasibility Templates to evaluate all incoming customer proposals
6.2.3 Basic Contract Types Used in Automotive Scope Development In Section 1.6 of Chapter 1, “Beginning” Documentation Requirements for an Automotive Project, two categories of contracts were introduced that are commonly used in establishing a contractual relationship between OEM and Automotive suppliers to define the design and performance specifications of a project: Statement of Requirements (SOR) and Letter of Intent/Agreement (LOI/A). Also referred to in the section was the Statement of Work (SOW). In this chapter, we will discuss the details of these contracts, how and when they are used, and how they relate to one another. Additional discussion of the full range of contract options and types will be presented in Chapter 8 on identifying and managing cost. In order to begin any developmental work effort there are two things that need to be defined: 1. The performance requirements or objectives of the system, product, or service to be provided 2. The tasks required to achieve those requirements or objectives
© SAE International. All rights reserved
FIGURE 6.1 Differences between SOR and SOW.
CHAPTER 6
The documents that capture these requirements are the Statement of Requirements and the Statement of Work. Figure 6.1 highlights the basic difference between these two documents. A third document referred to in Chapter 1 was the Engineering Statement of Work (ESOW), which is a combination of these two documents and is widely used in Automotive.
82
Project Management for Mobility Engineers: Principles and Case Studies
6.2.3.1 PRODUCT SCOPE DEFINITION DOCUMENTS Once the scope of the RFQ/P is agreed to and signed by the customer and supplier, an Engineering Design & Development (ER&D) scope becomes a legally binding contract which typically takes the form of an SOR, an ESOW, or an LOI/LOA. At this point the Core APQP team will assign a Project Manager and a transition meeting will occur between the Account Manager and Project Manager. The Project Manager and the full project team will then develop the formal Project Plan, which consists of the following: 1. Project Charter
Input document
Discussed in Chapter 5
2. Contractual Specification
Input document
Discussed in Chapter 8
3. R equirements & Traceability Matrix
Output document
4. P roduct Definition Specification
Output document
5. Statement of Requirements (SOR)
Output document
6. Statement of Work (SOW)
Output document
6.2.3.1.1 Requirements and Traceability Matrix (RTM). The RTM is typically a
high level performance document and serves to capture and organize all the product performance objectives, Verification/Validation requirements, and identification of customer level key or special characteristics. Additionally, the RTM coordinates traceability requirements between Engineering Design level and Manufacturing and Processing. This document is very helpful when preparing subproject project timing schedules as there is a clear and visible connection between design, validation, and manufacturing tasks. An example of a Requirements and Traceability Matrix (RTM) is provided at Appendix D.
6.2.3.1.2 Product Definition Specification (PDS). The PDS is a complete transla
tion of the performance requirements (ESOW) into a form and language that is under standable by the organization’s Engineering group. A PDS is only necessary when the customer contract language does not provide concise performance objectives. The PDS is used in situations where the customer cannot or chooses not to adequately and concisely define the product and project requirements and instead describes the project in the form of a Letter of Intent/Agreement (LOI/A).
6.2.3.1.3 Statement of Requirements (SOR). The SOR outlines PRODUCT
requirements and serves three primary purposes: (a) establishes the performance of the product at some level—concept, system, or component; (b) documents those; and (c) establishes the external and legally binding contract between the customer and the organization regarding these product performance requirements. Additionally, the SOR is the base document for the Design activity and forms the basis for the conduct of technical Design Reviews. The SOR establishes the “external” and legal contractual relationship between the customer (OEM) and the Organization (supplier). The ESOW, in addition to identifying the performance objectives, also identifies the roles and responsibilities of both the customer and supplier during the developmental life cycle of the project. A template for a complete SOR is given in Appendix A.
6.2.3.1.4 Statement of Work (SOW). The SOW on the other hand outlines the PROJ
ECT requirements which are based on the PRODUCT requirements and defines the high level (system) tasks necessary to accomplish each of the performance objectives outlined in the Customer specification. AN SOW is always written in a TASK format (verb-noun). The SOW, together with the Project Charter, establishes an “internal contractual” relationship between the PM and the Organization with respect to the project task responsibilities.
6.2 Scope Planning and the Scope Management Plan
83
6.2.3.2 LETTER OF INTENT–LETTER OF AGREEMENT (LOI/A) The LOI/A is a short outline of the basic PROJECT requirements so as to provide maximum flexibility to both the customer and the organization’s design and manufacturing capability. There are typically two scenarios when a customer would contract with a supplier through an (LOI/A): 1. A customer who does not possess the level of technical sophistication to draft a complex engineering performance specification such as an SOR or ESOW. An example of this would be a vehicle fleet operator who wishes to order speciality trucks for mining or agriculture or specialized vehicles such as for landscaping or hazardous material loading and transport. In these cases, the customer is not a vehicle OEM and is dependent on the supplier to take general concepts and develop a vehicle that meets the operational requirements and also can provide design recommendations and options that are not apparent to the customer. 2. A customer who deliberately desires to avoid providing concise design details. This gives the customer the advantages of increased freedom to change the design, as well as shift a major portion of the warranty and liability responsibility since the supplier is fully design responsible. The advantage to the supplier is that it gives them the design freedom to pursue alternative solutions to existing or potential design concerns. Chrysler Corporation and Freightliner Truck are examples of OEMs that have used this method of contracting. GM has begun to move in this direction with the advent of Supplier Discovery Day where they invite subsystem suppliers to offer innovative and alternative solutions to new vehicle design. LOI/A contains high-level contract language, which will form the basis of a more comprehensive Statement of Work as submitted by the supplier during the product development life cycle. An example of typical LOI/A language is:
As in the SOR, the LOI/A establishes a “contract” between the customer and the organization regarding product performance requirements and it forms the basis for the contents of the Technical Feasibility Risk Analysis and Concept Phase Review. While use of this form of contract relationship seems enticing to the supplier due to the design freedom offered by the general language of the LOI/A there can be legal difficulties if the supplier attempts to recoup Product Development man-hour costs expended to cover excessive scope creep. The vague nature of the contract scope makes it extremely difficult to determine what is considered to be “inside” or “outside” the scope of the LOI/A. Since the LOI/A offers performance information that is nominal at best, miscalculating the man-hour expenditures of design, testing, and production planning can lead to significant losses that might not be able to be recouped over the production life cycle. It is therefore highly recommended that when contracting with a customer under these circumstances the PM must ensure the following OPAs are operational: 1. A sophisticated cost modeling database, which uses bottoms-up WBS templates that are used to cost out the project 2. An extensive historical Lessons Learned (TGR/TGW) database from which to develop an accurate quote 3. A robust Change Management System, which tracks scope changes and effectively transmits them to a Change Control Board to determine if the scope should be added and how that additional scope will be funded. This is critically
CHAPTER 6
The customer wishes to retain the design services of “XY Supplier” for the purpose of designing a full interior cockpit assembly for the 20xx generation vehicle.
Project Management for Mobility Engineers: Principles and Case Studies
important because if the organization loses control over scope changes (creep), the additional scope can build to the point where it is orders of magnitude greater than the original baseline scope from which the project costs were built. 6.2.3.3 RELATIONSHIP BETWEEN STATEMENT OF WORK (SOW) AND STATEMENT OF REQUIREMENTS (SOR) While qualitative and quantitative design and performance requirements are contained in the Statement of Requirements, the SOW defines a high level overview of the levelof-effort tasks required to accomplish the requirements given in the SOR. This high level of effort will be sub-divided into discrete work packages in the WBS. Together with the WBS (which will be discussed next), the task format of the SOW allows the Project Manager to more effectively track project progress since PROJECT progress is assessed by task completion not by completion of product performance objectives. Project Management by SOR, requires a PM who is knowledgeable of all areas of the product design and many times this degree of expertise is not available especially in cases where the organization has limited resources that do not allow every project to have an experienced PM/Product Engineer. Project Management by SOW/WBS shifts the knowledge base from the Lead Engineer/PM to the SOW since the tasks in the SOW/WBS are developed by the individuals doing the work. Other advantages of the SOW are that it forms the baseline from which to identify resource and man-hour requirements, establish the project budget, track cost and schedule variances as project changes occur (i.e., Scope Control) and forms the basis for conducting Phase or Gate Reviews. Figure 6.2 show a graphic relationship between the SOR and SOW in terms of flow, documentation, reviews, scope control (ECMS) and collection of Lessons Learned information. The Case Study in Section 6.2.3.4 will help demonstrate this relationship between SOR and SOW. In case where the contract used is an LOI/A an alternative to the SOW is the Statement of Objectives (SOO). The SOO eliminates the ‘how to’ instructions to FIGURE 6.2 Relationship and Flow of SOR and SOW.
© SAE International. All rights reserved
84
6.2 Scope Planning and the Scope Management Plan
85
accomplish the required effort normally contained in the SOW and give the customer an opportunity to assess the supplier’s understanding of all aspects of the project. Also, this approach provides the supplier the flexibility to develop cost effective solutions and the opportunity to propose innovative options to both design and manufacturing which will meet the required objectives. 6.2.3.4 CASE STUDY: CONTRASTING USE OF THE SOR VERSUS SOW Using the example of our Engine Control Module, let’s compare what each of the three documents; SOR, SOW and WBS communicate. Let’s assume the following customer performance requirement as identified in the SOR: 6.2.3.4.1 Customer SOR.
ECM shall maintain operational reliability in a temperature and vibration profile of XX SOW statements would correspond to this SOR statement and would define both the task and the responsible area at a high level. 6.2.3.4.2 SOW Statement.
The supplier shall design PCB layouts and corresponding software and select housing geometry and material which will achieve the reliability goals stated in section XX of SOR. From this high-level task statement specific lower level individual tasks would be developed to allow project team members a more concise explanation of what tasks must be accomplished to achieve the goal stated in the SOR. This would also coordinate efforts between various departments and the Project Team. 6.2.3.4.3 WBS (Individual Task Statements)
1. Electronics Design team to design PCB layout and component selection to meet operational reliability within parameters of section X of SOR. 2. Hardware Design team to design housing which isolates and protects PCB from environmental parameters. 3. Software Design team to develop software algorithms and routines which engage protection measures in the event of environmental extremes outside of performance parameter.
Now with detailed tasks identified another advantage of the task based statement becomes evident; improved oversight and control during design reviews. To illustrate this point let’s look at two Design Review scenarios, one where the PM is managing via the SOR and one via the SOW. In either case the question at the Design Reviews is; What is the progress of the ECM design with respect to meeting reliability objectives? In the scenario of project management through SOR, the response received during the Design Review from the Electronics group and the Hardware group were positive. Without specific leading questions, which come from the individual tasks identified above, the PM must depend upon his/her experience with this type of project to ensure all the aspects involved in the ECM development that could impact the reliability performance have been addressed so the PM must depend on the accuracy of the statements made by the Electronics and Hardware groups and assume that the project is on track. The reality
CHAPTER 6
4. Test Lab to develop a DV/PV plan which will adequately simulate the environmental profile identified in section X of SOR.
86
Project Management for Mobility Engineers: Principles and Case Studies
is that the Design Review did not include the Software group who did not receive information on critical design changes made to the PCB layout and no information was given to the test Lab to begin preparing the DV test plan both of which will set the project back several weeks. Contrast that with the scenario of project management through SOW/WBS. Individual tasks have been developed by each of the functional areas involved and provided to the PM. Now it’s a fairly simple task at the Design Review for each Functional Area to provide a progress report against each specific individual task as identified in the WBS. 6.2.3.4.4 SOW Statement.
The supplier shall design PCB layouts and corresponding software and select housing geometry and material which will achieve the reliability goals stated in section XX of SOR. From this high-level task statement specific lower level individual tasks would be developed to obtain a much clearer status of what tasks must be accomplished towards achieving the goal stated in the SOR. This would also coordinate efforts between the Project Team, PCB Design Team, Software Programmers, Hardware Designers, and Test Lab. 6.2.3.4.5 Individual Task Statements (WBS). Another advantage of the taskbased statement is improved oversight and control during design reviews. To illustrate this point let’s look at two Design Review scenarios, one where the PM is managing via the SOR and one via the SOW. In either case the question at the Design Reviews is:
What is the progress of the ECM design with respect to meeting reliability objectives? In the scenario of project management through SOR, the response received during the Design Review from the Electronics group and the Hardware group were positive. Without specific leading questions, which come from the individual tasks identified above, the PM must depend upon his/her experience with this type of project to ensure all the aspects involved in the ECM development that could impact the reliability performance have been addressed so the PM must depend on the accuracy of the statements made by the Electronics and Hardware groups and assume that the project is on track. The reality is that the Design Review did not include the Software group who did not receive information on critical design changes made to the PCB layout and no information was given to the test Lab to begin preparing the DV test plan both of which will set the project back several weeks. Contrast that with the scenario of project management through SOW/WBS. Individual tasks have been developed by each of the functional areas involved and provided to the PM. Now it’s a fairly simple task at the Design Review for each Functional Area to provide a status report with regards to their individual progress against the following tasks originally identified: a. Electronics Design team to design PCB layout and component selection to meet operational reliability within parameters of section X of SOR. b. Hardware Design team to design housing which isolates and protects PCB from environmental parameters. c. Software Design team to develop software algorithms and routines which engage protection measures in the event of environmental extremes outside of performance parameter. d. Test Lab to develop a DV/PV plan which will adequately simulate the environmental profile identified in section X of SOR.
6.3 Detailing the Scope—Work Breakdown Structure (WBS)
87
6.3 Detailing the Scope—Work Breakdown Structure (WBS) Now that the PRODUCT has been fully defined by the SOR or ESOW, and the high-level task objectives have been identified via the SOW, the next step is to develop a detailed listing of all the tasks and resources associated with each PRODUCT requirement or deliverable. This is accomplished by the Work Breakdown Structure (WBS), which, like the SOW, is task-based rather than performance-based [4].
6.3.1 WBS Definition A Work Breakdown Structure (WBS) is a collection of level-of-effort deliverables that organizes the total project scope into discrete task-oriented work packages. The WBS provides the task details that are summarized in the SOW by taking each system-level product deliverable and breaking them down into smaller, more manageable components, hence the term work breakdown structure. Resourcing at the WBS level is by individuals, that is, tasks are broken out by individual team members such as Design Release Engineer, Manufacturing Engineer, Quality Engineer, Buyer, etc. The objective here is to create clear and measurable performance objectives and clear assignment of responsibility by individuals.
6.3.2 WBS Purpose and Advantages While the WBS serves to promote a common understanding of the level of effort required to accomplish the project scope among the project team, support staff, customer, and stakeholders, it also establishes the project task baseline used to define the responsible areas and cost account breakdowns of the project. The WBS also forms the basis for performance reporting formats used to evaluate contract compliance such as Design Reviews, Phase or Gate Reviews, and Earned Value Analysis reports.
The WBS can be presented in several different ways although the two most commonly used are the Graphic or Matrix structure and List structure which are shown in Figures 6.3 and 6.4. Note that in both structures the WBS is typically broken out into various degrees of work packages and are organized by “levels.” Each level refers to the level of oversight with a level 3 and above considered managerial and would be monitored by the PM and Top Management while Levels below that would be monitored by the Project team and Functional or Line Manager. Each structure portrays the same information however the List method is typically MS Project or EXCEL based for daily use while the Graphic structure is useful for visualizing the work breakout for the project such as when presenting at the Kick-Off meeting or at the Executive Management reviews. The List structure can also provide more project information with regards to man-hour estimates, personnel assignments, and matching of work packages to performance objectives (reference the column titled “ESOW para”). Within each of the two structures there are four common types of WBSs and selection is based on the type of project and what information is required by the Project team.
CHAPTER 6
6.3.3 WBS Structure and Types
Project Management for Mobility Engineers: Principles and Case Studies FIGURE 6.3 Example of Graphic or Matrix WBS for ECM.
© SAE International. All rights reserved
88
•• Product WBS •• Organizational WBS •• Hybrid •• Phase WBS 6.3.3.1 PRODUCT WBS The Product WBS is organized according to the Functional Block Diagram of the system and Figure 6.5 is an example of a Level 3 Graphic Structure, Product Type WBS of the Engine Control Module. The highest level or Level 1 is labeled as the end item or system that in this case is the Engine Control Module. The Level 2 WBS contains subsystems and is shown directly below as PCB Flex Assembly, Housing Assembly, Interface Connector Assembly, and Software. The Level 3 WBS contains a combination of nine (9) subsystems and components, i.e., the PCB Ground Plane, External Housing, Internal Separator, etc. Some items such as the Ground Plane, External Housing, and Fasteners are component levels and cannot be broken down further; however, the SM PROM and Connector could be broken down into additional levels as piece parts, however this would most likely be done by the sub supplier of those components. In the case of the PRODUCT WBS, all man-hour expenditures are organized under system, subsystem, or component regardless of who performs that work. For example referring back to the LIST WBS in Figure 6.4 all of the Level 3 tasks identified under (Level 2) PCB Flex Assembly represents all man-hour expenditures and costs related to the PCB Flex Assembly. This includes CAD design (440 manhours), Manufacturing (250 manhours) and Quality and Test (80 manhours) for a total of 770 manhours. This 770 manhours includes the documentation efforts as well as actual work expenditure. The PRODUCT WBS is useful for projects that (a) stable in production and are usually used for carry-over products, or (b) modular in design since historical costing and man-hour data is readily available which can be used to construct the WBS for future projects. Design responsibility can then be assigned by WBS package and managed
6.3 Detailing the Scope—Work Breakdown Structure (WBS)
89
CHAPTER 6
© SAE International. All rights reserved
FIGURE 6.4 Example of List WBS for ECM.
Project Management for Mobility Engineers: Principles and Case Studies FIGURE 6.5 Product WBS Example.
© SAE International. All rights reserved
90
by the appropriate level of management. Individual work packages can also be assigned to suppliers, which are then managed by the appropriate project team members. In the case of new products that are similar, the Project WBS can be easily, quickly, and accurately built by adding or subtracting existing WBS packages or modules that already have historical cost and resource data. 6.3.3.2 ORGANIZATIONAL WBS (OWBS) The Organizational WBS is organized according to the functional areas of the organization and an example is shown in the Matrix WBS shown in Figure 6.6 for the same Engine Control Module (ECM). In this type of WBS, the highest level or Level 1 is the same as in the PRODUCT WBS and is labeled as the end item or system, which in this case is the Engine Control Module. However, at Level 2 and below, the WBS activity is associated with a specific department or functional area such as Engineering, Manufacturing, Quality, Purchasing, etc., as opposed to subsystems or components as was the case in the Product WBS. Level 3 identifies specific tasks assigned to individuals whether on the project team or other organizational or sub-supplier assets similar to the Level 3 of the Product WBS. The Organizational WBS is useful for projects that are NOT production-established. Examples include Research and Development efforts, “white paper” designs, new product lines, or an established product that is being extensively modified by the customer. In these cases little or no historical information is available, so it is difficult to estimate cost and timing by subsystem or component, however, organizational expertise can be used to estimate the man-hours by functional area, taking into account the additional effort to be expended as a result of exploratory design and potential redesign efforts. Once this project is complete, this data can be used as the basis for developing more accurate costing models should this product become an established product line. One disadvantage of the OWBS is that determination of the cost and man-hour requirements to design and build a particular system or component is more difficult since this is uncharted ground in terms of work effort required so that each department’s
6.3 Detailing the Scope—Work Breakdown Structure (WBS)
91
© SAE International. All rights reserved
FIGURE 6.6 Organizational WBS Example.
6.3.3.3 HYBRID WBS The Hybrid WBS is useful when a project is a combination of an existing product line but certain aspects of the product need to be redesigned to accommodate new customer requirements, Federal mandates, or incorporation of new technology. An example is shown in Figure 6.7 for the same Engine Control Module (ECM). In this case the customer requests the new model ECM to be a carry-over of the previous model but with the additional requirement that the ECM must analyze and detect carbon levels received from the O2 sensor and adjust fuel mixture ratio to meet new Federal mandates. The components unaffected by this new requirement are indicated in yellow in Figure 6.7 and include those in the Housing Assembly, the Ground Plane, and the Interface Wiring. These components will be carryover from the previous ECM and be created as a Product WBS. However the PROM, Flex Mount, Interface Connectors and Software are new designs for the ECM as the Design Team needs to sort out all of the potential design issues. These portions of the WBS would be created as in the Organizational WBS. 6.3.3.4 PHASE WBS As the name implies, this type of WBS is aligned with the phases of the project life cycle and in the case of APQP this would be WBS tasks completed during Program Approval, then Prototype, etc. While PMBOK lists this as one type of WBS, MIL— HDBK-881 (HANDBOOK FOR PREPAR ATION OF WORK BREAKDOWN STRUCTURE—WBS) specifically states that program phases are inappropriate as elements in a work breakdown structure. Since WBS tasks do not fit neatly within a project phase and often times cross over into successive phases this type of WBS is not commonly used in Automotive projects.
CHAPTER 6
expenditure must be individually tracked and recorded. These types of WBSs should be built by subject matter experts (SME) with historical experience in the areas being developed or if being performed by new engineers the SMEs should have oversight authority prior to release of the work packages.
Project Management for Mobility Engineers: Principles and Case Studies FIGURE 6.7 Hybrid WBS Example.
© SAE International. All rights reserved
92
6.3.4 WBS Decomposition Once the PM selects the type to be used, i.e., Product, Organizational, or Hybrid, the next important question is “How far down should the WBS be broken out?” or put into PM terms, “What is the appropriate level of decomposition of WBS levels for my project?” The term decomposition, as provided by PMBOK is “a technique used for dividing and subdividing the project scope into smaller, more manageable pieces.” The project team must take care in choosing not only the appropriate levels of decomposition, but also select an appropriate size for the WBS. The team must be careful to avoid creating work packages too large that delays in task completion would impact the overall project schedule or objectives but not too small that they allow for micromanagement. In this regard PMBOK offers a definition for micromanagement: …excessive decomposition can lead to non-productive management effort, inefficient use of resources, and decreased efficiency in performing the work [5].
6.3.5 WBS Levels Although the number of WBS levels is dependent on program complexity, for the vast majority of Tier suppliers WBSs between 3 and 5 levels are adequate for most small-tomedium complexity projects, while highly complex projects with a large number of system–system interface and integration requirements can drill down to 6 or 7 levels.
6.3.6 WBS Work Package Size The standard rule of thumb for WBS work package size is 80 man-hours or not more than two (2) weeks’ worth of effort. The idea is that for a standard 18–24 month
6.3 Detailing the Scope—Work Breakdown Structure (WBS)
93
product level of effort this amount of time represents what can be recovered without adversely impacting the project schedule, assuming the worst case being work was not accomplished or that the work that was accomplished is not to the satisfaction of the customer.
6.3.7 Assignment of WBS to Project Team Personnel The PM should also be aware that people need to be managed according to their abilities so that WBS levels and sizes should be customized to suit the particular individuals assigned to those tasks. Selection of WBS levels can therefore be used as both a motivator and training mechanism. For example, in the case of inexperienced engineers the PM would want to closely monitor their performance on their initial project to determine strengths and weaknesses. The PM should allow the WBS to be built “bottoms up,” meaning that the individual constructing the WBS tasks should determine what those tasks should be under the supervision of an experienced mentor. Initially it is best to keep the work package size to the 80 h standard and once the engineer has proven his ability to effectively manage the workloads the PM or the Mentor can then manage them at higher levels with larger WBS sizes, thus offering them more autonomy in how to manage their aspect of the project. Experienced engineers should always be responsible for developing their own WBS work packages to ensure “ownership” of those tasks.
6.3.8 WBS: Additional Considerations 1. Write concise statements in a verb–noun combination. Use present tense actionbased verbs. To the extent possible, try to be as consistent as possible in the use of terms [6]. For example, the following statement is vague and open-ended and leaves definition of task completion open to multiple interpretations: Design ECM PCB Contrast that to the following statement that more concisely defines specific objectives, thus creating clearer communication between the PM and the task owner: Perform ECM PCB Material Selection Study Analyze 3 options for suitable PCB materials that meet SOR Section 3 requirements Conduct Validation study for material options 2. When required and/or available, refer to specific test methods or Design Best Practices. Rather than state: Conduct PCB Validation test Use specific references: PCB Heat Sink per PCB Best Practice Handbook, Section 5 Conduct PCB Validation test per SAE Environmental Profile 123-XX 3. Only list one task per WBS line item. Rather than state: Design PCB and Build PCB Prototype for Validation testing
CHAPTER 6
The following are Best Practice guidelines when writing a WBS task statement:
94
Project Management for Mobility Engineers: Principles and Case Studies
Break into separate tasks that will then provide historical data for future estimating and costing: Design Prototype level PCB Build PCB Prototype for Validation testing per SAE Environmental Profile 123-XX 4. Reworking, retesting, and refurbishing are not separate elements in a WBS. 5. Do not include meetings, travel, computer support, etc., as separate WBS elements. They are to be included with the WBS line items with which they are associated. This includes tooling and equipment, which should also be associated with the product or system it is used on.
6.4 Scope Validation This is the formal acceptance of the required project deliverables by the stakeholders, which includes the PM, company executives, functional managers, and the project team. This step helps ensure that the company does not take on projects that appear financially profitable but turn out to be very unprofitable once all the project obligations are uncovered. Table 6.1 relates the Scope Validation INPUTS (identified in PMBOK) to the typical Mobility equivalent. This formal acceptance is accomplished through a Technical Review or Kick-Off meeting [7] prior to the official start of the project. Attendees must include all stakeholders, and especially the project sponsor, who will review the proposed Project Management Plan with each stakeholder signing off that they agree to their obligations to the project. For example, the Sponsor commits to the project funding and supporting the PM’s authority to manage resources, functional managers commit to providing the resources indicated on the WBS, and the Customer agrees to provide any pre-agreed requirements identified in the contract such as tooling and/or gaging funding, customer-furnished products, test facilities, etc. This formal acceptance of the baseline scope and commitment allows project scope changes over the life cycle of the Product Development Process to be captured thus tracking the true cost of a project. This baseline serves as the initial input to the Earned Value Analysis process that will be used to Control Project Scope.
6.5 Monitoring and Control of Project Scope Changes Once the project scope has been established and approved the project can begin; however, the vast majority of projects never remain at the baseline level. This then requires that TABLE 6.1 PMBOK Validation Inputs and Mobility Project Equivalent
PMBOK Scope Validation INPUT
Automotive Project Equivalent
Project Management Plan
Baseline ESOW and WBS
Requirements Documentation
SOR portion of the ESOW
Requirements Traceability Matrix
Same (see Appendix D)
Verified Deliverables
Final Product and Approved PPAP file
Work Performance Data
Not a formalized process but is reviewed at the designated OEM Phase Reviews © SAE International. All rights reserved
6.5 Monitoring and Control of Project Scope Changes
95
some system of scope change monitoring be put in place to control the impact of ongoing changes to the project scope. Scope change is not necessarily bad and oftentimes the iterative process of scope modification results in a better product. For example, excessive scope changes to a carryover product in which there are no significant design modifications should alert the PM to a problem. However, contrast that to a project for developing an exploratory concept into a functional prototype. In this case the PM would expect numerous scope changes as the design team gets closer to the final design. The PM is responsible to determine how Scope Change Control will operate and would establish measures and processes to answer questions such as:
Tracking project and scope progress occurs either in a push or a pull format. A pull system requires the PM to actively obtain information from project team members usually through meetings, phone calls or one on one interactions. In contrast, a push system requires that the team members push information (on some cyclic basis) to the PM who then evaluates this information for concerns or obstacles to project progress. An example of a pull system is the weekly review meeting with the project team. In this scenario the PM uses some type of meeting to discuss status of the project progress and the impact of any scope changes. The chief problem with this type of scenario is that it becomes too labor and time intensive for the PM who, as the Lead Engineer, is already time-limited. In this way the PM is at the mercy of the project team to keep him informed of all the ongoing scope changes. The most common form of a push system for scope monitoring and change control is the Earned Value Analysis (EVA) method, which tracks and alerts the PM to the impact of scope changes as they occur during the course of the project. This process is widely used in the DoD and Aerospace industries but is currently used in a limited way in Automotive and mostly at the OEM and Tier 1 levels. An example of a portion of an EVA report is shown at Figure 6.8. The EVA report is fairly simple and monitors two discrete values: Cost Variance and Schedule Variance. The idea is that the PM is primarily concerned with (a) how the number of scope changes are impacting the resources assigned (Schedule Variance) and (b) what is the project team’s level of performance against the tasks assigned (Cost Variance). In order to calculate these values, EVA uses three (3) variables: 1. Planned Value (PV)—the estimated budget or man-hours represented in the baseline scope of work 2. Earned Value (EV)—the estimated budget or man-hours represented by the baseline scope of work plus the sum of all man-hours to complete all the authorized scope changes 3. Actual Cost (AC)—the actual budget or man-hour expenditure to accomplish the Earned Value
CHAPTER 6
1. How are scope changes received? 2. What is the documentation process? 3. Who makes up the Change Control Board (i.e., review and approval of scope changes) 4. How are affected departments notified of the change(s)? 5. How will the initiator of the scope change be notified as to the status of the change and whether or not he or she should proceed? 6. What type of reporting format with respect to ongoing scope change will the PM receive? 7. What is the cycle time of the scope change report: weekly, bi-weekly, or monthly?
96
Project Management for Mobility Engineers: Principles and Case Studies
FIGURE 6.8 Example of an EVA Report Format Group:
Earned Value Report - Engineering
Brackets, Powertrain
Phase:
3
Week:
14
Manhours WBS Task Name
Planned Value TOTAL
PV (Week 14)
EV (Week 14)
Actual Cost
SV
CV
100
120
120
120
120
0
0
100
150
150
130
100
-20
30
Critical % Complete Path Task
SV = EV-PV
3
Install and Trial UG Upgrade Investigate alternate bracket materials Design Bracket Assembly and Create CAD Model
Y
80
350
280
300
350
20
-50
When project Cost Variance is nega ve, the project is over-budget.
4
Build Prototypes
Y
100
170
150
180
210
30
-30
When Schedule Variance is negative, the project is behind schedule
5
DV Testing of prototypes
Y
50
150
75
75
75
0
0
6
Packaging Trials
0
-20
1 2
Total Manhour Expenditures (by dept.)
Y
20
0
0
0
20
940
775
805
875
CV = EV-AC
Total Manhour Expenditures - Project Assumptions:
1) 2180 man-hours available per year
The Schedule Variance is then calculated as follows: SV = EV − PV The Cost Variance is then calculated as follows: CV = EV − AC When project Cost Variance is zero (0) this means that the team is accomplishing the work according to the established estimates but when CV is negative this could mean that the team members are spending more that the allotted time on the particular task and that the project is potentially over-budget. A positive CV indicates that less work is actually being accomplished than was anticipated. This could be a result of a team member being pulled off the project to perform other non-related tasks. When SV is zero (0) this means that there has been no change to the scope baseline. Negative Schedule Variance indicates the project is behind schedule or there has been a reduction in scope. A positive SV indicates that there has been an increase in the scope, which could represent the customer having added additional scope to that particular task. The PM, on some cyclic basis, (usually bi-weekly) receives an EVA report with this information to determine where areas of concern are developing and can reach out to specific individuals before the issue reaches critical mass. Some interpretation examples for the data presented in Figure 6.8 follow: A. This report indicates that WBS tasks 1,2, and 4 have been completed (% complete = 100) B. WBS line 1, Install and Trial UG Upgrade, indicates that both CV and SV are zero which means that for this reporting period and this specific task there are no scope changes, the project task is on schedule and that team member performance is on target with the man-hour estimate. C. WBS line 2, Investigate Alternate Bracket Materials, indicates an SV = -20 indicating this task is behind schedule. There is also a CV = +30 which means that the team’s performance on this specific task in this reporting period is less than the estimated man-hours. This could potentially be the result of team member diversion to other tasks or confusion among the team members regarding the responsibility for this task. This would require immediate attention from the PM to uncover the root cause as this as this could impact other project tasks. D. WBS line 4, Build Prototypes, indicates a decrease in scope from the original planned value of 170 mnhrs down to 150 mnhrs. Since this task is complete (% complete = 100%) this could indicate a decrease in the originally contracted
© SAE International. All rights reserved
WBS No.
References
97
scope reflective of the customer reducing the scope of the project or reducing the number of prototypes. However the positive SV value of +30 means that the desired earned value is greater than what was planned possibly indicating the scope decrease was not communicated to those responsible for this task. The CV = -30 indicates an issue regarding the team’s performance on this specific task in this reporting period. This could potentially be the result of the prototype shop having difficultly manufacturing or assembling the prototypes. Based on this analysis of the EVA report and the magnitude of the variances, the PM would investigate tasks 2 and 4 and include them on the weekly design review agenda to ensure capture of important lessons learned. The PM, together with the Functional managers, is responsible to establish the protocols for the EVA report and should work with the IT department to create a format that is best suited to his/her purposes for project tracking. Also, the EVA should be linked to the organization’s Engineering Change Management System to ensure that any time there is a scope change processed in the ECMS system this information will be automatically updated to the EVA report. The advantage of the EVA process is that the PM has project information pushed to him rather than having to pull the information from team members giving the PM to react quickly to issues of scope and team performance before they affect project timing or result in less than desirable deliverables to the customer. The major challenge EVA presents however is that when first introduced into an organization, team members are reluctant to track and provide this information since they might see this as being used punitively against them. Another danger is the Commander Scott Syndrome from Star Trek where team members over-inflate their initial time estimates in order to look good when the tasks are completed under the allotted time. The PM must introduce this method slowly and incrementally so as to develop an understanding of why this information is being tracked so that the organization is more willing to provide accurate data. There is quite a bit more information that the EVA process can provide the PM; however, an in-depth review of this would be outside the scope of this textbook.
1. The details and construction of the Design Record file is covered in the chapter on Automotive APQP and Chapter 13 (PPAP). 2. Chapter 5, p. 105, Project Scope Management, PMBOK 5th Edition. 3. An example of this was presented in the Feasibility section in Chapter 1. 4. Although the PMBOK provides some level of detail on preparation of SOW and WBS, two resources that provide the most extensive guidance are MIL-HDBK-245 (HANDBOOK FOR PREPARATION OF STATEMENT OF WORK—SOW) and MIL-HDBK-881 (HANDBOOK FOR PREPARATION OF WORK BREAKDOWN STRUCTURE—WBS). 5. See Section 5.4.2, p. 131, PMBOK 5th Edition. 6. Appendix B of MIL-HDBK-245 (HANDBOOK FOR PREPARATION OF STATEMENT OF WORK—SOW) provides an extensive glossary of suggested “work or task words” to be used when creating WBS tasks. 7. A typical agenda for an automotive project kick-off meeting is provided in Section 7.1.6.2 of Chapter 7 on design review process.
CHAPTER 6
References
C H A P T E R
Design Review Process for Mobility
7
7.1 Introduction In this chapter, we will discuss the following items and also provide a template for Design Review planning and Design Review content for each of the minimum required design reviews under a standard APQP project life cycle.
1. 2. 3. 4. 5.
Defining the Design Review Process Why have Design Reviews? Design Review Process as Risk Management Design Review Planning, Protocol, and Roles Design Reviews—Categories, Types, and Timing
7.1.1 Defining the Design Review Process
©2020 SAE International
99
CHAPTER 7
The term Design Review (DR), as presented in the PMI PMBOK refers to a specific technique for conducting an evaluation of a proposed design to determine if that design will meet both product and project requirements as identified by the project team, through verification of the complete Voice of the Customer (VOC).
100
Project Management for Mobility Engineers: Principles and Case Studies
The Automotive-specific ISO standard, IATF-16949, section 7.3.4 (Design and Development Review) refines this definition by stating the following: At suitable stages, systematic reviews of design and development shall be performed in accordance with planned arrangements to a. e valuate the ability of the results of design and development to meet requirements b. identify any problems and propose necessary actions. Participants in such reviews shall include representatives of functions concerned with the design and development stage(s) being reviewed. Records of the results of the reviews and any necessary actions shall be maintained. For Automotive, as in DoD, the Design Review Process is well established, extensively detailed, conducted at very specific points along the APQP timeline, and integrated together with the OEM Vehicle Master Timing Schedule (MTS). Design reviews are led by the Project Manager or Lead Project Engineer who are responsible to develop and implement performance-based metrics that optimize the end product or system. While this defines what a design review is, it is also important to understand what the design review is not. The design review is not the place for problem solving and is not meant to be accomplished independent of key stakeholders in the organization. Proper completeness and timing of the design reviews is critical because if done too late in the project life cycle, financial and human resources will have been needlessly expended to accomplish tasks that are not part of the VOC or if done too early result in extra (wasted) effort to redo aspects of the design while the design was still “fluid.” This is especially critical in Mobility since the vast majority of product design, in the early stages of product development, is very fluid, with a significant number of scope changes due to quickly evolving market variables. Typically, the design review process is broken out into two broad categories: Technical or Product-based (Design Reviews) and Project or Resource-based (Phase or Gate Reviews). Each of these has a particular focus and agenda but are both essential to ensure the product meets all VOC requirements, affords ease of manufacturability, and aligns with the strategic goals (financial and market) of the organization.
7.1.2 Why Have Design Reviews? Oftentimes, organizations view design reviews as merely a “dog and pony show” meant to convince the customer (or the project sponsor) that the project is moving along in an orderly fashion. This attitude is so prevalent it leads to the view that Design and Gate (Phase) reviews are not value-added leading to the following bad practices: •• Expectation to present only good news; bad news is postponed •• Participants poorly prepared to discuss issues •• Key persons don’t attend •• Covering too much material at too fast a pace •• Hidden agendas left unresolved •• Drifting due to lack of formal agenda •• No clear review of action items, leading to confusion and lack of clarity regarding follow-on actions
7.1 Introduction
101
In each of these cases, the root cause for these issues lies with the Project Manager. While each person attending a Design Review has specific roles and responsibilities (covered under Design Review Protocol and Roles), it is the Project Manager who is ultimately accountable for the effectiveness of the Design Review Process. For example, it is the Project Manager who must ensure that the person assigned to lead the meeting is: a. Clear on what needs to be discussed b. Has reviewed the agenda, c. Sets the tone for what is to be discussed, and most importantly, enforces the requirement that all attendees are aware of all agenda items that concern them and that they bring that information and documentation to the meeting As was mentioned previously regarding the well-defined structure of the Automotive Product Development process (APQP) and a highly formalized content for design reviews, there is no excuse for failing to conduct an effective design review that provides the organization and the customer a detailed and true status of a project. In addition to this welldeveloped structure providing the Project Manager with clear evidence of engineering due diligence, a solid DR process allows creation of lower-level DR formats for functional areas and lower tier suppliers, which serves to communicate higher-level concerns. Having outlined some of the common problems associated with the Design Review Process, what are the reasons to conduct a Design Review? The following list is presented in order of why Design Reviews are conducted: 1. Customer and/or QMS Requirement 2. Low Cost Insurance against Product Liability 3. Knowledge Transfer leading to Best Practices
7.1.2.2 LOW COST INSURANCE AGAINST PRODUCT LIABILITY This brings us to the second point: that properly conducted design reviews are low cost insurance (and a valid defense) in the case of a product liability dispute. In the event of a product nonconformance, or defect, the burden of proof will be on the supplier to demonstrate that the project team has observed all organizational, customer, and Federal requirements regarding the product in question. Failure of the project team to design and develop a product that is not unreasonably dangerous can result in significant monetary fines and possible prosecution of those involved in the design.
CHAPTER 7
7.1.2.1 CUSTOMER AND/OR QMS REQUIREMENT Often, an organization will perform a policy or procedure such as Design Review simply because it is mandated by the customer or some type of Quality requirement such as ISO-9001 or IATF-16949. While it is true that every automotive OEM demands that all suppliers conduct formal Design Reviews as part of any project development effort for product(s) that will be installed on production intent vehicles, the unfortunate result of this is that oftentimes this requirement is seen as a documentation exercise that has no real impact to the project or the organization should this requirement not be met or met improperly. Specifically, in the case of Design Review this is a dangerous practice since (a) the Design review is meant to identify and apply corrective action to design weaknesses early in the product development process avoiding unnecessary design changes and (b) the records of a Design Review are the primary means by which an organization can demonstrate “engineering due diligence.” This is especially critical in cases where there is a product recall, warranty dispute between the supplier and customer, or a Federally mandated Safety Recall or Campaign.
102
Project Management for Mobility Engineers: Principles and Case Studies
Section 402A of the 2nd Restatement of Torts, published by the American Law Institute, defines the conditions for a seller to be found liable in a product liability case: 1. The product was in a defective condition at the time it left the possession or control of the seller. 2. It was unreasonably dangerous to the user or consumer. 3. The product was expected to and did reach the consumer without substantial change in its condition. 4. The defect was a cause of the injuries. Evidence for each of the conditions above that demonstrate a supplier’s evidence of due diligence during the Product Development Process is found in the Design History File (DHF), as part of the Design Record File. The DHF contains engineering specifications conforming to industry standards and Federal regulations, test planning and results of those tests, Design and Process FMEAs, and records of formal Design Reviews. The legal protection afforded through a robust Design Review Process is summed up very well in the following excerpt from the book entitled Product Liability and Innovation, which specifically addresses the approach to product liability in the U.S. automotive industry: The single greatest strategy to minimize legal risk in design defect cases may be this: to convince engineers of the importance of accurate report writing. The words “report writing” refer to the presence of a complete Design Record File (DRF). An in-depth explanation of the contents of a DRF along with Design Review considerations are discussed in chapters 11 (Risk Management) and 13 (PPAP). 7.1.2.3 KNOWLEDGE TRANSFER LEADING TO BEST PRACTICES A mature Design Review Process is no longer concerned only with documenting project level details but is also concerned with the success of future projects. The project team has a responsibility to the organization to ensure that the lessons they have learned throughout their particular project life cycle is made available to other project teams, engineers, designers, testers, and others involved in product development. Design Review records can indicate both negative Lessons Learned such as gaps in testing, design shortfalls, end-user applications not considered, or improper design assumptions that future Project Managers will incorporate in their initial design considerations, and positive Lessons Learned such as improvements in component design, improved manufacturing technology, improvement or additions to existing design best practices. Proper recording of design records and placement of those records in a protected share-file that is easily a ccessible to those who need the information helps ensure that project teams working on similar designs can benefit from one another without wasting time and resources working on different solutions to the same problems.
7.1.3 Design Review Process as Risk Management This section should more appropriately be titled “Design Review as part of a Risk Management.” As important as design reviews are, they are still only an audit of the status of a project and even that status is a snapshot in time. One of the greatest disadvantages of the Design Review Process is that the project team often relies solely on the conduct of design reviews to establish the progress and health of a project. Without creating the framework from which a design review obtains timely and accurate data or the mandate that participants be adequately prepared to address agenda items, the
7.1 Introduction
103
design review deteriorates into a game of cat and mouse as the project team tries to decipher the cryptic answers or shoot-from-the-hip responses given by the participants of the meeting. Figure 7.1 graphically portrays the totality of a Risk Management system (where RMP = Risk Management Plan). Notice that Design Reviews, although critical to the system, make up only a portion of the complete system. Think of the Design Review Process as a PUSH and PULL system. All the other components listed in Figure 7.1 serve as data inputs that are pushed into the Design Review, which the Project Team can use as a basis from which to generate pertinent agenda items and effective recommended actions. Participants are given the opportunity ahead of time to review and assess information from these other inputs regarding actual and potential project issues and prepare suitable recommendations. During the actual conduct of the design review, the Project Manager or the Lead Engineer pulls this information from the attendees for the purpose of obtaining consensus on risk levels, risk mitigation recommendations, and agreement of response strategies. According to PMBOK, risk management involves not only identifying risks but also requires qualification, quantification, mitigation, and response. While the Design Review agenda identifies risk (at best), the Design Review meeting is not the forum to develop risk mitigation and response strategies. This needs to be accomplished prior to the DR meeting so that the focus of DR meetings can be on a data-driven discussion of recommended risk mitigation strategies, consensus on selection of the most appropriate strategy, and selection of a method to validate the proper implementation and assessment of the success of the risk mitigation strategy.
CHAPTER 7
© SAE International. All rights reserved
FIGURE 7.1 Components of a risk management system.
104
Project Management for Mobility Engineers: Principles and Case Studies
One company that embraces this idea is Toyota. As part of their Six Mechanisms of Managing Product Development, they mandate formal preparation for design reviews as explained below [2]. “In lieu of regularly scheduled meetings, [Toyota] emphasizes written communication. When an issue surfaces that requires cross-functional coordination, the protocol is first to write a report that presents the diagnosis of the problem, key information, and recommendations, and then to distribute this document to the concerned parties. Usually, the report is accompanied by either a phone call or a short meeting to highlight the key points and emphasize the importance of the information. The recipient is expected to read and study the document and to offer feedback, sometimes in the form of a separate written report. One or two iterations communicate a great deal of information, and participants typically arrive at an agreement on most, if not all, items. If there are outstanding disagreements, then it’s time to hold a meeting to hammer out a decision face to face. In such meetings, participants already understand the key issues, are all working from a common set of data, and have thought about and prepared proposals and responses. The meeting can focus on specific problems without wasting time bringing people up to speed. By contrast, at many U.S. companies, attendees often arrive at meetings having done little or no preparation.”
7.1.4 Design Review Planning, Protocol, and Roles Proper planning of a design review is just as important as the content of the design review since poor planning will lead to the scenarios presented at the beginning of this chapter. Proper planning gives the project team and the functional areas a sense that the design review is actually a worthwhile effort in presenting and assessing project risks. This affords a cultural “buy-in” of the process so that design reviews are viewed as beneficial and not something to be avoided. We will begin first with the key individuals responsible for design review planning, which include the following (note that these roles are different from the key roles during the design review meeting, which will be defined later): 1. Lead Engineer (or Release Engineer)—defines Product Level deliverables (i.e., documentation, samples, test results, etc.) that are to be evaluated at the technical review, to include all scope changes from the Customer. 2. Project Manager (PM)—defines Project and Resource Level deliverables to be evaluated at the technical review, to include all scope changes from the Customer. 3. Technical Review Coordinator (TRC)—confirms that all preparation documentation, logistics, and deliverables have been received by the intended participants and that performance objectives for the technical review, as developed by the Sponsors, PM, and Lead Engineer are understood by the APQP Team and that this has been communicated back to the PM. Also the TRC confirms that all documentation and scope changes are under configuration control (i.e., Engineering Change Process).
7.1 Introduction
105
Next are the steps involved in planning the Design Review (These steps are not necessarily sequential.): a. Verifies completion of Product and Project Level DR deliverables b. Assures that all deliverables are current, have been reviewed and approved, and are under configuration control c. Verifies completion of Project Level DR deliverables and identifies potential participants for the technical review from the stakeholders 2. Identify potential DR attendees—Project Manager a. Per the Project Statement of Work (SOW or ESOW) and type of technical review being conducted, identifies potential participants necessary to accomplish the technical review objectives b. Identifies required sponsor participant(s) who provide oversight for the technical review and potential subject matter experts (SME) who, together with the PM and Lead Engineer, determine if the goals of the technical review are satisfied 3. Determine meeting parameters—Project Manager Select the time and location parameters for the technical review. Select the technical review chairperson and facilitator (if required). Approve potential substitutes for those participants selected but who may not be able to attend. Identify stakeholders from other organizations that are not included in the attendee list that should be invited to attend the technical review. The Project Manager must also tailor the timing and participation in the technical review to be commensurate with the customer expectations at this point, overall project scope and the risks to product and project success at this point in the Product Development Process. Issues for the Program Manager to consider include: a. The depth of discussion of the project requirements weighed against having a timely technical review. b. The availability of the participants based on previous commitments, schedule, and location. Be sure to consider use of remote technology as an alternative to physical attendance when required. c. The time participants will need to familiarize themselves with the deliverables to be reviewed. d. The complexity of the scope changes in the deliverables since the last technical review. e. The advantages of having an independent facilitator when potential conflict issues are possible. f. The risk to the project if the technical review fails to detect a defect. g. The risk status of the technical review in terms of Customer expectations at this point in the NPD process and overall project success. 4. Set up the meeting agenda and technical review rules—Lead Engineer/ Project Manager a. Develop an agenda and define the roles and responsibilities of the participants. b. Determine how the review results will be coordinated among those that review the same artifact. c. Describe how the meeting will display, that is, AV requirements, handouts, samples, etc. d. Determine the degree of agreement needed to resolve issues (decision of the technical review chairperson, consensus, majority vote, etc.).
CHAPTER 7
1. Deliverables verification—Lead Engineer/Project Manager
106
Project Management for Mobility Engineers: Principles and Case Studies
e. Establish agreement on Risk Rankings and Risk Methodology for product and project level risks. f. Determine if the technical review as a whole has been satisfactorily completed, satisfactorily completed pending changes, or needs to be reconvened when updated deliverables are completed. g. Determine how issues will reach final conclusion (i.e., decision of the technical review chair, consensus, majority vote, etc.). h. Ensure that the agenda and rules for the technical review are given to and coordinated with the Technical Review Coordinator. 5. Organize and support the meeting preparation—Technical Review Coordinator a. Finalize the time and location of the technical review and invite the participants and attendees and inform them of their roles based on the program manager’s decision. Ensure all required documentation is made available to the participants and provide them with the objectives of the technical review. Provide a list of all project deliverables and directions to the participants for access to these deliverables. b. Invite substitute participants from the program manager’s list of potential substitutes and make sure that they have all the technical review meeting information that was provided to the other participants. c. Inform participants of all agenda and rules for the conduct of the technical review and provide all necessary updates to participants, such as product/ project documentation, required research and issue resolution information to be presented by individual participants, meeting information, meeting locations and times.
7.1.5 Design Reviews: Categories Although the Design Review Process for the automotive industry is similar in many respects to most other product-oriented design and manufacturing industries, there are obviously particular nuances to automotive product development. The addition of increased awareness of concerns such as product liability, mechanical–electrical– electronic interface issues, coordinated and effective test planning, and software development, add a degree of complexity that requires a layered and parallel approach to design reviews as opposed to linear, point-in-time reviews. This complexity requires that the Project Manager ensure that system, subsystem, and component level design reviews are well coordinated, especially for high-risk suppliers, to avoid system development progressing out of step with component development. This is especially critical in the initial design reviews (such as Concept Reviews and Kick-Off meetings) to ensure that downstream Tier suppliers are clear on what the critical parameters are of the system. The typical categories of the Design Review Process for Automotive projects are: •• Peer Reviews •• Technical or Design reviews •• Project Phase Reviews •• Executive Reviews 7.1.5.1 PEER REVIEWS •• What: An in-depth critique of assumptions, calculations, alternate interpretations, methodology, and acceptance criteria employed, and of conclusions drawn from
7.1 Introduction
107
the original scope. Peer reviews confirm the adequacy of the work and are informal, smaller meetings, although the peer review does record the design decisions and thought process behind those decisions. •• Who: Peer reviews are typically conducted by persons having technical expertise in the subject matter to be reviewed to a degree at least equivalent to the project technical scope. At least some of the members of the peer review need to be independent of the project under review. •• When: As required with no set schedule, although peer reviews are usually conducted in preparation for formal Design Reviews. •• Focus: Mainly on technical level issues at Design group level but can include resourcing challenges presented by the technical issues. 7.1.5.2 TECHNICAL DESIGN REVIEW •• What: A formal, sequenced, and documented assessment of the design maturity of the PRODUCT to verify compliance to predetermined requirements such as customer specifications, regulatory and industry standards and required technological, engineering, and industry practices. Oftentimes, Concurrent Engineering requires that these design reviews be conducted separately for design and manufacturing concerns with a bi-weekly meeting to review these together. While specific content details are provided in the next section entitled Design Reviews—Types, the major areas of concern are: •• Complete capture of VOC into an engineering-based Statement of Requirements •• Design considerations to address special or key characteristics •• Ease of manufacturability and assembly •• Quality •• Test planning •• Durability and reliability •• Service •• Who: Design Reviews are typically conducted by the project PDT and led by the Lead Design Engineer or Design Release Engineer to the functional (line) managers. •• When: Design Reviews are regularly scheduled meetings, usually occurring on a set cyclic schedule. •• Focus: The formal Design Review focuses on the product readiness for either prototype verification or production validation and serves as the formal design record of the product development process.
7.1.5.3 PHASE OR GATE REVIEW
•• Ability to achieve required functionality and concerns that could, or potentially could, impact contracted performance requirements •• Cost, timing, or performance impacts resulting from scope creep
CHAPTER 7
•• What: A formal and documented assessment to a select group of project stakeholders and sponsors of the risks of the PROJECT in the following areas:
Project Management for Mobility Engineers: Principles and Case Studies
•• Ability to achieve production goals at contracted delivery and volume rates •• Resourcing shortfalls that could, or potentially could, impact project cost or timing •• Who: Design Reviews are typically conducted by the project PDT, led by the Project Manager, to (executive level) project sponsors. •• When: Phase Reviews are regularly scheduled meetings aligned with established customer or organizational milestones. •• Focus: The Phase Review focuses on decisions that need to be made regarding the status of project readiness and viability to proceed to the next phase in terms of: •• Financial and market •• Technical •• Manufacturing •• GO/NO-GO decision to proceed to the next project phase Figure 7.2 graphically portrays the relationship between the Technical (Design) Review and the Phase Review. Notice the distinction of the focus and of base level documentation that serves as the input and basis of assessment of achieving project goals. Properly performed, the concerns coming out of a Design Review normally feed the Phase Review. For example, a Design Review conducted after the initial Simulation Study of the product at Alpha Build revealed that the selected material will not perform adequately in the stated environment, which now requires an alternative material study. The project team then negotiates a 4-month contract with a materials specialist to select and develop a more adequate material. The associated cost, timing and resourcing impacts would then be reported at the next Phase Review to the project stakeholders to assess these impacts and decide on future courses of action regarding these types of issues.
FIGURE 7.2 Relationship of design review to phase review.
© SAE International. All rights reserved
108
7.1 Introduction
109
7.1.5.4 EXECUTIVE REVIEW •• What: A formal and documented strategic level assessment of all currently active organizational projects to senior level stakeholders and sponsors with regard to the project’s capability to: •• Achieve required profitability. •• Achieve market goals—is this project worthwhile to continue in the particular market segment? •• Continue to remain viable as an organizational commodity and viewed as value-added to the customer base. •• Be viable in other market sectors such as the DoD, Recreational, Agricultural, etc. •• This level of review is also where resource cross-leveling decisions would be made. •• Who: Executive Reviews are typically led by the Project Manager of each project presenting to (executive level) project sponsors. •• When: Executive Reviews are typically conducted quarterly. •• Focus: The Executive Review focuses on decisions that need to be made regarding the project health and viability to the overall organizational strategy in the areas of: •• Financial and market viability •• Technology leadership in the market •• Opportunities for additional markets; that is, the DoD, Aerospace, etc. •• Long term cost versus investment benefits
7.1.6 Design Reviews: Types and Timing For a typical automotive APQP project, there are several distinct and formal Design Reviews that occur. Some OEMs and suppliers have more than these and they are usually presented under other names, but there is no project that can function successfully without the following minimum Technical Reviews (Table 7.1): Figure 7.3 graphically portrays the timing and relationship of these Technical Design Reviews. While a detailed explanation of each of these Design Reviews is presented at Appendix E, it is important to point out several items of concern with respect to some of these Reviews.
Industry standard nomenclature
APQP nomenclature
SRR
System Requirements Review
Concept Exploration
PAO
Post Award Orientation
Project Kick-Off
PDR
Preliminary Design Review
Program Approval
CDR
Critical Design Review
Prototype
PRR
Production Readiness Review
Pilot © SAE International. All rights reserved
CHAPTER 7
TABLE 7.1 Minimum technical reviews
110
Project Management for Mobility Engineers: Principles and Case Studies
© SAE International. All rights reserved
FIGURE 7.3 Design review timing and APQP overlay.
7.1.6.1 SRR—SYSTEM REQUIREMENTS REVIEW System Requirements R eview (SRR) is critical since it serves three (3) main purposes: 1. The SRR establishes the relationship between the Customer and the Organization in terms of what are the minimum requirements, the project stretch goals, and what are potential value-added options (excitement factors— think Kano model). 2. The SRR output is the basis for the project contract between the Customer and the Organization. 3. The SRR constitutes (for the Organization) the formal analysis of the feasibility of technical, manufacturing, testing, and profitability of the project under consideration. As was mentioned in Chapter 1, the SRR is a major portion of the “beginning ocumentation” of an automotive project and must occur prior to contract award since d renegotiation of project contractual terms is not possible without some type of formal Scope Change process, which may or may not be accepted by the Customer. If the organization’s Engineering or Manufacturing group discovers that some aspect of the contract is not feasible AFTER contract award, and the Customer is unwilling to revise the terms of the contract, then the organization could be legally liable for breach of contract in failing to deliver the contracted item(s) resulting in a potentially significant financial impact.
7.1 Introduction
111
7.1.6.2 PAO OR PROJECT KICK-OFF MEETING PAO or Project Kick-Off meeting typically occurs within 3 weeks of the contract award date. While many Project Managers view this meeting as a means to orient and introduce the project team to the new contract, the true purpose is for the Project Manager to receive acknowledgment from all the functional managers of what they are required to provide in terms of both personnel and equipment resources in support of the project. All stakeholders need to come to the Kick-Off meeting having already received and analyzed the contract requirements, developed a task list, and assigned personnel so that at the meeting they are prepared to either “buy off” on the project or voice their concerns regarding shortfalls existing in personnel, equipment, timing, or technical capability. While the SRR will result in a contract between the Customer and the Organization, the PAO (KickOff) is the (internal) contract between the Project Manager and the Organization. All follow-on Phase Reviews risks will be based on the baseline internal “contract” that is established at this Kick-Off meeting. Any Project Manager that treats the PAO (Kick-Off) as an introduction meeting only and fails to establish functional Manager level buy-in and uncover project concerns is creating for himself or herself the real potential for miscommunication and waste of resources to which they are ultimately responsible for.
7.1.6.4 TRR: TEST READINESS REVIEW Test Readiness Review (TRR) is important if the project complexity involves a significant amount of testing and coordination of several levels of subsystem, component, and software testing, not to mention samples required to be submitted to the customer at particular points in the project life cycle for evaluation at the system or vehicle level. This is especially critical during the PDR phase when using a Robust Matrix to identify shortfalls in the Design Verification portion of the project test plan. Since testing can be costly and time-consuming, the TRR is helpful to identify not only missing tests but also unnecessary duplicate testing and/or determining proper test sample sizes to obtain useful information to drive design improvements.
CHAPTER 7
7.1.6.3 CDR: CRITICAL DESIGN REVIEW Critical Design Review (CDR) must be understood as the demarcation line between “paper designs” and “hard tooling.” The CDR is often mistakenly termed “Design Freeze,” which gives the impression that after this point the design will remain unchanged or “frozen”, however this is rarely the case in the Mobility industry as design changes normally continue to occur throughout the project life cycle often for good reason. More realistic is an unwritten rule between the Mobility Customer and Supplier that design changes prior to CDR are typically funded by the supplier since this is the exploration portion of the project when the product scope is not yet solidified. Design changes post CDR should be at the Customer expense or at the very least a shared expense between Customer and Supplier since major aspects of the design (at the system and subsystem levels) should be solidified, barring any last minute updates to governmental regulations. The CDR gives the supplier the ability to “manage” customer scope creep by continually reminding the Customer at the SRR, PAO, and PDR that once the project passes CDR, changes could negatively impact the project since this will involve changes to “hard tooling.”It is difficult, if not impossible, for a supplier to tell their customer that they cannot make any further design changes after CDR, but the supplier can keep them appraised of the risks which could potentially have significant cost, timing, or performance impacts. This idea has been a key point of Chrysler’s Forever Requirements “Proactive Communication.
112
Project Management for Mobility Engineers: Principles and Case Studies
7.1.6.5 PRR: PRODUCTION READINESS REVIEW Production Readiness Review (PRR) is an examination of the project to determine if the design is ready for production and the organization has accomplished adequate production planning without incurring risks that will exceed the capabilities of the organization’s Quality Management System in terms of schedule, performance, cost, or other criteria established by the project team. The full production-intent system is evaluated to determine that it correctly and completely implements all system requirements, to include traceability as required by the customer contract requirements and Federal and/or International regulations as applicable. At this review, the Project Team, together with the Production Launch Ramp-Up team shall also review the readiness of the manufacturing processes, the Quality System, and the production planning, that is, facilities, tooling, and test equipment capacity, personnel development and certification, process documentation, inventory management, and supplier readiness. A successful review results in approval to proceed to Low Rate Initial Production (LRIP)—DoD terminology or Production Launch Ramp-Up—Automotive terminology leading to Full Rate Production or Product Launch. In Automotive, it is at the PRR that there is a transition of responsibility FROM the Engineering Project team TO the Manufacturing Launch Team. Typically, the criteria for a successful transition are as follows. Failure of the Engineering Project team to accomplish these criteria would require that they maintain responsibility for the project until all of these criteria are met. 1. Determination that the system requirements are fully met for the final production intent configuration. 2. Production capability has satisfactorily demonstrated the ability to achieve the contracted production volume rate plus any over-capacity rate established by the customer contract. 3. All suppliers have successfully achieved a PRR “pass.” 4. Remaining project risks have been identified and mitigated to the point that they can all be corrected within the capability of the organization’s Quality Management System.
7.2 Case Study Design Review Issue: Challenger Mission While the proper and effective procedural application of a Design Review process and the effective documenting of design issues is both beneficial and essential it is even more important to ensure that these procedures and documentation lead to actual solutions or mitigation of discovered risks. As design review records and FMEA form a critical part of the Design Record File (which is evidence of engineering due diligence), any process which only serves to collect data but fails to use this data to improve product safety and performance opens the organization to warranty costs and at worst liability claims. Probably the most famous modern-day case of poor risk management which demonstrates this failure to properly apply the lessons learned achieved through the use of the FMEA and Design Review process by both a supplier and a customer to address a known risk issue is the Challenger Space Shuttle 51-L mission in January of 1986. The results of a Congressionally appointed committee investigation3 revealed that improper material selection of the O-ring seal on aft field joint of the solid rocket booster
7.2 Case Study Design Review Issue: Challenger Mission
113
was susceptible to failure in cold temperatures which were present on the day of launch. This failure allowed flames to escape the rocket booster and damaged the external fuel tank, causing the spacecraft to explode and disintegrate. While the Committee investigation discovered that there were several technical management deficiencies leading to this failure chain they found that Information on the flaws in the joint design and on the problems encountered in missions prior to 51-L was widely available and had been presented to all levels of Shuttle management. The report cited that there were records of Design Review documentation throughout the course of the Design and Development of the Solid Rocket Motor System. This documentation referenced the use of the FMEA and Hazards Analysis processes for the identification of risk: As a result of performing the FMEA, a list of critical items [was] identified. NASA’s FMEA assure that all Criticality 1 and 1R systems are properly identified and classified. The failure of these items would produce loss of life and/or loss of vehicle. The FMEA applies strictly to the hardware associated with the NSTS and is “bottoms-up” analysis, in which a single component failure is traced and its effect on a particular subsystem, subsystem interfaces, and the overall flight systems is determined. With respect to Validation testing the Committee found evidence that prior to the STS 51-L accident, there was in place a comprehensive and prescribed design and certification processes. So with all this information in place and available the question become, how could this disaster happen? The Committee determined that the underlying problem which led to the Challenger accident was not poor communication or inadequate procedures, but rather that the fundamental problem was; …poor technical decision-making over a period of several years by top NASA and contractor personnel, who failed to act decisively to solve the increasingly serious anomalies in the Solid Rocket Booster joints. Despite the presence of significant amounts of information and the occurrence of at least one detailed briefing at Headquarters on the difficulties with the 0-rings, the NASA and Thiokol technical managers failed to understand or fully accept the seriousness of the problem… the Committee concluded that NASA’s decision making process was flawed...[and] that the Marshall Space Flight Center should have passed along to higher management levels the temperature concerns that Thiokol engineers raised the night before the launch of Mission 51-L.
[the committee] investigation indicates that the decision to launch Challenger on January 28 suffered equally from a lack of information, misinterpretation of the information that was available, and a complex interplay of personalities among the principals involved. We are equally convinced, however, that the resulting decision to launch was arrived at as a logical conclusion of faulty premises, coupled with a failure to recognize the effect of temperature on the design. The best and most effective processes are useless unless the data they produce is used to (a) make valid decisions based on a valid and appropriate interpretation of
CHAPTER 7
Another interesting observation made by the Committee was the statement that valid design conclusions did result from misinterpretation of collected data.
114
Project Management for Mobility Engineers: Principles and Case Studies
collected data, and (b) take clear and timely action on the part of the project team, the project manager, and the top management of the organization. Pressure to achieve corporate financial goals, customer or in-house timing schedules must not override the requirement to properly respond to discovered risks and this falls within the duties of the project manager to effectively manage.
References 1. Source: Chapter 12, Approaches to Product Liability Risk in the U.S. Automotive Industry by Charles W. Babcock, Jr. 2. Source: Harvard Business Review article: Another Look at How Toyota Integrates Product Development by Sobek, Liker, and Ward, July–August 1998.
Identifying and Managing Costs/Procurement and Supplier Quality
8
CHAPTER 8
C H A P T E R
8.1 Introduction and Overview As with other areas of Project Management, Cost Management involves the process of developing and maintaining policies, procedures, and documentation for the expenditure of funds allocated to a project. As with other Management plans such as the Communication Management Plan, Risk Management Plan, etc., the key benefit is to provide the project team and stakeholders guidance and direction on how the project costs will be established and controlled throughout the project. While most industries such as Aerospace, Defense, and Civil Engineering have cost budgeting and control within the purview of the project team, most suppliers in the Automotive sector typically have cost management and budgeting outside the control of the project team and there is a separate accounting group that would manage this aspect of the project. This is not to say that the techniques listed in the PMBOK do not apply but they are not performed to the degree that they would be in other sectors. With this in mind, PMBOK identifies several areas related to Cost Management as follows:
1. 2. 3. 4.
Cost Management Plan Cost Estimation Determine Project Budget Cost Control
©2020 SAE International
115
116
Project Management for Mobility Engineers: Principles and Case Studies
Before we discuss the process flow for each of these steps let’s define some typical costing terms commonly used in project management. 1. Direct Costs and Indirect Costs 2. Commitment and Obligation Direct and Indirect Cost: The primary difference between these two terms is the ability to clearly track expenditures against these types of costs. Direct costs are those that are specifically identified against a singular cost objective. These should be reflected in the WBS structure and are controlled and budgeted at a PM level. Examples of direct costs are tooling and equipment, raw materials, design services, and prototype parts since each of these has a direct cost associated with it. Indirect costs are those that cannot be identified against a particular product or activity and therefore may or may not be reflected in the WBS structure. In fact, many times indirect costs can cross several different project line items. Examples of indirect costs include travel expenses, leasing of office space, setting up of overseas logistic offices, utilities, and general ER&D labor expenses. Indirect expenses can be difficult to track since the expenses are not necessarily against a single WBS line and can cross several line items such as travel expenses. Another concern is that in many commercial industries such as Automotive, these costs are managed at a functional or organizational level as “overhead” or “burdened” costs and thus are mostly invisible to the Project Manager. This results in the PM losing visibility on how much engineering, testing, or manufacturing labor is expended to design, test, and build prototype and preproduction units. As an example when the PM reports on the project expenditure relative to the allocated budget, things look rosy and on track; however, the reality is that 400 man-hours of additional engineering development and overtime was spent to solve design issues discovered during prototype testing and changes made at the request (i.e., whim) of the customer, all of which was not captured on the project WBS. Oftentimes these overruns will purposely not be reflected on the project WBS to show that the project was managed successfully. Key to this is a well-developed and effective Engineering Change Management System which ensures tracking of all expenditures related to a project so that the total impact of the design capability of the organization and the external influences of the customer can be seen allowing for robust cost models to be built for future programs. Commitment and Obligation: These terms are used to indicate how project funds are to be distributed. A commitment is an administrative reservation of allotted funds, or of other funds, in anticipation of their proposed use, or obligation. A commitment expresses intent to expend assets. A commitment can create a legal liability. An obligation is a definite commitment which creates a legal liability on behalf of the organization for the payment of goods and services ordered or received. Obligations are incurred when an order is placed, a service is purchased, or a contract is awarded. An obligation can also occur when funds are transferred from one account to another internally within the corporate structure of an organization. Committed funds can be redirected based on the economic or strategic needs of the organization, whereas obligated funds must be used for the purposes specified in the budget plan. This is beneficial when funds need to be moved between projects. Take the case where two projects are under development and market studies determine that Project A needs to be redesigned to accommodate emerging trends; however, this will require an additional $50,000 in engineering and testing. This is outside the budget of Project A. Now the Project Manager of Project A knows that Project B has $200,000 remaining so he can solicit his Project Sponsor to release $50,000 from Project B since it is known that Project B is in a declining market and the organization would not benefit from additional engineering design expenditures. Since the ER&D funds for this
8.2 Cost Management Plan
engineering effort were only committed they can be transferred to Project A. Now not all organizations make this level of distinction; however, the PM should be careful to obligate, or at least identify the importance of obligating critical line items from his or her WBS.
8.2 Cost Management Plan As was mentioned, the Cost Management Plan contains the policies and procedures specific to how the organization will estimate project costs, determine project budgets and implementation of cost control measures. Table 8.1 identifies the basic elements of a Cost Management Plan and the inputs that are required to accurately develop the project cost model. In this chapter, we will cover items 2 and 4 as items 1, 3, and 5 have been discussed in other chapters of this book.
8.2.1 Develop Project Cost Mapping As indicated in Table 8.1, the Project Cost Map defines the parameters by which project costs will be tracked, identifies the historical reference point from which the project budget will be developed, and establishes buy-in between the project team and the organizational staff that supports the project effort. Normally, for Automotive projects the budget is established by the Account Manager prior to the assignment of a Project Manager so, unfortunately, the PM inherits the budget, be it good or bad. This budget was established during the bid and contracting phase of the project and, hopefully, was based on sound historical costs from similar engineering and manufacturing efforts. So, while the PM is typically unable to create her own budget, what she can do is request information concerning how the budget was achieved. The first question then is:
© SAE International. All rights reserved
TABLE 8.1 Basic elements of project cost management
Task
Documents or inputs
1. Define project requirements
SOR and SOW
2. Develop Project Cost Mapping
a. TOTAL cost structure definition for design and Manufacturing Risk Assessments
b. Identify historically applicable cost models
3. Establish project timing with key events 4. Administer appropriate contracts 5. Establish project cost tracking system and report cycle
c. Tie-in of level 1–3 WBS (minimum)
d. Cost structure review for functional manager buy-in
a. Customer MTS
b. Critical Path Event Analysis
c. Sub-project milestones
a. Selection of contract types
b. Determine contract incentive features
a. Engineering Change Management (ECMS)
b. Earned Value Analysis (EVA)
117
CHAPTER 8
118
Project Management for Mobility Engineers: Principles and Case Studies
“Does this budget reflect the total anticipated cost to bring this project to completion based on the Customer SOR?” The key to this is for the organization to: a. have a good handle on the number of engineering changes generated for a similar product b. understand the historical pattern of the particular customer; do they operate “hands off” or are they heavily involved, making frequent and costly changes to the design during the development process c. know if the skill level history of the project team and auxiliary staff is appropriate to the development effort so as to avoid in-house changes and redesigns. This is where mentoring for entry level staff or those working on technologies outside of their core expertise can prove valuable. Mature PM processes will have readily available data, by product line, on total and average number of engineering changes (ECs) and what the average cost is per EC. Tracking this also by customer can be very helpful since customers can have a drastic impact on the number of ECs generated. The elements of an effective Engineering Change Management System (ECMS) will be discussed later in this chapter. Armed with this data the Account Manager can make allowances for probable cost impacts. This data together with historical Lessons Learned data allows for the development of a Cost Model handbook that will contain template WBSs by product line, which can be used by the Account Manager as a basis for establishing the new project budget. The organization must ensure that the Account Manager and PM have a formal transition meeting at project start to transfer project information such as the WBS template (at least to a Level 3) and Lessons Learned as well as the rationale for selecting those as the baseline. The PM, for his or her part, must ensure that during the course of the project all project-related expenditures and ECs are documented in the Project Book and that the WBS is updated to reflect the most current product development costs. Once the project budget is transitioned to the PM, there needs to be buy-in from the functional managers since they will be providing the personnel to complete the project. This budget review should be a line item on the agenda of the PAO or the Project Kick-off meeting (see Chapter 7). In the situation where the PM cannot establish the project budget, this meeting provides the PM the opportunity to present gaps in the project budget based on the risk analysis the project team has performed, historical Lessons Learned not captured but available from previous team experience. Equally important is that the Kick-off meeting provides the highest visibility since it is attended by the functional managers, account manager, and project sponsors. Using the Kick-off to identify these gaps the PM can alert the organization to critical flaws in the project costing process while at the same time have the right audience to obtain funding to close the gap. Should the PM fail to take this opportunity at the beginning of the project to identify risks, it will be very difficult later for him or her to justify why additional funding is required, creating the impression that the PM has mismanaged the project since at Kick-off everything seemed OK. Additionally, this meeting provides the functional managers the chance to present their concerns associated with the budget whether in terms of inadequate funding for personnel, equipment, testing, or production trials and ramp-up.
8.2.2 Selection and Administration of Supplier Contracts Selecting the contract type is generally a matter for negotiation and requires careful consideration by the project team. While most automotive PMs will not be part of the
8.2 Cost Management Plan
product contracting process, they will most likely be involved in working with purchasing to establish contractual relationships with suppliers of product subsystems or components; therefore, the PM should be knowledgeable in the basics of contracting. The objective is to negotiate a contract type and price (or estimated cost and fee) that will result in acceptable risk to both customer and supplier, while providing the appropriate flexibility and latitude for the supplier to deliver the most effective product or service at a reasonable price. 8.2.2.1 FACTORS TO CONSIDER IN DETERMINING THE TYPE OF CONTRACT While there are many factors to consider in selecting and negotiating the specific type of contract type, the following represents some of the basic considerations:
a. b. c. d. e.
Price competition and analysis Type and complexity of the requirement Urgency of the requirement Period of performance or length of production run Supplier’s technical capability and financial stability
8.2.2.2 CATEGORIES OF CONTRACTS •• Fixed-Price Contracts (FP) ▪▪
Fixed-price contract provides for a firm price or, in appropriate cases, an adjustable price. Fixed-price contracts providing for an adjustable price usually include a ceiling price and/or a target price.
•• Cost-Reimbursement ▪▪
Cost-reimbursement types of contracts provide for payment of allowable incurred or unanticipated costs, to the extent prescribed in the contract. As in FP contracts, these contracts establish a ceiling that the supplier may not exceed (except at its own risk) without the approval of the purchasing agent.
•• Level-of-Effort ▪▪
Used when the supplier is contracted to provide a specific level of effort, over a stated period of time, on work that can be stated only in general terms. An Systems Technical Services (STS) contract is an example of this where the scope is written for a particular project but with non-specific scope language.
8.2.2.3 SUB-CATEGORIES OF CONTRACTS SPECIFICALLY USED IN AUTOMOTIVE 8.2.2.3.1 Letter of Intent/Agreement (LOI/LOA). This is a performance docu
ment that outlines basic PROJECT requirements so as to provide maximum flexibility to the organization’s design and manufacturing capability. Typically, an LOI contains high-level contract language, such as the following: The “customer” wishes to retain the design services of “XY Supplier” for the purpose of designing a full interior cockpit assembly for the 20xx generation vehicle. This LOI/LOA will form the basis of a more comprehensive Statement of Work as the submitted system level design concepts are approved.
119
CHAPTER 8
120
Project Management for Mobility Engineers: Principles and Case Studies
The LOI/LOA establishes a “contract” between the customer and the organization regarding product performance requirements and forms the basis for the contents of the Technical Feasibility Risk Analysis and Concept Phase Review. LOI are often used in Joint Venture situations where two or more companies are merging technical, manufacturing, and/or testing capabilities to meet a particular customer demand. Due to the high risks an LOI presents since much of the work is not well defined, this contract requires the organization to possess a sophisticated cost modeling database from which to develop an accurate quote. 8.2.2.3.2 Statement of Requirements (SOR). An SOR is a Product Performance document that provides the details of the PRODUCT requirements and establishes the performance of the product at some level: concept, system, or component. The SOR as in the LOI establishes a “contract” between the customer and the organization regarding product performance requirements and forms the basis for the contents of the Design Reviews. The SOR also establishes the baseline performance standard from which product scope change will be tracked through the organization’s Engineering Change Management System (ECMS). An SOR should provide details (at some level) of all product performance requirements such as design, reliability, durability, test requirements, etc. If the SOR is not written in the Organization’s technical language, then there is the additional step of translating the SOR into a PDS (Product Definition Specification), which is language understandable by the organization’s engineering and manufacturing personnel. An example of Statement of Requirements that contains all the elements of a large-scale project is in Appendix A. 8.2.2.3.3 Engineering Statement of Work (ESOW). An ESOW is both a Product and Project performance document that serves as both an SOR and an SOW in that it provides the details of the PRODUCT requirements and establishes the performance of the product—SOR, and also provides a list of tasks to be performed delineated by Customer and Supplier. Examples of this task delineation would be:
1. Supplier to provide CAD drawing and delivery of four (4) prototypes for Phase 1 Testing 2. Customer to provide test facility for testing of prototype samples 1. Customer to design product packaging 2. Supplier to contract with packaging vendor to build all packaging and dunnage While the ESOW provides the basis for the Design Reviews since it outlines product requirements the ESOW also forms the basis for the contents of the Phase (Gate) Reviews and is also the baseline cost model from which to track cost and schedule variances (i.e., scope creep) as project changes occur. 8.2.2.3.4 Special Case Contracts—BPA and BOA. A Blanket Purchase Agree ment (BPA) is a simplified method of filling anticipated repetitive needs for supplies by establishing “charge accounts” with qualified sources of supply usually consumables. The use of this procedure avoids the writing of numerous purchase orders each time the particular item is needed. The BPA can be used when there are a wide variety of items in a broad class of supplies or services that are generally purchased, but the exact items, quantities, and delivery requirements are not known in advance. It is also used when there is a need to provide a source of supply for one or more projects where that project team does not have the authority to purchase otherwise. Examples of where a BPA can be used include copy paper, replaceable testing stylus, or a particular size fastener.
8.2 Cost Management Plan
A Basic Ordering Agreement (BO) is similar to a BPA except that in a BOA the items being purchased are time and/or labor. A BOA can be used to contract for uncertain requirements for supplies or services when specific items, quantities, and prices are not known at the time the agreement is executed. Typically, there is an expectation of a substantial number of repeat requirements for the type of supplies or services covered by the agreement. The BOA is extremely useful in situations where new or untested technology is being developed and the customer or Supplier has no real way of knowing how much ER&D will be required to develop the technology. Time or labor is contracted in “blocks” of time for service support and the supplier only pays for that time or labor that is expended against the contract. Examples include use of test fixture stands, engineering consulting or design time, or testing services. BOAs are used extensively by the Defense Department and are referred to as System Technical Services (STS) contracts.
8.2.3 Closing Thoughts on Contract Selection Whichever contract is used, the project team must carefully examine and analyze the project risks particular to each type of contract to identify and respond to hidden risks especially in the case of conceptual ventures. A supplier responding to a conceptual style quote, such as an LOA/LOI must possess the ability to transform a concept into hard reality, in the form of a prototype model, virtual mock-up, and ultimately a production product. This necessitates a project manager who has the knowledge and experience to apply the appropriate product development model as described in chapter 2. Many times a customer will use concept quoting to gain insight from the supplier base as to what is possible. Suppliers responding to this type of quote are expected to be up to date with the latest technology in both product and process. A big advantage of quoting a concept is that the supplier is afforded the opportunity to create the standard which the customer will apply to other suppliers, as opposed to quoting to someone else’s standard. Due to the significant amount of development and exploratory effort that would typically be required for a Concept quote, it should be evaluated by both the project team and key line staff members prior to award. These types of contracts require all of the organization’s collective e xperience and knowledge as well as a significant commitment of funding. Therefore, a well formed response to a Concept Quote should address the following at a minimum: •• Funding reimbursement for design studies as well as prototypes •• Funding reimbursement for tooling, secondary equipment, test equipment, and gaging •• Staffing requirements for new product or process technologies (external and internal) •• Design freedom (with respect to design release authority) •• Design confidentiality rights, both product and process •• Reliability and Warranty requirements, stretch goals, and responsibilities •• Critical Path considerations and concurrent design and manufacturing risks •• Timeline feasibility and Critical Path identification of significant milestone events The Team Feasibility Commitment Form (TFC) (see Chapter 1) is a good method of ensuring that all affected parties have had an opportunity to input into the risk analysis prior to the award of the contract. Remember also that it is important that the company
121
CHAPTER 8
Project Management for Mobility Engineers: Principles and Case Studies
personalize the Team Feasibility form to avoid the generalized format, which can quickly lose effectiveness. Requiring team members to update the TFC with new concerns identified during the TGRW reviews not only provides incentive to improve the TGR/TGW process but allows project planners to better identify project concerns UPFRONT so as to quickly respond to RFQs.
8.3 Cost Estimation When developing the Cost Model for project budgeting, consideration should be given to the level of both accuracy and precision appropriate to the type of project. While it seems obvious that projects with smaller profit margins must have better accuracy, in many companies this does not seem to be the case. Project budgets are created based mainly on production figures such as piece price, production labor, and other logistics, such as packaging, warehousing, and transportation. The upstream portion of the project, that is the ER&D portion, seems to be, at best, very liberal estimates based on hopeful outcomes. As was mentioned in the prior section, many Tier companies attribute these costs to overhead or burdened costs without realizing the true cost impact of the project to the organization’s projected profit margin. Now this is not to say that every project requires highly expansive and detailed cost estimation; however, it does require the organization to understand which customer and which levels of effort do require a higher degree of accuracy. The cost of full implementation of RDM (DFSS) techniques can be costly both from a time investment standpoint but also from a testing standpoint as the test program for some new technology projects could be pricey. Table 8.2 offers a comparison of the three basic types of cost estimation and outlines when each is best used and what type of inputs are required. Note that there is no “right” type for all projects as each has its own benefits and shortfalls. Automotive Tier 1 TABLE 8.2 Types of Cost Estimation
Type of estimate
Order of magnitude
Budget
Definitive
Description
Coarse estimation of major inputs necessary to complete the project developed by a single person or department
More detailed review of individual project tasks based on topdown prorating
Well-defined cost data built from the bottomup by department. This data is usually consolidated into a cost-estimating manual or target cost by module
Accuracy
±25–35%
±15–20%
±5%
Information Required
Basic project scope, size and complexity, similar projects
Project scope (WBS), resource requirements, resource rates, history, schedule, vendor estimates
Similar parts, specs, design concepts, drawings, project plan information, early vendor quotes
When to Use
Project with fairly welldefined tasks, which presents low risk and project not critical to business strategy
Exploratory area with ambiguous task descriptions and/or project direction but project presents solid business opportunities
Project presents highrisk areas. Profit margins very tight and success is vital to core business strategies
© SAE International. All rights reserved
122
8.4 Determination of Project Budget
companies have the infrastructure to develop and maintain cost modeling handbooks and therefore are capable of using Definitive cost estimation while Tier 2 and below typically use the Budget type of cost estimating. Since profit margins for most Mobility programs are fairly lean (5–7% range) it can be seen in from Table 8.2 that Budget level estimating at best provides on average a 15% accuracy range. This in essence is like playing roulette—every once and a while you will win a spin, but the odds are in favor of the house, and in this case the house is the customer. The main difference between the Budget and the Definitive cost estimate is how the estimate is prepared; top-down versus bottoms-up. In the Budget scenario the Pre-Core team will prepare the estimate based on their experience and while they may make a few phone calls to confirm their gut feel, for the most part the estimate is prepared by them and then fed down to the project team. In the Definitive model, the actual persons doing the work are providing the labor data based on actual previous experience. This is why the WBS template is so important in that the Quote (Pre-Core) team uses the WBS template, which has been updated with the latest information on ER&D labor and material expenditures from those performing the work. With this information documented and available, the time to perform a Definitive estimate would take no longer than it would for the Budget estimate. Normally speaking, Definitive Estimating should be used for carryover projects where there is a large and well-established product data and product risk is high or the product is vital to the core strategy of the company. The Budget estimate is used in situations where the customer is modifying a current design and is adding features or technology of which the organization does not have much experience with and medium risk. Order of Magnitude Estimation is used on technology-heavy or advanced technology projects where there is very limited data and thus project risk is high or where the profit margin is great enough that cost tracking is not value-added. A good example of this would be a company that designed and manufactured LASER machines used in cosmetic surgery. They contracted our company to help them improve production efficiency as well as optimize the design and development process. The company had just hired a Quality Manager from the automotive industry and together we came up with several improvements that would result in significant product cost savings, mostly coming from streamlining a very labor-intensive process. When presented with the results and recommendations, the executive staff decided against implementation since it was felt that the costs of the improvements would not produce a sufficient ROI as the current profit margin was well in excess of 30%. In this situation the profit margin was significant enough to allow for coarse estimation of project costs making detailed collection, tracking, and analysis of data non-value-added.
8.4 Determination of Project Budget Recall earlier it was stated that in most Mobility Tier organizations, the PM does not establish the budget and oftentimes has limited visibility into budget expenditures. Oftentimes this results in simple estimates based on the parts (Bill of Material) and labor that does not include other ER&D costs, which can be significant. The PM needs to be aware of what elements are missing from the project budget that he has been given and should present these elements at the Project Kick-Off meeting. This can then be added to the Quoting process so as to be captured in future quotes. Figure 8.1 shows some of these “unrecorded” costs. For those organizations desiring to use off-shore design and manufacturing, an area of consideration which does not receive proper attention and can be a source of lost revenue is the last item in the DESIGN column of Figure 8.1; off-shore set-up, licensing
123
CHAPTER 8
Project Management for Mobility Engineers: Principles and Case Studies
© SAE International. All rights reserved
FIGURE 8.1 Detailed Project Cost Considerations.
FIGURE 8.2 Total Design and Production Costs.
© SAE International. All rights reserved
124
and logistics. Not taking into account these logistical and administrative costs when considering outsourcing to overseas facilities can result in potentially severe financial miscalculations and erode expected profit margins. Figure 8.2 shows the impact of some of these common “hidden” costs increases when we compare TOTAL design and production costs between the United States, Mexico, and China. Note the Add-On factor. Additional cost impacts can result from: •• Quality costs due to increased levels of inspection, reworking, or returning delivered items. •• Expediting costs to ship product, which was delayed and is required JIT at the customer facility. •• Use of hazardous chemicals during processing can lead to product liability impacts from consumer exposure to products and/or processing methods.
8.5 Control of Project Costs
•• Employee safety practices are generally underdeveloped and safety violations and/ or worker injury leading to legal expenses. •• Economic instability causing unstable monetary policies leading to employee turnover and inflation.
8.5 Control of Project Costs For automotive-based projects, most Cost Control measures usually fall into three categories, from the simplest to that which provides the highest level of detail and requires the most work: a. Project Budget review as part of the Design and Phase Review Agenda b. Project Management Dashboard c. Earned Value Analysis (discussed in Chapter 6, Section 6.5) While item a) requires the least amount of work, it is what is referred to as a contact method (meaning a hands-on process) that requires that the PM and staff be physically present, such as a meeting, to review the data and determine corrective actions, while items b) and c) are considered non-contact since information is pushed to the PM and he or she makes the determination of what needs attention. Thus, they do not need to be physically present and as required can hold very selective meetings addressing just those areas that require attention and closer management oversight.
8.5.1 Documenting Cost Management 8.5.1.1 PROJECT BUDGET REPORT FORM For organizations in which the PM has responsibility to monitor project costs documenting the ongoing Project Budget is essential. Figure 8.3 shows a simple format that provides a snapshot of the budget data necessary to ensure that the majority of potential risk areas are covered and which can be easily updated. A format similar to this would be presented at the POA (Kick-Off) meeting to (a) indicate shortfalls in the quoted budget, (b) receive commentary from key stakeholders, and c) receive approval of a modified budget. This then serves as a cost baseline against which is tracked cost increases from both the customer and the organization. This baseline can be used by the PM to “check” the work of the Quote team or Account Manager to ensure that all of the actual and potential risk areas have been accounted for in the working budget. Once the project begins, this format tracks changes in the project budget over the course of the project and forms a part of the close-out review at the end of the project. The final budget worksheet then becomes a template that can be used together with the WBS template to create more accurate budget projections and future quotes. 8.5.1.2 PM DASHBOARDS Dashboards have become increasingly popular. They first appeared on business and marketing projects but are now appearing in more technical-based projects. A Dashboard can be thought of as a report card of the project at each phase of the project or some other cyclic reporting period. Dashboards typically use charts, graphs, and performance indicators to highlight key areas of the project by displaying data in formats that are easy to interpret by multiple layers of management. PM Dashboards are extremely useful as a NON-CONTACT management tool to allow the project manager to review, monitor,
125
CHAPTER 8
126
Project Management for Mobility Engineers: Principles and Case Studies
© SAE International. All rights reserved
FIGURE 8.3 Sample project budget format.
8.5 Control of Project Costs
© SAE International. All rights reserved
FIGURE 8.4 Sample PM dashboard.
and manage data without the need for physical interruptions of daily work such as meetings or phone calls. Once a trend or “critical value” is observed, the PM can take specific and “surgical” action to remedy an issue without involving project team members who are unaffected. In this way, a Dashboard can also help to prevent project managers from micromanaging a project. An example of a Project Dashboard is shown in Figure 8.4. Dashboards use various types of performance indicators to help the PM visually track project progress in terms of budget or labor expenditures or quickly alert the PM to problem areas. Typical performance indicators include the following. Quantitative •• These are PIs that display a very specific number usually associated with a critical reference number Trend •• Used when the direction that the data is trending is more important that the exact number. Action Required •• This is similar to the QUANTITATIVE PI but requires some action to be taken if the value falls below the target value indicated. Risk Identification •• This is an identification of the Risk items for the dashboard reporting period categorized by risk level such as Hi, Med, Low or Red, Yellow, Green.
127
CHAPTER 8
Communication Management
9
CHAPTER 9
C H A P T E R
9.1 Introduction and Overview Most of a project manager’s time is spent in communicating. How many times have you heard someone say “There’s no communication around here. That’s why nothing gets done right.” Communication-related issues are the most frequent problems faced by the project manager and the organization; however, most often the fault lies with the PM. This is because what is absent are specific protocols for the effective management and monitoring of project information throughout the communication spectrum; customer, organization, and supplier. For this reason PMBOK has devoted an entire section to addressing the need and the methods for structured communications management. PMBOK defines Communications Managements as: “…the processes necessary to ensure the information needs of the project and its stakeholders are met through development of artifacts and implementation of activities designed to achieve effective information exchange.” PMBOK categorizes these processes in three distinct areas within Communications Management: 1. The planning of communications management. 2. The activities involved in managing the communication systems and processes which includes the documentation requirements of the communication management plan. 3. The activities involved in monitoring the flow, channels, and security of communication.
©2020 SAE International
129
130
Project Management for Mobility Engineers: Principles and Case Studies
Communication in its most basic form is the exchange of information with the intent of transferring knowledge. That information can be transferred both formally and informally. Formal communication involves capturing the communication elements in a manner so that the information can be collected, distributed, stored, retrieved, and eventually disposed of. Examples include Scope of Work contracts, Design Review minutes, and Lessons Learned reports. Informal communication is more focused on the expression of the communication elements, which includes speaking, writing, presenting, gesturing, and other verbal and nonverbal cues that can greatly impact the receipt of that information. While the basic elements of informal communication, are common across most industries, formal communication practices such as forms, procedures, and protocols which are specific to the mobility industry will also be discussed in this chapter. Before we explore each of the three processes of Communication Management, it would be helpful to visualize the overall communication process before we deep-dive into the elements of communication management. In order for the communication exchange to be successful, whether formal or informal, it must be: (a) accurate, (b) concise and to the point, (c) purpose clearly stated, (d) be logically arranged and e) most important; be tailored to the audience. The 5 WHY process is very useful to ensure that these five points are properly considered: 1. WHO are the stakeholders that need to receive the communication? 2. WHAT is being communicated, that is, what information needs to be communicated? 3. WHY does the information need to be communicated? 4. WHEN does the information need to be communicated? 5. HOW will the information be distributed?
9.2 Case Study To illustrate this, let’s return to the example of the Engine Control Module (ECM). We’ll assume that the project team is presenting to two distinct audiences. In the first case, the Design Review is being presented to the engineering staff to approve new design features to be incorporated into the existing design. The second case is a project overview of the new design features to the executive stakeholders. We’ll examine how the format and presentation to each of these audiences differ and then compare a poorly written agenda to a more audience focused agenda. Figure 9.1 illustrates the differences in presentation and the specific details that should be brought out by the presenter particular to each audience using the 5 WHY method. The Technical Design Review is represented by the left side of the table. Note that the focus is on the product level details of the design in engineering language, details of the deliverable and the schedule in language appropriate to the level of the engineers present. Also included is a notation regarding the specific reporting format to be used for this review to help ensure commonality across projects. The right side of the table shows how the presentation should focus more on how the project team plans on achieving project level customer and organizational objectives related to budget, resourcing, and profitability. Note however that the review will still provide an overview on the progress of the product design in terms of achieving the contract specifications in a language appropriate to executive level stakeholders. This is where the Stakeholder Register (Chapter 4) offers a significant benefit by identifying the specific concerns of
9.2 Case Study
131
© SAE International. All rights reserved
CHAPTER 9
FIGURE 9.1 Product vs. project audience targeting.
each of the project stakeholders. The Project Team can use this information to ensure that the presentations address these concerns. Since the PM is responsible to ensure that both the content of the communication material and the abilities of the presenter are appropriate to the intended audience he is therefore responsible to provide training on proper and effective application of communication skills and protocols for each of the formal and informal communication methods presented above. Other vital communication skill sets include the ability to listen, an understanding of the business culture of both of the organization and customer, conflict management and resolution, and people handling skills. Turning our attention to the Design Review agendas Figure 9.2 compares two agendas for a Design Review for the example provided in Figure 9.1. Note the agenda presented on the left side of Figure 9.2 although it states the purpose of the meeting, it lacks the details to allow for proper preparation of the DR attendees. This is one of the major issues related to ineffective meetings, i.e., lack of information to permit attendees to properly prepare. The second issue is that attendance is left to the discretion of the attendees which can result in the wrong people attending or no representation from the necessary departments. On the right side of Figure 9.2 is a more informative agenda which uses the 5-WHY method. Note that the purpose of the DR is stated clearly upfront “…obtain go-ahead approval…” and states the necessity and consequences of this approval. Also note that particular attendees are mandatory along with conditions; i.e., approval authority.
Project Management for Mobility Engineers: Principles and Case Studies FIGURE 9.2 Comparison of design review agenda quality. DR – Poor Communication Quality
DR – Improved Communication Quality
Design Review Agenda – DR-227 ECM
Approval of New Feature designs to ECM Module DR-227
Design Review Agenda
On Monday July 12th a Design Review is
WHAT: Purpose of this Design review is to
scheduled to discuss several new features to
obtain go-ahead approval for the following
be incorporated in the DR-227 ECM design
customer requested new features to the DR -
as requested by the customer, with specific
227 ECM (Ref EC-597XX) which include:
focus on the design modifications to the ECM circuit board and PROM design. This review will be held in Conference Room B from 10am-12pm. All engineers involved in this effort are invited to participate in this meeting.
1. ECM PROM placement location on circuit board 2. Layout for cooling of PROM 3. Pin Connector configuration for emergency power supply subsystem WHY/WHEN: Approval required to commence ordering of components for prototype build for delivery in support of customer Alpha Trials in 2 weeks. WHEN/WHERE: Conference Room B, 10am-12pm, Monday July 12th WHO: This review will be led by the Product Lead Engineer with the following departments in attendance. Please ensure that each department provides an individual with approval authority to attend: ·
Software Engineering Group
·
PC Component Design Group
·
Electrical Engineering – Connector Division
·
Manufacturing/Prototype Engineering
·
Test Lab Manager
© SAE International. All rights reserved
132
9.3 Communication Planning According to PMBOK, Communication Planning is “the process of developing an appropriate approach and plan for project communication activities based on the information needs of each stakeholder, available organizational assets, and the needs of the project.” In the Automotive Industry, most of these processes are well established for communication between the OEM and the Tier 1 supplier but are not as well developed for sub-tier suppliers. This disconnect is extremely problematic since the vast majority of subassemblies and components are being designed and manufactured at the sub-tier levels. Today’s OEMs and most Tier 1 suppliers operate mainly as system integrators and are not heavily involved in the details of lower-level subassemblies and components.
9.3 Communication Planning
Deficient communication between these levels leads to integration issues when these subassemblies and components are installed into the vehicle resulting in production delays or shutdowns at the OEM or Tier 1 production facilities. Thus, the goal here is not to create new communication processes and documentation but to ensure that, to the extent possible, there is commonality in the presentation and reporting of information throughout the full project team from customer to lowest tier supplier. Establishing this commonality has been the greatest strength of the Automotive industry since APQP and PPAP have evolved into a solid framework of procedural and documentation requirements implanted throughout the supply chain. One example of this is the Design and Process FMEA format that is common throughout the OEM and Supply Chain. While there has been an ongoing evolution of the form the update process and new formats are always communicated to the Supplier Community. Communication Planning, like other aspects of Project Management, has distinct and discrete INPUTS and OUTPUTS. This information is typically maintained in a Project Design File which will eventually become the Design Record File that is submitted as Item 1 in the PPAP approval process.
9.3.1 Inputs to Communication Planning Inputs to Communication Planning include fall into the category of Organizational Process Assets (OPAs) and include a) documents which communicate project details and b) protocols for how those documents are formatted or prepared, distributed, maintained, and ultimately disposed of. Examples of documents which communicate project details includes the following and have been discussed in other chapters: 1. Signed Project Charter—Chapter 5 - Project Integration. 2. Stakeholder Register and Assessment—Chapter 4 - Stakeholder Management. 3. Signed Contract(s)—Chapter 6 - Project Scope. 4. Requirements & Traceability Matrix—Chapter 6 - Project Scope. 5. Lessons Learned (TGR/TGW) database—Chapter 5 - Project Integration. 6. New Product Development Model (NPD)—Chapter 6 - Project Scope. 7. Risk and Feasibility Assessments—Chapter 11 - Project Risk Management. 8. Resource Management Plan—Chapter 10 - Human Resource Management. Examples of protocols for communication planning can be found in the Section 5 of the Communications Management Plan shown at Appendix C. The source material for creating these formats, templates, and protocols was discussed in Section 1.8 of Chapter 1. Recall that the organization’s Quality System or Program Manager is responsible to take high level industry standards such as ISO-9001, APQP and PMBOK and create organization or project specific formats and protocols adapted from these highlevel standards tempered with data obtained from Lessons Learned information.
9.3.2 Outputs to Communication Planning The primary outputs to Communication Planning are the Communications Management Plan, Stakeholder Register and Engagement Matrix, Project Charter, and Security Protocols. 9.3.2.1 COMMUNICATION MANAGEMENT PLAN Once the inputs are obtained the project team can use them to develop the Communications Management Plan (CMP), which is the chief output of Communications Planning.
133
CHAPTER 9
134
Project Management for Mobility Engineers: Principles and Case Studies
This document is approved by the project sponsor as it identifies the methods, protocols, and platforms to be used throughout the project. A sample template of a CMP for a typical automotive project is shown in Appendix C. While content can vary based on the needs of the organization and the project, the following sections are typical of an automotive CMP: •• Key contact list •• RASIC matrix •• Communications technology platforms & protocols •• Communications reporting methods and formats •• Other Communication Platforms as required •• Glossary of key terms Some of these, such as the Key Contact list and the RASIC matrix are not necessarily separate documents but can be part of a larger document or file such as the Project Charter or Staffing and Resource Plan. As was previously mentioned, the protocols and reporting formats for the automotive industry are fairly standard. Note that the CMP is signed by the project sponsors and key stakeholders to ensure they understand how project information will be communicated. Normally, the CMP is maintained at a company level and is not project-specific, although there are certain portions that can be adjusted to address project particularities; however, these exceptions should be signedoff by the project sponsors. Since today most companies use some type of company share drive or cloud application, a generic CMP can reside on the share drive as an organizational resource to ensure commonality among different projects, thus creating a template format that is used for future projects. The CMP should identify areas of flexibility in application, which can be adjusted at the discretion of the PM or project sponsor to suit any special particularities of the project and should identify the location of communication protocols and templates necessary for project reporting. A glossary of key terms is helpful for those new to the company, especially for those who are from outside the automotive industry. 9.3.2.2 STAKEHOLDER REGISTER AND ENGAGEMENT MATRIX See Chapter 4. 9.3.2.3 SPECIAL CONSIDERATIONS FOR COMMUNICATION SECURITY The CMP must identify security requirements for information distribution both for external and internal communication. A lack of an established and enforced communication security policy results in proprietary information to be released to unauthorized persons or mistakenly mailed or taken outside the organization’s facility without proper review. Often times the project team is unaware of the release of information until informed by either the customer or as a result of a Quality Audit. With the proliferation of social media platforms, it is also important to have strict policies regarding the use of any cameras or phones in areas where sensitive information or products are being used, especially in the Prototype and testing areas. Engineering desks and conference rooms should also be cleared of any proprietary documents or products upon completion of the meeting or discussion. Disposal of any potentially sensitive documents should be done before the employee leaves for the day. While most Mobility suppliers have badge control entry into their building, most office areas and R&D laboratories and prototype shops are not adequately security monitored. This allows anyone including visitors the ability to gain access to propriety and competitive material, and it only takes a few seconds to snap a couple of pictures. Table 9.1 identifies documentation and facility situations that should have clearly defined security protocols.
9.4 Managing Communications
135
© SAE International. All rights reserved
Documentation and material
Facilities and areas
PPAP documentation
Engineering Design offices
Design Record Files
Prototype Lab
Prototype or R&D design information
Benchmarking Areas
Prototype, Mockup, or Alpha/Beta samples
Testing Labs
Project Schedules
Mockup Manufacturing Areas
Strategic Business reports that identify company and/or new product strategies
Conference Room Boards wiped of any sensitive information
Project Budget reports
Engineering Desks and wastebaskets secure of any proprietary information
Proprietary drawings and notes
Phones with cameras and cameras controlled
Test reports
Recording devices controlled
Vistor escort procedures
Considerations for security monitoring
Customer sensitive documents
Badging and access control process, employees, and visitors
New Employee Security Protocol Training Contigency response for security breach Cyber Security protocols
9.4 Managing Communications According to PMBOK, managing communications is “The process of creating, collecting, distributing, storing, retrieving, and the ultimate disposition of project information in accordance to the communications management plan.” While planning is important the best plans are not of much use if there is nothing in place for how these plans will be managed during the project, what communication platforms will be used and how key information will be passed on to future projects. Communication management ensures efficient, effective and timely communications flow between project team members and stakeholders. Factors that influence the proper management of project plans include: •• Selection of communications technology •• Urgency of Need •• Availability and accessibility to project stakeholders •• Ease of Use •• Project Environment ■■ Hard Contact (meetings, phone or conference calls, Skype, etc.) ■■ Soft or Virtual Contact ■■ Business Location and Language ■■ Culture – business and regional •• Confidentiality requirements for project information (see section 9.3.2.3)
CHAPTER 9
TABLE 9.1 Areas of concern for security protocol.
136
Project Management for Mobility Engineers: Principles and Case Studies
© SAE International. All rights reserved
FIGURE 9.3 Communication relationships of the PM process groups.
9.5 Controlling and Monitoring Communications
While it is important to plan for and manage commu nication it is equally important to determine whether project communication systems and processes are operating properly and are adjusted or modified to respond to the dynamic nature of Mobility based projects. As part of the Monitoring & Controlling process group, the project manager must put in place communication controls at established project status update points and ensure that stakeholders are receiving these updates. While a large part of the controlling process involves ensuring that the proper procedures are in place and being applied properly the monitoring process ensures that policies and procedures are being reviewed for currency, accuracy, and effectiveness. Figure 9.3 graphically portrays the relationship between the major project management process groups; Inputs/Outputs, Planning, Executing, and Monitoring and Controlling. The organization, with help from Project Managers should have in place methods of controlling and monitoring the activity which is occurring in each of the process groups during the project and making sure that corrective action and updating of policies and procedures is occurring. The annual Quality Audit can contribute to this process by having a part of the audit include Monitoring and Controlling methods. It is the responsibility of the PM and related stakeholders to point out deficiencies in the control and monitoring of communication processes to the Quality Auditors so that the entire organization can benefit as opposed to improvement on only a project level.
9.5.1 The Four Areas to Monitor and Control PMBOK identifies the following four (4) areas that require monitoring systems and processes to be managed by both the PM of the project and the organization. 1. Project management plan – Part of the Inputs and Planning Process Group and includes Resourcing management, Stakeholder Assessment and Engagement, and Communications management. 2. Project documents – Part of the Execution Process Group and includes Technical scope for both design and production assets, Lessons Learned Logs, Corrective Action reports, Risk Assessment documents, Engineering Change documents, and Test reports. 3. Work performance data – Part of the Executing, Outputs and Monitor/Control Process Groups. Executing includes data on how well the project team and other stakeholders are performing according to the tasks outlined by the WBS. Output Data includes the deliverables identified in the Planning Process. These include prototypes, drawings or CAD models, test reports, etc. Monitoring is where some form of Earned Value Analysis is helpful to track both actual team performance. Controlling is the reaction to project and product scope changes, both internally and externally generated to ensure that the work being accomplished is aligned with the contracted scope.
9.5 Controlling and Monitoring Communications
137
9.5.2 Hard vs Soft Communication – the Push – Pull System One significant issue facing the Mobility Industry in the area of Monitoring and Controlling is the overuse of hard contact when managing communications during a project. Typically, communication is managed either through a pull system or a push system. In a pull system the PM or Project Leader is tasked with pulling necessary information from project stakeholders. Examples are meetings such as Design or Gate Reviews or Status Updates whether in person or virtual. In a meeting the PM must pull information from each of the participants and often cannot be sure if the information is accurate, complete, or if it addresses the issue(s) at hand. In a push system information is pushed to the PM by the stakeholders according to predetermined report formats that allow the PM to make assessments regarding the ongoing progress of the project. Figure 9.4 identifies some hard (pull) versus soft (push) contact methods. With this information the PM has the option of reacting immediately by contacting the affected parties and resolving the issue as soon as discovered or if not critical he can add these items to the upcoming meeting agenda. This allows for the creation of a concise meeting agenda which addresses specific problem areas rather than wasting resource time addressing items which are on track or progressing well. Examples of push system are WBS tracking sheets, Engineering Change documents, Test reports, and Earned Value Analysis reports. The PM would work with the IT department to develop an automated report format that can synch with existing PM Management Systems. Once the project team members become accustomed to this push system the PM or Project Leader has improved flexibility and ease for managing the project through established metrics which can pass down to the Supply Base.
9.5.3 Engineering Change Management (ECM)
© SAE International. All rights reserved
While the purpose and importance of the ECM system was discussed in Chapter 5 (Project Integration), a few additional thoughts are necessary here. From a communication Management perspective, a functional and effective ECM system, as part of FIGURE 9.4 Comparison of hard versus soft contact methods. monitoring and controlling, provides both the customer and the supplier a clear path of evolution for a particular design and it is also a gage for evaluating an organizations’ ability to successfully navigate and control design changes. The engineering change history also provides a documentation trail of why design decisions were made which can be important in the event of product liability or warranty claims. The source of engineering changes are
CHAPTER 9
4. Enterprise environmental factors (EEF) and Organizational process assets (OPAs) – Part of Monitor and Control since EEF are monitored to assess their impact on the project and/or the organization and the OPAs are controlled to ensure that policies and procedures are updated and adapted to respond to EEFs.
138
Project Management for Mobility Engineers: Principles and Case Studies
either INTERNAL; generated by the design organization to address a particular in-house design issue or EXTERNAL; generated by the customer to incorporate a new design requirement or address a design issue discovered through customer-level testing or field reports. One essential project metric is the current average of engineering changes (EC), by customer for both internal and external changes. This information is then used to develop a plan of action to address mitigation of engineering changes and customer management. Several scenarios are possible here:
1. 2. 3. 4.
PM discovers a high number of internal changes on new development projects PM discovers a high number of external changes on new development projects PM discovers a high number of external changes on carryover projects PM discovers a high number of internal changes on carryover projects
In scenario 1, there may be no reason to be overly concerned since it is normal to expect a new design to experience design changes due to evolution and operational situations that were not identified. An example of this would be a manufacturer that is prototyping a new manufacturing method that could reduce processing costs. In scenario 2, there may be no reason to be overly concerned since this may be the case where the customer is also exploring new design territory or emerging technologies. Automotive cyber security is a good example of this. In scenario 3, there is reason for concern since this could indicate a customer who is using the supplier to fund exploratory research, at the supplier’s expense. Carryover projects typically involve minor changes to the design to address new model lines or platforms but should not require extensive redesign and Design Verification testing. In this case, the PM would set up protocols to alert him or her when EC levels reach a preset limit to ensure that project costs, and timing, do not get out of hand. Finally, in scenario 4 we have the most detrimental situation since this potentially indicates that the organization’s design or manufacturing process is making repeat errors and that Lessons Learned are not being properly applied. As was stated in scenario 3, carryover projects typically involve minor changes so that the organization should have a clear and established plan. In this case, it is vital that the PM establish preset EC levels to help isolate where problem areas are. The single greatest source of project cost overruns are poor management of engineering changes which is typically the result of a poorly built ECM system or a lack of proper enforcement of ECM protocols, or both. A robust ECM process is critical for allowing the PM to “manage and regulate” his or her customer’s expectations, especially in cases where the customer tends to gold plate the designs, leading to extensive time and money in redesign. It is difficult for engineers to manage this as they see this as hindering a good design process and tend to enjoy working with customer engineering to develop the best possible design. It is therefore up to the PM to ensure that the baseline scope of work is being accomplished and that any modifications to that baseline are communicated back to the customer for adjustment of the baseline scope (referred to as Earned Value). If the customer refuses to accept the additional cost associated with the engineering change, then the PM has the responsibility to communicate with the project sponsor(s) to determine if the changes are in the best interest of the company goals and objectives. The reality is that consistent cost and timing overruns due to external changes might necessitate a more cautious approach to continued business with that particular customer. Consistent internal changes might indicate a need for additional competency training or a reassessment of how engineers are selected for particular projects.
C H A P T E R
CHAPTER 10
Human Resource Management
10
10.1 Introduction and Overview Even with the best scope plan and unlimited budget, every project requires resources in order to accomplish the stated objectives. Human Resource Management is the process of identifying and documenting the organizational structure, personnel roles and responsibilities particular to the project, required skill sets, and appropriately and effectively task-loading each member of the project team and the support staff. The Staffing Management Plan (SMP) is the document that captures this information and is part of the overall Project Management Plan (PMP). The SMP defines several key steps for the successful resourcing of a project and includes:
1. 2. 3. 4.
Defining Organizational and Project Team structures Acquiring and staffing the resources necessary to achieve project objectives Organizing the Project Team and establishing performance metrics Management of the full Project Team
10.2 Organization Structures Organizational Structure is usually in the form of a company organizational chart that shows the interface relationships between the project manager, functional (line) managers, and the project team. There are several styles of organizational structures and the PM should work with the internal project sponsors to develop a structure that allows the PM to maximize the flexibility and authority of the project team to operate within the company as required to achieve the project objectives. His or her ability to ©2020 SAE International
139
140
Project Management for Mobility Engineers: Principles and Case Studies
achieve this is, of course, subject to the importance of the project to the overall business objectives of the organization (see Chapter 6 Scope Management, Section 6.2.1). While it is not important to go into great detail on how to structure organizations, it is helpful to be familiar with the following basic types of organizational structures and their respective advantages and disadvantages.
10.2.1 Classical or Line Staff This is the typical hierarchal structure and was the most common form of organization in companies (Figure 10.1). In this type, functional managers retain control, both personnel and budget authority, over their respective departments. While any of the Functional (Departmental) managers shown in Figure 10.1 can serve as Program Manager, for most Automotive companies, the Engineering Manager is typically serves the dual role of Program Manager and has full responsibility to determine and assign all project tasks that are completed by his or her staff. The Engineering Manager is therefore accountable for both engineering design work and PM related tasks and issues daily assignments to his staff which comprises the project team. This type of organizational structure is rapidly disappearing due to several disadvantages, which include the following: 1. Communication with other functional areas (departments) is often limited so that project focus is diminished. 2. Little to no formal Project Management training on the part of the Engineering Manager and his or her staff. This lack of education on the effectiveness of applying PM principles results in the functional manager to believe that formal PM is not important and therefore not encouraged. 3. The project team is derived from members of the functional manager’s staff with one individual selected to serve as project coordinator. This results in project focus primarily on design with limited attention given to other areas such as manufacturing, quality, test, reliability objectives, etc. FIGURE 10.1 Traditional Hierarchal Structure.
President
Program and Project Management occurs at the Func onal Level
Design Staff
Engineering
Quality
Manager
Assurance
CAD
Product Engineers
Marke ng Sales
VPO
R&D
Plant Manager
Quality Control
Advanced Development Engineers
Plant Staff
QC Staff
© SAE International. All rights reserved
Director Engineering
10.2 Organization Structures
141
4. Project coordinator is given little or no project authority and is most likely working alongside his or her peers and has limited influence on ensuring tasks are performed on time or to a standard of quality. 5. Rapid resolution of project risks is difficult since all information flows through a very rigid hierarchal structure with each managerial level requiring time to review and provide guidance and/or approval.
According to PMBOK, a matrix organization is a blend of the projectized and the hierarchal organization structures. The authority of functional manager flows vertically, and the authority of the project manager or project coordinator flows horizontally, creating a matrix structure. In a matrix organization structure, team members often times report to many managers, across multiple product platforms or lines. The Matrix structure has three variations: weak, balanced, and strong. a. Weak Matrix Organization Structure A weak matrix organization structure resembles the characteristics of a Hierarchal organization structure in that overall project responsibility is still at the Functional level. The project team is provided by each functional manager as required and is indicated by the red boxes shown in Figure 10.2. Additionally, the Functional Manager appoints one of his staff the role of project manager. (In Figure 10.2 this person is identified as the Design Release Engineer (DRE). This position has limited power and authority (hence the term “weak”) so that his or her position is more appropriately termed project coordinator. Project management is typically a part-time role with limited or no access to administrative staff. The functional manager retains control over the project budget and scope change approval. Since the project coordinator is a peer with respect to his team management, task assignment is difficult due to similar concerns as in the Hierarchical structure. Additionally, the coordinator also functions as designer, engineer, representative to manufacturing, etc. This is the standard organizational structure for most automotive Tier 2 and below suppliers (Figure 10.2). FIGURE 10.2 Weak matrix structure.
© SAE International. All rights reserved
Program Management occurs at the Func onal Level
Eng Manager
MFG Manager
DRE 1
ME 1
QE 1
TE 1
DRE 2
ME 2
QE 2
TE 2
DRE 3
ME 3
QE 3
TE 3
Each DRE assigned as Project Coordinator for a par cular project
Quality Manager
Test Lab
CHAPTER 10
10.2.2 Matrix
Project Management for Mobility Engineers: Principles and Case Studies
b. Strong Matrix Organization Structure The strong matrix structure is closer to the projectized organization structure since Project Management is no longer an afterthought but has become a Functional Area alongside Engineering, Manufacturing, Quality, etc. (see Figure 10.3) The title of Program Manager is appropriate since he or she manages a staff of project managers each of whom is assigned individual projects and has the authority to cross level resources between projects to balance the overall needs of the organization. Project authority, however, both in terms of personnel and budget, is held by the individual project managers and the project manager functions full-time in this role, is formally trained and experienced as a PM, and has an administrative staff under him or her (not shown in Figure 10.3). The project team members are still provided by each of the functional manager as required and is indicated by the red boxes shown in Figure 10.3, however day-to-day management of these personnel is now performed by the Project Managers. Advantages to the Strong Matrix includes: (a) Project Manager can provide input into the team member’s annual performance review thus increasing the motivation of the project team members towards accomplishing project goals (b) Since the Program Manager is equal to the other Functional Manager they have increased authority to negotiate with Functional Managers when team members are pulled away on side projects issued by various functional managers. (c) Project Managers report directly to Program Manager who are project and product focused helping to ensure the project management skill training is weighted equally with technical training. Disadvantages to the Strong Matrix are mainly the cost of employing both a project and program staff however this organizational structure is used in most DoD, Aerospace and Automotive OEMs and Tier 1 suppliers. FIGURE 10.3 Strong matrix structure.
Eng Manager
MFG Manager
Quality Manager
Program Manager
DRE 1
ME 1
QE 1
PM 1
DRE 2
ME 2
QE 2
PM 2
DRE 3
ME 3
QE 3
PE 3
Each Project Manager is managed by the Program Manager
© SAE International. All rights reserved
142
10.2 Organization Structures
143
FIGURE 10.4 Balanced matrix structure. Program Management occurs at the Func onal Level
Eng Manager
MFG Manager
DRE 1
ME 1
QE 1
TE 1
DRE 2
ME 2
QE 2
TE 2
DRE 3
ME 3
QE 3
TE 3
Quality Manager
Test Lab
Each DE operates as Project Manager for a par cular project
Additionally, each Project Manager provides input into the team member’s annual performance review thus increasing the focus of the project team members towards accomplishing project goals while monitoring the time they spend on side projects issued by various functional managers. The Program Manager is responsible to task each of his Project Managers and conducts their annual performance reviews. This is a standard organizational structure for most automotive OEMs and Tier 1 suppliers (Figure 10.3). c. Balanced Matrix Organization Structure In balanced matrix organizations, power and authority are shared between the functional managers and the project managers. (See Figure 10.4). The project manager is formally trained (as in the STRONG Matrix structure) and has some degree of project management experience, however the Functional Manager serves as the Program Manager as in the WEAK Matrix structure. His or her role is mostly full-time but might still retain technical design responsibilities such as review and approval of the developing design. There is typically a part-time administrative staff that is shared among all of the project managers and in most cases the project manager has at a minimum some level of project budget authority. Due to the balance between cost effective use of resources and project authority this structure is common to most Tier 2 and below suppliers.
10.2.3 Projectized or Silo Structure Projects are aligned by product or platform lines as shown in Figure 10.5. As in the case of the Matrix structures personnel are obtained from the functional departments, however the functional areas lose control over these assets once assigned to the PM. Advantages include the ability of the PM to hold almost exclusive project control (budgets, timing, etc.) and have the ability to secure their own resources whether internal or externally contracted. The PM has a high degree of motivational influence since he or she typically conducts the performance reviews for their team members and has hire/fire authority.
CHAPTER 10
© SAE International. All rights reserved
Project Management for Mobility Engineers: Principles and Case Studies FIGURE 10.5 Projectized structure.
Program Manager
Project Manager North America
ENG Manager
DRE 1
DRE 1
DRE 1
DRE 1
MFG Manager
ME 2
ME 2
ME 2
ME 2
Quality Manager
QE 3
QE 3
QE 3
QE 3
Each Func onal Manager controls staff horizontally
Project Manager Asia
Project Manager Defense
Project Manager
Truck/Agricultural
Each PM controls staff ver cally
Functional managers are responsible to maintain technical competencies of the resources they provide and are also responsible to ensure that their resources are routinely cycled among the various platforms to allow for a diverse experience among the full range of the organizational customer base. Disadvantages include: a. Project teams operate as separate entities, which severely reduces cross-platform communication. b. Similar negative impact on skill development as in the Hierarchal structure but in reverse. The PM and/or the Functional Manager is often not attentive to the professional development needs of his or her project team so that their skill sets become “stale” by not being afforded the opportunity to keep up with the latest technological advances in their field. c. “Siloing” of project teams can create the situation where different teams can be working on different solutions to the same problem and since cross-platform communication is limited, application of organizational level Design Best practices is hindered. This type of organizational structure was attempted about 10–15 years ago by several automotive OEMs and was discontinued due to the adverse impacts of the disadvantages listed. However, this structure is very effective when a supplier wishes to invest in a field office for expanding a market base or providing local design and logistical support to a customer. For example, if a company wishes to expand into Asia or South America, it is probably not cost-effective to resource a Hierarchal or Matrix structure in country but a small “projectized” office can be a cost-effective way to determine if a long-term investment is desirable (Figure 10.5). 10.2.3.1 SPIDER WEB This is a special case of Hierarchal structure except that command and control is more decentralized. This structure is typical of organizations with a very small number of employees (about 10–15) since it allows a company with limited resources to increase the speed and efficiency of communication and work task accomplishment by requiring that each employee perform multifunctionally. This structure typically defines how
© SAE International. All rights reserved
144
10.3 Acquiring and Staffing the Resources
© SAE International. All rights reserved
FIGURE 10.6 Spider web. entrepreneurial companies operate before transitioning into traditional corporate structure. Unlike the Hierarchal structure, there is no formal chain of command and the communication and reporting structure can jump levels as QE required. These multiple and intersecting levels of commuPlant Manager nication create a picture which represents a spider web, hence the name (see Figure 10.6). Using the example shown in Figure 10.6 the design engineer can speak directly with ENG the company owner to quickly address project concerns Manager without going through the layers of communication and Owner approval required in a traditional hierarchal structure. Equally so, those closest to the center of the spider web must CAD be able to immediately fill in when necessary. For example, Quality if the ENG Manager is out of the office, the Plant Manager Director must be able to step in and complete the design on CAD, while the Quality Director must be able to fill in for Sales. The disadvantage of this type of structure is that it breaks DE down once the organization becomes large and needs to transition to one of the afore-mentioned structures. This transition is often difficult since the originating e ntrepreneur often does not recognize when this transition needs to occur, which stifles the growth of the organization and his or her desire to maintain overall control becomes cumbersome and time-consuming to the customer. Also, the emotional attachment to “what has been built” clouds the actions of the entrepreneur and his desire to maintain control overshadows the power of the spider web structure. This structure, as with the Projectized Structure, is also effective as a temporary organizational structure when a company wishes to invest in a field office for expanding a market base or providing local design and logistical support to a customer without the large investment of resources.
10.3 Acquiring and Staffing the Resources a. Once the PM has worked with the various functional managers to achieve a suitable structure organizational structure from which to operate, the PM must then acquire the necessary resources to staff his or her project team. Typically, within Automotive most companies do not allow the PM to select project team members by name and are at the mercy of the functional area regarding personnel provided. Oftentimes, the person(s) provided do not possess the required skill levels and, if they are still under the control of their Functional Managers, (i.e. Hierarchal or Matrix structure) they are not allotted the time required to complete the WBS project tasks assigned to them. Rather than request project personnel by name which can lead to favoritism or experienced PMs hand picking particular personnel, the PM should clearly define what are the specific skill and proficiency levels required for the particular project. Not all projects will require the same skill level, so the Functional Managers can select personnel based on factors such as skill level, cross-product experience, or promotion to higher level projects. If the PM is unable to express definitely the skill required, then he places himself in the position of dealing with the additional risks associated with tasks taking longer to complete than estimated based on lack of proficiency and/or having resources pulled at critical times. However, it is also inappropriate for the PM to send a general request to the
145
ME
TEST & Quality
TE Sales
CHAPTER 10
146
Project Management for Mobility Engineers: Principles and Case Studies
FIGURE 10.7 Sample HRP.
HUMAN RESOURCE MANAGEMENT PLAN
Project Manager Product Design Eng Manufacturing Eng Supplier Quality Materials Eng Project Team Project Manager Product Design Eng Manufacturing Eng Supplier Quality Materials Eng TOTAL Staff Resource Silvia Dody Design Engineer Manufacturing Eng Materials Eng
TOTAL
Name
Es mated Start Date
Skills Required
Silvia Dody
APQP, PMBOK, ECM Advanced Materials Selec on, APQP PPAP, Processing advance materials PPAP, APQP, ISO Audit Advanced Materials Selec on and processing PROJECT STAFF REQUESTS & COSTING MnHours Name Requested Available Rate 850 Silvia Dody 1 100% $85.00 580 1 50% $70.00 750 1 50% $70.00 200 2 80% $70.00 120 Contracted Service 1 100% $300.00 $177,200 6 TRAINING REQUIREMENTS Es mated Cost Training Requested $2,500.00 APQP $7,500.00 Composites Selec on and Manufacturing $1,200.00 FMEA $7,500.00 Processing composite materials, Lamena on processes $12,000.00 See Sec on C of Technical Services contract
Dura on Required Project Project 8 months 4 months 2 months
Department Eng Eng Produc on Quality Eng
Vendor Skills Corp. ALT MTLS Inc. Skills Corp. ALT MTLS Inc. STS Resources
$30,700.00
functional areas with open-ended times for each of the requested resources since the Functional manager cannot then adequately schedule his resources across the various product or platforms under development. Therefore, at project start, the PM should formally request to each Functional Manager the specific resourcing needs, which can then be used as a basis for negotiating the provision of resources. This request should include at least three specific items for each of the assigned resources: b. Specific skill set and level of proficiency required c. Number of project staff and percent availability required d. Duration indicated by start and end dates This information is contained in a document referred to as the Human Resource Plan (HRP) and a simple format that addresses each of these three areas is shown at Figure 10.7.
10.3.1 Availability and Proficiency Matrix In small companies (