Engineering Project Management

​

Instructor: Angelo Mago

​

​

​

I.D. #99003

Course Objectives

• Describe the benefits of Project Management (PM) as used within the Mobility Industry.
• Relate the techniques of PM as they apply to each other.
• Extend and adapt the methods and techniques of PM and APQP to your particular situation.
• Develop leadership and management principles critical to managing resources effectively.
• Conduct team-focused case studies of key elements of an APQP Project Plan.

By the end of this course you will be able to:

Seminar Modules

1.

​

​

​

​

2.

3.

​

​

​

​

4.

​

​

​

5.

​

• The Why, What, When, and Who of Project Management (PM)
• Types of PM
• PM Life Cycles
• Mobility PDP Overview – APQP and PPAP
• Stakeholder and Integration Management
• Scope Planning and Management
• Organizing VOC
• Scope Development and Scope Tracking
• Understanding and Using WBS for Project Organization
• Quality Management
• Robust Design Methods
• Special (KEY) Characteristic System
• The Design Review Process
• Schedule Management
• Personal Time Management
• Advanced Scheduling Methods

3

Seminar Modules

6

​

​

​

​

​

7.

• Resource and Communications Management
• Communications Planning
• Team Formation and Project Team Dynamics
• Types of Meetings and Meeting Protocols

​

• Risk Management and Product Liability
• Product Based
• Design Prioritization Matrix
• Pugh Matrix
• FMEA
• Project Based
• Risk Register and Quadrant Mapping
• Expected Value Matrix
• Probability Impact Matrix

​

​

4

MODULE 1: PM OVERVIEW & INTRODUCTION

​

1. THE WHY, WHAT, AND WHEN OF PM
2. TYPES OF PM
3. THE PM LIFE CYCLE
4. MOBILITY PRODUCT DEVELOPMENT PROCESS (PDP) OVERVIEW – APQP AND PPAP

Sources of Project Variability?

1. Environmental Factors. These include market variability, business culture, and operating systems being used during the project.
2. Resource Fluctuations. Variability associated with financial and physical resource fluctuations. This could be monies or team members transferred to another project the organization feels is more vital.
3. Schedule Impacts from Customer. While this varies with the type of customer. Often emerging technologies can result in a customer shifting the focus of the project or product scope.
4. Performance variability. Variability due to uncertainty of product performance during development, in either technology or manufacturing, or both. Also includes issues resulting from variabilities in team member performance .
5. Schedule Impacts from internal organization issues Variability associated with scheduling issues and internal conflicts which impact release to Full-Scale production.

​

Outside the control of PM

Within the control of PM

WHY

6

Issues facing the Project Manager

• The design challenge is not properly bounded
• Failure to not properly demonstrate, through prototyping or other means, that product works
• Incomplete design reviews of the system and subsystems
• Failure to obtain stakeholder concurrence with respect to design adequacy
• Failure to fully quantify and qualify potential failure modes and their effects on performance
• Incomplete flow down of key design-level characteristics to critical manufacturing and assembly processes
• Leadership and Management skills not properly developed
• Managing product requirements versus managing project tasks
• Inability to properly manage risk

​

Within the control of PE

WHY

7

Additional Issues facing a Product Manager

• VOC not formally organized and translated for team understanding.
• Misuse of ECMS to address Project Scope Creep
• Inability to properly apply the full range of DFSS methodologies
• Lack of understanding of value creation during Product Development
• Response to issues is reactive in nature
• System level issues discovered during operational phase
• Incomplete design reviews of the system and subsystems
• Inability to properly manage risk

​

WHY

8

The Constraint Triangle

Project Managers are constantly balancing both Customer requirements and organizational influences (EEF) against constraints. The traditional expression of these constraints is:

The Statement of Work (SOW) should identify and document these influences, constraints and assumptions.

As these factors can often be outside the control of the Project team, communication of these issues to the project stakeholders (customer, sponsors, etc.) is essential.

WHY

9

The Updated Constraint Triangle

A new expression for project constraint, which places focus more squarely on benefit and value is proposed by Angelo Baratta* and is shown as:

Baratta states that the value delivered is a function of the scope of the project opportunity and the capability of the process used to deliver it. Expressed in equation form

Value = ƒ(scope, capability)

This better aligns with the idea of value creation presented in the new PMBOK, with a focus on developing technology and processing capabilities within the organization which provide improved benefit to their customers.

WHY

10

What is a Project?

• An Endeavor
• undertaken to create a unique product or service.
• Temporary
• defined by a beginning and an end
• Constrained
• usually by a window of opportunity or customer mandated timeline.

pg 4

Projects :

• are performed by people of various abilities
• can be a product, service, or improvement
• are planned, executed and controlled (at some level)‏

WHAT

11

Project Management as Risk Management

• Risk has been defined as

a combination of constraint and uncertainty

​

• PM is an organized and long-standing methodology for identifying the sources of project variability and qualifying (and quantifying) these constraints on a project.
• PM also affords techniques of varying sophistication to minimize, to the extent possible, these variabilities in the project.
• No amount of PM can eliminate all constraining factors or identify all risks, however up-front planning and good leadership is vital to preparing and implementing preventative action.
• Effective PM depends upon documenting these Lessons Learned for use by future Project Managers.

WHAT

12

Knowledge Areas of TPM

The PM Body of Knowledge defines 10 areas, each of which must be managed to ensure project success.

4. Project Integration
5. Project Scope
6. Schedule Management
7. Cost Management
8. Quality Management

9. Resource Management
10. Communication Management
11. Risk Management
12. Procurement Management
13. Stakeholder Management

WHAT

Pg 25

For this course we will only cover the areas highlighted in RED.

13

How Much Project Management Do I Need?

Application of PM should be appropriate to:

• The degree of project control required to accurately achieve project objectives. (both customer and internal)‏
• The amount of time available to complete the project.
• The culture of the organization or the project team.
• Sponsor willingness to extend the required authority to the project manager(s) and their staff.
• Stakeholders willingness to provide appropriate level of resources to support to the Project at the required times and duration.

14

Differentiating Project, Program, and Line Management

• Project Management
• Organizational effort to bring a particular product or service to market.
• Responsible for coordination and communication of all project tasks as appropriate.
• Program Management
• Group of projects managed in a coordinated way to obtain benefits not available from individual project management.
• Provides executive level oversight and cross-levels company resources across various projects.
• Operations (Functional) Management
• Management activities associated with day-to-day operations to maintain organizational and operational effectiveness.
• The personnel which typically perform sub-project tasks for the Project Manager are sourced by the Operations Managers with whom the PM must work to maintain good communication.

Pg 11

WHO

15

Competencies of a �Successful Project Manager

KNOWLEDGE

• Effective application of project management techniques and principles.
• An ability to appropriately scale advanced level PM processes to specific projects

​

​

Pg 56

PERFORMANCE

• Leadership skill
• Management skill
• Motivational skill
• Balancing of available resources

PERSONAL

• Cultural, Social, and Political drivers
• Conflict Management
• Interpersonal and communication skills

​

​

WHO

16

Typical Project Management Models

• TPM
• Traditional Project Management for fairly well-defined projects with set schedules and deliverables and well-defined organizational hierarchy.
• Agile
• Adaptable Project Management for undefined or evolving products or technologies which operate in a highly flexible and loose structure.

17

Agile (SCRUM ) Delivery Model

Agile is a blanket term for many frameworks or approaches to non-traditional PM.

Agile is especially useful for high uncertainty projects such as exploratory or ER&D as opposed to definable work such as carry-over product development.

Most Agile frameworks consist of the following elements:

• Short duration tasks and feedback loops
• Frequent process adaptation
• Frequent reprioritizing of tasks based on evolving risk
• Regular updates to the project plan(s)
• Frequent deliverables (when compared to a traditional gated process)

18

SPRINT BACKLOG

OUTPUT

DAILY TEAM MEETINGS

SPRINTS

1-4 WEEKS

24 HRS

Example of a SCRUM Model

Scope validated between customer and Product Owner

PRODUCTBACKLOG

19

Differentiating Between Project Management Models

20

PM Life Cycles

The application of Project Management involves understanding 3 distinct and nested life cycle processes:

Project Management

21

Product Life Cycle

Project Management

22

All products go through5 Phases from Concept through End of Useful Life which include:

1. Conceptual Phase
2. Definition Phase
3. Production Phase
4. Operational Phase
5. Divestment Phase

R&D efforts

Useful Life

Market Decline

Design Freeze

Product Life Cycle

23

Project Life Cycle

Project Management

24

Pg. 38

Types of Project Life Cycles

1. Linear or Traditional Model
2. V-Model
3. Waterfall
4. Evolutionary or Spiral

• Project Life Cycle refers to the Phases that the organization or project team goes through to bring a product to completion, from concept, through development to launch.
• Referred to as the Product Development Process, the most common models are:

25

LINEAR (TRADITIONAL) MODEL

PHASES

26

Source: DOD 5002.R

Linear Example 1 - DOD PRODUCT LIFE CYCLE

27

Linear Example 2 - AUTOMOTIVE (APQP)

28

V – MODEL of PROJECT DEVELOPMENT

for

SYSTEMS

29

DEFINE

DESIGN

VERIFY

LAUNCH

Component

Sub-system Level

System Level

Vehicle Level

Target Cascade

Design Verification

KO

PS1/2

SI

SC

PH

PA

PR

CC

LR

LS

J1

ST

CP

FORD FPDS as an example of V – MODEL

30

WATERFALL MODEL FOR

SOFTWARE DEVELOPMENT LIFE CYCLE

Gather Requirements

Systems Analysis

Coding

Testing

Implementation

Software Design

Operations & Updates

Disposition

Feasibility Study

SDLC

Integration

31

EVOLUTIONARY (SPIRAL) MODEL

The Spiral model combines features of the Waterfall and the incremental prototype approach.

​

​

​

​

​

In this model the radial distance is a measure of effort expended, while the angular distance represents progress made.

Source: DOD Systems Engineering Handbook

32

Project Phase Characteristics

Each Project Phase has the following common characteristics:

• Performance metrics to quantify project status within the constraints of performance, cost and timing.
• Deliverables of some type such as products, prototypes, certifications, or other or handoff.
• documentation.
• Some form of technology transfer

The Design and Phase Reviews serve to evaluate the achievement of project and product characteristics established by the contract and the project plan.

33

Project Management Life Cycle

Project Management

34

Project Boundaries

Project Initiator/ Sponsor

Project Inputs

Project Deliverables

Project Records

End

Users

Process Assets

Monitoring & Controlling Processes

Planning Processes

Executing Processes

Initiating Processes

Closing Processes

Fig. 3-4 pg. 54

Outputs

Project Management Life Cycle

35

Project Level of Activity� Grouped by Process Area

36

EXERCISE 1:

​

​

PROJECT FAMILIARIZATION

&

AND INITIAL PROJECT RISK ASSESSMENT

Exercise – 1�Project Familiarization and Initial Risk Assessment

1. FOCUS - Your company is embarking on a new project. The project focuses on supplying a next generation product to the customer GOCAR.

2. TIMING – Prior to contract award

3. OBJECTIVE - Acquaint the project team to the details of the project.
4. TASKS:

a) Review the following documents:

• PM Planning File - EXCEL PMP Student
• Project Data File - EXCEL Project Workbook Student
• Product Data File - EXCEL Product Workbook Student

b) Using the data above and the 2 slides entitled “Typical issues facing the PRODUCT and PROJECT Manager” as a guide, complete the Team Feasibility Commitment form (TFC) located in the PMP EXCEL file.

38

MODULE 2:

​

ESTABLISHING PROJECT SYSTEM SUPPORT

​

• STAKEHOLDER MANAGEMENT
• INTEGRATION MANAGEMENT

​

​

​

STAKEHOLDER MANAGEMENT

Plan Stakeholder Management

• Planning involves the documenting how project stakeholders will be identified, managed and controlled.
• Stakeholder Management (SM) stresses the idea of building relationships between the project team, stakeholders, and sponsors.
• In this way SM is not just about improving communication
• Inputs to SM include techniques for understanding and relating to the organization’s culture, structure, and project climate.
• Sources of this information include Lessons Learned from previous projects specific to issues and concerns regarding past stakeholder involvement.

​

41

Stakeholders/Sponsors

42

For successful projects, it's not enough to deliver on the customer's demand; projects have to address all Stakeholder and Sponsor expectations.

Identifying and differentiating stakeholders and sponsors is essential first step since many of the important decisions are made by these stakeholders.

​

Stakeholders:

• are actively involved as project team members
• are affected by project decisions
• exert influence over the project
• have a stake in the success or failure of the project
• Have varying levels of involvement during the project life cycle

Sponsors (often called “champions”):

• provide project resources
• play a critical role in developing the project scope and charter
• are affected by the outcome of the project
• have interest or stake in the success or failure of the project
• can exert influence over the project

Stakeholder Management Techniques

Several techniques common to PMBOK are:

• Stakeholder Register
• Stakeholder Engagement Matrix
• Stakeholder Power/Interest Grid

43

Stakeholder Register

• It’s important to know who has the influence and desire to positively (or negatively) impact your project.
• The Stakeholder Register provides the Project Team the ability to clearly outline the expectations, strengths, weaknesses, and opportunities of each identified project stakeholder.

44

Example of a Stakeholder Register

45

Manage/Control Stakeholders

Power/Interest Grid or Power/Influence Grid

​

• The Power/Interest Grid creates a visual map to establish individual stakeholders level of interest or concern and their ability to influence the project outcomes.

​

• The P/I Grid, plots the range of stakeholders from most influential to least influential so that a focused stakeholder management strategy can be developed to manage stakeholders throughout the project life cycle based on their “power of influence”.

46

Example of a Stakeholder Power/Interest Grid

Keep Satisfied

Keep Informed

Manage Closely

Monitor

ENG

VPO

Supplier

TEST

MFG

POWER

INTEREST

Pg. 397

47

EXERCISE 2:

​

​

ASSESSMENT OF PROJECT STAKEHOLDERS

EXERCISE 2 Assessment of Stakeholders

​

• FOCUS – Identify and understand the concerns presented by the project stakeholders
• Timing – Post contract award but prior to Kick-off meeting
• Input Documents
• Stakeholder register – located in EXCEL Project Data file
• TGR/TGW Reports from GM and FORD – Design Record file PRODUCT Data file
• GOCAR ESOW - WORD document labeled GOCAR ESOW
• Team roles – PM/Lead Eng, Account Manager, and Recorder
• Task (Be sure each member of the Project team provides input into the analysis)
1. Using the information from the INPUT documents above, complete the INTEREST/INFLUENCE matrix located in the Project PMP file.

49

​

​

​

PROJECT INTEGRATION

Project Integration

The identification of project requirements, business need, project risks, and resource requirements.

Involves setting up systems and processes (OPAs) to address outside and uncontrollable influences to the project (EEFs).

Pg. 63

Knowledge Area 4

51

External Project Influences

All project are influenced by factors that are outside of the control of the Project Team and must be addressed in the Project Management Plan.

PMBOK refers to these as Environmental Enterprise Factors and defines this term as:

• “…conditions not under the control of the Project team that can influence. Constrain, or direct the project.”

EEFs can have positive or negative impacts on a project and must be identified by the project team to develop strategies to mitigate the risks presented by these factors.

• The next slide lists examples of potential EE factors

Pg. 29

52

Enterprise Environmental Factors (EEF)

• Organizational Structure and Culture
• Organizational Capability, both Technical and Production
• Industry Standards - to include homologation to other country standards
• Human Resources Availability and Administration
• Project Manager and Project Team authority
• Project Communication channels
• Stakeholder Interactions
• Economic and market conditions

Pg. 29

53

Organizational Process Assets (OPA)

• Lessons Learned Register – TGR/TGW
• Stakeholder Assessment (Register) – covered in previous section
• Project and Product level policies and procedures
• Engineering Change Management
• Project Communication Plan – covered in section 6
• Risk Management Methodology – covered in section 7
• Financial Controls – not covered

Organizational Process Assets help address Environmental Enterprise (Organizational) influences typically consist Organization-specific categories such as:

Project Integration

Pg. 27

54

Project Management Plan – Automotive Specific

1. Procedure for Product Development Process to be used
2. Statement of Requirements (SOR) or Engineering Statement of Work (ESOW)
3. Design Record File
4. TGR/TGW Database – (knowledge management)
5. PPAP documentation file
6. Design and Phase review records

A Mobility Project Management Plan consists of elements and documents specific to the Mobility Industry such as:

55

1) Lessons Learned Register

Managing (corporate) knowledge involves not just a process to collect historical information, but also involves:

• Soliciting and capturing new knowledge
• Organizing knowledge for useful retrieval
• Integrating that knowledge across the organization
• Methods for quickly and easily sharing that knowledge

OPA

These management systems do not need to be overly complex but should use a platform that is appropriate to the size of the organization and the complexity of the projects being undertaken.

Also these knowledge databases should be structured so that information can be easily updated when new information becomes available. An example of a typical Mobility register is shown on the next page.

56

57

Governing Standards�for �Mobility�Product Development

2^nd Edition

5^th Edition

IATF-16949

3) Policies and Procedures

58

Project Integration establishes the systems and databases necessary for project success such as:

PRODUCT

• Organizational Quality System
• Product Risk Management
• New Technology ER&D
• Specification Development
• Product TGR/TGW
• Engineering Change Control
• Design Process
• Test Planning and Resourcing

Typical Product & Project Level

Policies and Procedures

OPA

PROJECT

• Organizational Quality System
• Project Risk Management
• Resourcing Plan
• Contract Development
• Scope Planning (WBS)
• Project TGR/TGW
• Project Performance tracking
• Robust Phase Reviews
• Tier Supplier Management

59

Mobility –Specific OPA procedures

• Product Development Process - APQP
• Design Review structure and Meeting Protocol
• DFSS
• Sub-Supplier monitoring and control
• Security Protocols for product and documentation
• Final Product Sign-off - PPAP
• Product Liability Reviews
• Industry and Company Best Practices

The following have a unique approach in the Automotive Industry:

60

Best Practice as Knowledge Management

Knowledge Management seeks to make the best use of the data that is available to an organization, leading to Best Practices throughout the organization.

​

This requires a distinction to 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.

61

4) Change Management� AKA: Configuration Management

Definition: 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.

An effective change control system contains the following features:

• It is tailored from an effective set of guidelines and standards
• it is streamlined, yet encompasses the entire life cycle of the project, recognizing the requirements of each phase of the life cycle.
• it establishes the mode of operation and interface relationship among the company, subcontractors, and customer(s).
• Dynamic change control boards and resource tracking systems are linked and updated in a timely fashion.

pg 94

62

5) Communication Planning

Today’s rapidly-changing customer environment requires organizations to not only respond quickly but also to communicate effectively across internal and external channels.

PMBOK presents several dimensions to consider in the Communications Planning process: (Section 10.1.2, pg 291)

• Communication Requirements Analysis
• Use of technology
• Communication Models & Methods
• Documentation

These typically are documented in a Communications Management Plan (CMP).

63

MODULE 3: SCOPE PLANNING

​

• CAPTURING AND ORGANIZING VOC
• SCOPE DEVELOPMENT
• WBS

Project Scope

5 sub-processes

• Initiation
• Scope Planning
• Scope Definition
• Scope Verification
• Scope Change Control

Key Output - Development of the Scope of Work

Knowledge Area 5

Pg. 105

65

Generic Steps of Project Scope Development

Task

1. Scope Definition

​

• Scope Planning

​

• Establish project timing

​

• Ensure adequate project team and organizational support structure (RASIC)
• Scope Verification

​

• Scope Change Control

Deliverable Document(s)‏

Identify VOC and Contract Type

Translate VOC into Requirements document(s)

Establish project objectives and outline project tasks via WBS

Create Sub-Project, and Design/ Phase Review schedules from MTS

Org Structure and RASIC

​

Monitor Project Cost or Man-hour usage through EVA reporting

Engineering Change Management

66

1. Scope Definition - Capturing VOC

There are seven (7) levels of VOC which the Project team must evaluate.

Although each project will not necessarily have each voice, each should be evaluated to determine its applicability to the project.

1. End User (consumer)
2. Government Regulations (Federal and International)
3. OEM - Design and Manufacturing
4. Organization - Design and Manufacturing
5. Dealers
6. Service
7. Sub Supplier Base

67

1. Scope Definition - Capturing VOC

Voice of the Customer (VOC) must be identified, organized, analyzed, and evaluated to determine what needs to be included ( and not included) in the Project Scope within the imitations of the project resources.

VOC Identification techniques:

• Benchmarking
• Customer Surveys
• Lessons Learned (TGR/TGW)
• R&T Matrix

VOC Analysis techniques:

• QFD
• Affinity Diagram
• Prioritization Matrix

68

Sample Requirements & Traceability Matrix

69

Competitive Technical Assessment

Goals and Targets

Warranty

Regulatory Issues

Co-Relationships

Column Weights

QFD Matrix Worksheet

Customer

Reqt’s

Technical

Reqt’s

Competitive Evaluations

Complaints

70

Waterfall (Phased) Deployment of QFD

71

Affinity Diagram for Travel Mug

72

Prioritization Diagram for Travel Mug

73

2. Scope Planning

Within the Mobility Industry, product development can take two discrete paths, each of which has a unique approach to scope planning:

1. Design and Development of new technology with limited or no experience.
2. Design and development of existing (carry-over) technology with a significant amount of design and field data.

​

New Product Development:

• QFD
• Process Decision Chart (PDPC)
• WBS development

Carry-Over Product Development:

• TGR/TGW Review
• Requirements Matrix
• WBS development from existing templates

74

Process Decision Program Chart (PDPC)

A PDPC is one of the 7M techniques and is useful for systematically identifying what might go wrong with a plan. Countermeasures are developed to prevent or offset those problems.

Different shapes within the hierarchy are used to highlight risks and identify possible countermeasures (often shown as 'clouds' to indicate uncertainty).

The PDPC is similar to the FMEA in that both identify risks, consequences of failure, risk rating, and recommended actions.

​

The PDPC extends the levels of the Tree Diagram levels further to identify risks and countermeasures.

​

Objective

Solutions

Constraints

Countermeasures

75

2. Scope Planning Flowchart

SOR

SOW

WBS

Phase Reviews

Design Reviews

PDS

Cost Tracking

Contract

ECMS

DV/PV Testing

76

Statement of Requirement (SOR)‏

Details the PRODUCT performance requirements.

Often times in Automotive, these documents are combined to form what is termed an

Engineering Statement of Work (ESOW)

PRODUCT & PROJECT DOCUMENTS

Statement of Work (SOW)‏

Details the PROJECT performance requirements.

77

Statement of Requirements (SOR)‏

Product Performance document which:

• Details the PRODUCT requirements.
• Establishes the performance of the product (at some level; concept, system or component).
• Establishes a “contract” between the customer and the organization regarding product performance requirements.
• Identifies Product Scope – pg 123

If the SOR is not written in the Organization’s technical language then there is the intermediate step of translation into a PDS (Product Definition Specification)

Documenting VOC

78

Statement of Work (SOW)‏

Project performance document which:

• Outlines the PROJECT requirements based on the PRODUCT requirements.
• Always written in a TASK format (verb-noun).
• Establishes a “contract” between the PM and the supplier organization regarding project task responsibilities.
• Forms the baseline cost model from which to track cost and schedule variances (i.e. scope creep) as project changes occur.
• Identifies Project Scope – pg 123

79

Terms Specific to SOR/SOW

• “Shall” is used to express mandatory compliance.
• “Will" is used to express a function to be performed by the Customer.
• Use active voice, not passive.
• Avoid "may", "should", and "might" since those terms could infer task requirements not in the contractual SOR.
• Avoid using ambiguous terms such as "any, either, and/or, etc." These words imply that the supplier has a choice. Use of these words leave the scope open ended and could result in failure to obtain compensation.
• Define your terminology and be consistent throughout the document.
• Make sure that words and phrases (especially technical ones) are used in the same way throughout both the SOR and the SOW.
• Create an SOW or WBS dictionary and acronym list as necessary

80

EXERCISE 3:

​

​

REQUIREMENTS & TRACEABILITY MATRIX

(RTM)

EXERCISE 3 RT Matrix

​

​

• FOCUS – Collect VOC scope and record on RT Matrix
• Timing – Phase 1
• Input Documents
• DFSS worksheet file
• Other documents from previous exercises as required
• Team roles – Lead Eng, Mfg, Purchasing, Quality, and Recorder
• Tasks (Be sure each member of the Project team provides input into the risk analysis)
1. Complete Affinity Diagram and assess quality of remaining DFSS documents
2. Using the data from the DFSS documents above complete columns 2,3, and 4 of the Requirements & Traceability Matrix and verify the values in column 6.

82

​

​

​

WORK BREAKDOWN STRUCTURE

(WBS)

Work Breakdown Structure (WBS)‏

• Deliverable oriented graphic grouping of projects elements that organize and define the total project scope.
• Listing of all tasks necessary to address each requirement in the SOR.
• Ensures a common understanding between the Project team, and support staff.
• Baseline used to define the responsible areas and cost account breakdowns of the project.

What is it?

pg 125

84

Work Breakdown Structure (WBS)‏

• A WBS is typically broken out into various levels from levels of work packages.
• Although WBS levels are dependent on program complexity, typically 3 levels are adequate for most medium risk projects, while high risk projects can drill down to 6 or 7 levels.
• There are two major categories of levels:
• Managerial - customer has visibility - > 3 level
• Technical - Line Manager visibility - < 3 level

How Does it Work?

85

Simple WBS Structure – Graphic Model

Level 1

Level 3

Level 2

86

WBS – MS Project

WBS

Elements

87

Work Breakdown Structure (WBS)‏

• Product - breaks the work down into system, subsystem and component levels. Best for project under two years in length.
• Organization - work is broken down by functional levels in the organization such as Platform, Division and Department. Useful for repetitive type projects with similar requirements.
• Life-Cycle - Projects whose duration is longer than two years and involves Life-Cycle (O&S) considerations.

Types

88

Examples of Major WBS Types

Level 1

Level 3

Level 2

Product

Organizational

89

EXERCISE 4:

​

​

CONSTRUCTING THE WBS

EXERCISE 5 WBS Roll-up APQP – Program Approval

​

​

• FOCUS – Construct the Level 3 (Roll-up) WBS from a lower level WBS
• Timing – Week 1 after contract award
• Input Documents
• Level 3 WBS Task List – PROJECT Data file
• Test Summary Log – PRODUCT Date file
• Team roles – PM/Lead Eng, PDT members, and Recorder
• Tasks (Be sure each member of the Project team provides input into the risk analysis)
1. Using the data from the WBS task listing identify the man-hours required and complete the cost centers on the Level 3 WBS Rollup in the PROJECT Date file
2. Identify the total man-hours of the Level 2 Organizational for each of the following departments; Engineering, Manufacturing, and Quality (indicated in YELLOW on the WBS Rollup)
3. Obtain a baseline Project Budget by completing YELLOW items on the Project Budget Summary in the PMP file.

91

MODULE 4:

​

• QUALITY MANAGEMENT
• ROBUST DESIGN METHODS (DFSS)
• SPECIAL CHARACTERISTICS SYSTEM
• THE DESIGN REVIEW PROCESS

Quality Management

3 sub-processes

• Plan for Quality
• Manage Quality
• Control Quality

Key Output – Robust Design that can be economically manufactured

Knowledge Area 8

Pg. 227

93

Quality Planning

Quality Planning involves identifying which quality standards are relevant to the project and determining the best approach to achieve the project objectives.

Each industry has a specific QM system that they use for their daily ongoing processes, such as engineering, production, purchasing, HR, etc.

Examples of common QM systems are:

• TQM (Toyota, FORD, and Motorola)
• ISO 9001 (Global standard of TQM principles)
• TS-16949 (Automotive specific)
• CMMI (used mainly by DOD and Software firms)‏

94

Quality Planning

If the determination is made that the organizational QMS cannot manage the risks presented by the customer’s request then PM is necessary.

Quality Planning also involves identifying which New Product Development process (NPD) the project team will use.

In addition to the QM system, a company which is design responsible has an NPD* process for managing projects outside the capability of the company QMS.

For the Mobility industry the base model is the AIAG 5-Phase APQP

95

ROBUST DESIGN

A method which is aimed at:

reducing a product’s sensitivity to external NOISE.

​

​

This “noise” is expressed in engineering terms as variation.

​

96

ROBUST DESIGN CONCEPTS

Sources of uncontrollable variations are:

• Variation in Customer use
• Environmental Changes
• Manufacturing Limitations

​

97

Robust Design Methodology�RDM

• The attitude of Automotive has been to put pressure on suppliers to “get the design right the first time.” This has led the Mobility Industry to embrace the principles of Robust Design Methodology (RDM*), also referred to as Design for Six Sigma (DFSS).
• Unlike DOD where delivery of weapon systems or a logistical support vehicle design can be delayed to ensure that the final design will result in a fully functional and safe system, suppliers to an automotive OEM cannot afford to impact the fixed production schedule of that OEM.
• Initially RDM was used to improve processing quality issues that affected production eventually leading to the development of the Six Sigma program and Lean Manufacturing.
• The great success realized in these production-centered programs was then applied to APQP leading to Design for Six Sigma (DFSS).

* Taguchi's Robust Design methods were introduced to Ford Motor Co. in the early 1980’s

98

ROBUSTNESS METHODS & TECHNIQUES

There are several analytical methods that work together to aid the design team in organizing the mass of VOC data.

This helps the design team differentiate between major and minor concerns and prioritize product improvements.

Some of the more essential techniques are:

​

• QFD
• Affinity Diagram
• Pareto Charting
• Parameter (P) Diagram
• Interface Matrix
• FMEA
• DFM/A
• Design of Experiments (DOE)
• Dimensional Management
• Design Error proofing
• FEA and simulations
• Priority Matrix design selection
• Use of Design Best Practices Handbooks
• Design Reviews

99

DFX as a Robustness Strategy

Notice that each method is only a PORTION of the total DFSS process

100

Parameter (P)-Diagram

101

Now that the boundaries and interfaces are properly understood by the FMEA team, the P-Diagram can be created to identify the INPUTs, noise factors, control factors, required OUTPUTs and error states as associated with the established function(s)*.

Sources for this include:

• Customer or End User Requirements
• Controllable and Uncontrollable inputs
• Design Bill of Material
• Industry Standard (as applicable
• ANSI/NEMA FL 1-2009
• Flashlight Performance Standard 
• Design & Process Lessons Learned
• Applicable Warranty data
• Serviceability plan
• Reliability and warrant targets
• Manufacturing limitations

101

Parameter (P)-Diagram

​

PRODUCT SYSTEM

​

Noise Factors

Input Signals

Controllable Factors

Output Signals or Response

Error States

102

103

According to the book, FMEA with Robustness Linkages by FORD, a system interface matrix is defined as:

“an illustration of the relationships between the subsystems, assemblies, subassemblies, and components within the

object [design] as well as the interfaces with the neighboring systems and environments.

​

A system interface matrix documents details such as types of interfaces, strength/importance of interface, and potential effect of interface.”

​

An Interface Matrix plots four primary relationships or interface on both the vertical and horizontal axes and is used in preparation for a System or Design FMEA.

Interface Matrix

104

Interface Defined

An interface is the point or surface where two components or subsystems meet.

There are 4 primary types of Interfaces:

1. Physical - brackets, bolts, clamps
2. Energy transfer - heat, friction, or motion transfer such as chains or gears
3. Material transfer – fuel, air, hydraulics, other liquids
4. Information exchange – electrical signals analog or digital

Since interfaces can contain up to 50% or more of the total failure modes, it is essential part of a FMEA analysis.

INTERFACE MATRIX

Example of an Systems Interface Matrix

105

The FMEA, is primarily a Risk Assessment method which asks the following questions:

1. What can go wrong?
2. If something does go wrong
• what are the consequences?
• what is the probability of it happening?
3. If something does go wrong can it be detected?
4. Can I quantify the risk?

Failure Mode

Effect and Severity

Occurrence

Design Control

RPN

FMEA

106

• Complete understanding of design functions and requirements
• Maximize the probability that all actual and potential failure modes are identified.
• Understand the upstream Effects of these Failure Modes
• Root Cause Analysis
• Semi-objective prioritization of the risk for each design requirement through S-O-D analysis.
• Help develop design alternatives to optimize Hi-Risk areas of the product and process design.

107

Function/Requirements

​

Failure Modes

Effects

Causes/Mechanisms

RPN/SO/CM

​

​

Recommended Actions

​

Goals of a Design FMEA:

FMEA Field:

FMEA

Types

1. SYSTEM
2. DESIGN
3. PROCESS
4. T&E
5. SOFTWARE

There are various types of FMEAs used in industry today, therefore FMEAs can be divided into categories and types as follows:

Categories

1. FMECA
2. FMEA - Automotive
3. VDA
4. Harmonized VDA/AIAG

Design for Manufacture and Assembly (DFMA)

Defined as the process of :

• Optimizing the design of a product in such a way that permits the easiest and most efficient method of manufacture without comprising functionality.

​

• Optimizing a manufacturing process to permits the quickest, simplest, and safest method of manufacture.

109

DFM and DFA

1. Part count analysis
2. Design for ease of handling
3. Design for ease of fitting
4. Design for ease of setup
5. Assembly costing analysis

1. Material Selection
2. Process Selection
3. Design for ease of processing
4. Geometric Considerations
5. Tolerancing for Process Capability
6. Component costing

DFM Considerations

DFA Considerations

Figure 1-4 Producability Handbook pg 28

110

DFM�Design for Ease of Manufacture

Design improvements for ease of manufacturing can be divided into three (3) major parameters.

1. Handling or feeding of component parts
2. Insertion (fitting) and release of component parts
3. Securing of component parts

111

DFA�Design For Assembly

Improvement of assembly methods can be divided into three (3) major groups.

1. Manual
2. Full automation 
3. Soft automation or robotic assembly

112

Comparing B-D and Lucas Methods

These two methods are the most widely used in industry and are based on a "point scale" which gives a relative measure of assembly difficulty. Although both methods are similar in approach the Lucas method has the prelimianry step of the “quick” analysis of DFM efficiency.

Lucas

1. Functional Analysis
2. Handling Analysis for manual assembly
3. Insertion (Fitting) Analysis
4. Mfg and processing costing tables

Boothroyd-Dewhurst

1. Handling Analysis for manual or automated assembly
2. Insertion (Fitting) Analysis
3. Redesign Analysis

113