Road and Track Vehicle - Project Document

Project DP Zero 1

FIRST PRINCIPLES TECHNOLOGIES

12 BAY DRIVE

CHARLESTON, SOUTH CAROLINA

DATE

8 January 2015

Note:

Many of the details and technical details in this version of the document have been

removed or amended

1

TABLE OF CONTENTS

EXECUTIVE SUMMARY ........................................................................................................................... 2

INTEGRATION MANAGEMENT .................................................................................................................. 3

PROJECT CHARTER ................................................................................................................................ 5

STAKEHOLDER REGISTER....................................................................................................................... 10

STAKEHOLDER MANAGEMENT PLAN........................................................................................................ 11

COMMUNICATION MANAGEMENT PLAN .................................................................................................. 14

STATEMENT OF WORK ......................................................................................................................... 21

SCOPE MANAGEMENT PLAN.................................................................................................................. 24

COST MANAGEMENT PLAN ................................................................................................................... 31

SCHEDULE MANAGEMENT PLAN............................................................................................................. 36

RISK MANAGEMENT PLAN .................................................................................................................... 42

CHANGE MANAGEMENT PLAN ............................................................................................................... 51

HUMAN RESOURCE MANAGEMENT PLAN ................................................................................................. 56

LESSONS LEARNED APPROACH ............................................................................................................... 59

PROCUREMENT MANAGEMENT PLAN ...................................................................................................... 61

EXAMPLE STATUS REPORT .................................................................................................................... 66

PROJECT CLOSE .................................................................................................................................. 69

APPENDIX ......................................................................................................................................... 70

PROJECT TEAM DIRECTORY ................................................................................................................... 70

EARNED VALUE DETAILS....................................................................................................................... 72

GUIDANCE ON CREATING HIGH PERFORMANCE TEAMS ............................................................................... 73

PERFORMANCE IMPROVEMENT ............................................................................................................. 75

REFERENCE ....................................................................................................................................... 78

2

EXECUTIVE SUMMARY

Utilisation of track cars is limited to race circuits as they are not road legal. This creates some annoyance

as it limits their use and requires the use of transporters. Road cars on the other hand are not developed

for track use. Gone are the days of drive your car to the track, race it and drive it back home.

Given these constraints the objective is to produce a car that can be driven from home to the track,

pushed to the limit on the race circuit, and thereafter driven back home. The car must be reliab le,

beautiful and at home on the road and the track, without compromising performance.

This document presents the plan for transforming a Daytona Prototype for use on the road and the

track. The vehicle will serve as a prototype for development and sales purposes.

The Daytona Prototype platform has been selected due to its mix of performance, reliability, cost and

design.

The purpose of this document is to provide every participant in the project, a single point of reference

that identifies the overall framework for the execution of the project.

3

INTEGRATION MANAGEMENT The FPT Program Manager will have primary responsibility for ensuring the project team’s adherence to the expectations set forth in this plan and is responsible for coordinating the project management activities referenced in this plan Integration Management is a discipline that focuses on ensuring that all project components are coordinated effectively in order to achieve the project ’s goals and objectives. Project Integration Management consists of six processes:

Process Key Deliverable Develop Project Charter Project Charter

Develop Project Management Plan Project Management Plan Direct and Manage Project Work Deliverables

Monitor and Control Project Work Change Requests Perform Integrated Change Control Change Requests status updates

Close Project or Phase Final product

Develop Project Charter

The project charter includes information on the project background, business case, goals, authority of the program manager, budget, risk, stakeholders, deliverables and approval criteria. The document is generic enough that it does not change frequently during the course of the project.

The project charter will formally authorise the project and allow the Program Manager to apply organizational resources.

Develop Project Management Plan

The project charter serves as input to the project management plan. The project management plan will provide information on how the project will be executed, monitored and closed.

Included in the project management plan are all the sub plans including scope, change, schedule, cost, process improvement, human resource, communication, risk and procurement sub plans.

These sub plans will provide the necessary detail including the WBS (work breakdown schedule), cost baseline, scope baseline, performance measurement baseline and responsibility for each deliverable.

Once the project management plan is baselined, it will be subject to formal change control and used as a basis for comparison to the actual plan.

4

Direct and Manage Project Work

Direct and manage project work process includes performing the work defined in the project

management plan to achieve project goals. The outputs of this process include project deliverables,

work performance information, change requests and updates to the project management plan.

Monitor and Control Project Work

Monitor and Control project work process includes tracking and reviewing the progress of the project.

The change requests on the project deliverables and project artefacts will be managed in this process.

Perform Integrated Change Control

The Change Control Board (CCB) will be formed to review change requests. After the project scope has been baselined, each requested change must go through the formal change control review process.

Close Project or Phase

The Project shutdown procedure includes processes for accomplishing closure, ensuring the fulfilment of commitments, obtaining lessons learned, formal sign off by designated stakeholders and the completion and archiving of project documentation.

5

PROJECT CHARTER The Problem The inability to open the home garage climb into your car drive it to the nearby race circuit, push it to

the limit and then drive home, is a source of frustration for those who enjoy what the combination of a

track car and race circuit can bring. Current “supercars” which have seemingly morphed into

“hypercars” like the Mclaren P1 and LaFerrari, are road legal monsters. While these engineering marvels

are capable on a race circuit they are not designed for frequent track use. This can be seen with track

only versions of the aforementioned being made available to a lucky few by their respective

manufacturers.

Pictured:

The road car: Ferrari P4/5 by Pininfarina

The track version: Scuderia Cameron Glickenhaus P4/5 Competizione

Scuderia Cameron Glickenhaus is currently building a new road

and track car, SCG 003, which can be converted from road car to

race car and back again. The SCG 003 will be built to customer

order at a price of approximately 2 500 000 Euros.

The Objective The objective of the DP Zero 1 project is to produce a prototype vehicle that will lead to a limited

production version that will provide owners with a high performance track car which is aesthetically

pleasing, reliable and cost effective to run on the race circuit, while being fully capable of comfortable

and frequent road use.

The intent of the prototype that will emerge from the DP Zero 1 project is twofold:

1) Serve as a development test bed 2) Serve as a sales platform

Should the prototype be successful the intention is to:

- produce 6 vehicles a year - build cost approx. 800 000 USD - sales price approx. 1 500 000 USD

6

Project Description First Principles Technologies together with Riley Technologies and Fioravanti will in the DP Zero 1 project

produce a vehicle that will be the harmonization of a track car and road car. The project will utilize the

current Daytona Prototype vehicle specification as the vehicle platform. The platform has proven

performance, cost and reliability measures.

To make the vehicle fit for road use and to meet the objectives of this project, modifications to the

following areas will be made:

- Suspension package - Chassis package - Powertrain package:

o Engine Management o Gearbox o Exhaust system

- Air-conditioning system package - Interior package - Body and light cluster package

Project Timeframe Stage 1:

Within 30 days of project commencement: o Complete design modifications

Within 60 days of project commencement:

o Select brake and suspension suppliers o Complete chassis production


o Complete powertrain installation o Complete exhaust system installation o Complete suspension installation o Complete brake installation

Within 110 days of project commencement

o Complete air-conditioning installation o Complete vehicle system integration o Complete body fitment o Complete vehicle shakedown o Vehicle ready for shipment to Fioravanti

7

Stage 2:

Within 130 days of project commencement: o Complete interior design o Complete light cluster design o Complete interior installation o Complete light cluster installation


o Complete interior testing and refinement o Complete light cluster testing o Complete vehicle painting o Complete second vehicle test o Vehicle ready for shipment to First Principles Technologies

Project Budget The budget for the project is 800 000 USD and is funded by First Principles Technologies.

Stage 1: completed within a budget of 700 000 USD

- Chassis: 355 000 USD - Powertrain: 145 000 USD - Brakes: 70 000 USD - Suspension: 60 000 USD - Body: 70 000 USD

Stage 2: completed within a budget of 100 000 USD

- Interior, body and light cluster: 100 000 USD

Critical Quantitative Success Factors Stage 1: vehicle mass not to exceed 825 kilograms (excluding driver and fuel)

Stage 2: vehicle mass not to exceed 1 075 kilograms (excluding driver and fuel)

Power unit output in track mode 700 metric horsepower

Power unit output in road mode 350 – 400 metric horsepower

Power to mass ratio in track mode (excluding driver and fuel):

≥ 0.65 metric horsepower per kilogram

8

Project Stakeholders First Principle Technologies

12 Bay Drive

Charleston, South Carolina

Riley Technologies

170 Overhill Road

Mooresville, North Carolina, 28117

Fioravanti

USA Office

2810 Jamboree Road

Newport Beach, California

Project Authorization Mr. Kevin Jones from First Principles Technologies is named as Program Manager for the duration of the

DP Zero 1 project. Mr. Jones’s responsibility is to manage all project tasks, scheduling, and

communication regarding the project. Mr. Jones is authorized to approve all budget expenditures up to,

and including, the allocated budget amounts. Any additional funding must be requested through Mr.

Jim Bergmann, head of Contract and Commercial Management at First Principles Technologies. Further

Mr. Jones is authorized to interface with management as required, request resources, delegate

responsibilities within the framework of the project, and to communicate wi th all contractors, as

required, to ensure successful and timely completion of the project.

Project Charter Acceptance

__________________________________________ Date: ___________________

Jim Bergmann

Head: Contract and Commercial Management,

First Principles Technologies

9

10

STAKEHOLDER REGISTER

Project Name: DP Zero 1 STAKEHOLDER REGISTER Date

Name Designation/Title Department Role Contact Internal/External Influence Power

Gregg Barrett CEO Management Project Owner 7 195 559 899 Internal Weekly High High

Kevin Jones Program Manager Management Program Manager 7 195 559 890 Internal Daily High Medium

Jim Bergmann

Head: Contract and

Commercial ManagementManagement Contract and Commercial Management 7 195 559 895

Internal Weekly High Medium

Gordon Murray Technical Head Technical Technical Head 7 195 559 885 Internal Daily High Medium

Bill Riley CEO Management Responsible for Riley Project 704 663 6325 External Weekly High High

Bill FingerlowGeneral Manager Management/Engineering

Oversees Riley Project infrastructure and

resources 704 663 6323 External Weekly Medium Medium

Kenneth Swan Project Manager Management Project Manager 704 663 6320 External Daily Medium Medium

Jim Kasprzak Head: Engineering Engineering chief vehicle engineer 704 663 6315 External Daily Medium Medium

Jon Miles Senior Engineer Engineering electrical 704 663 6314 External Daily Low Low

Tyler Hook Senior Engineer Engineering chassis 704 663 6312 External Daily Low Low

Ray Banda Senior Engineer Engineering suspension 704 663 6311 External Daily Low Low

Charles Long Senior Engineer Engineering powertrain 704 663 6310 External Daily Low Low

Leonardo Fioravanti CEO Management Responsible for Fioravanti Project 949 780 3298 External Weekly High High

Marco Fernelli Chief Designer Design Project Chief Designer 949 780 3284 External Daily Medium High

Louis Augeri Interior Chief Designer Design Interior Chief Designer 949 780 3280 External Daily Medium Medium

Francine Facchini Project Manager Design Project Manager 949 780 3276 External Daily Medium Medium

Jamie Allison Ford Racing Director Management Responsible for Power unit 313 845 8648 External Weekly High High

Paul Barton

Commercial & Engineering

ManagerManagement Responsible for Gearbox

7 047 994 489 External Weekly Medium Medium

Tom Franks Head of NVH Management Responsible for Exhaust 4 084 965 344 External Weekly Medium Medium

Type/Frequency of

Communication

11

STAKEHOLDER MANAGEMENT PLAN

The Stakeholder Management Plan for the DP Zero 1 project will be used to identify and classify project

stakeholders; determine stakeholder power, interest, and influence; and analyze the management

approach and communication methodology for project stakeholders. This will allow the identification of

key influential stakeholders to solicit input for project planning and gain support as the project

progresses. This will benefit the project by minimizing the likelihood of encountering competing

objectives and maximizing the resources required to complete the project.

Early identification and communication with stakeholders is imperative to ensure the success of the

project, as some stakeholders may have interests which may be positively or negatively affected. More

effective management and balance these interests can be attained by initiating early and frequent

communication and stakeholder management.

Identify Stakeholders The following criteria will be used to determine if an individual will be included as a stakeholder:

- Will the person or their organization be directly affected by this project? - Does the person or their organization hold a position from which they can influence the project? - Does the person have an impact on the project’s resources (material, personnel, funding)? - Does the person or their organization have any special skills or capabilities the project will

require? - Does the person potentially benefit from the project or are they in a position to resist this

change? Any individual who meets the first and thereafter one or more of the above criteria will be identified as

a stakeholder. Stakeholders from the same organization will be grouped in order to simplify

communication and stakeholder management.

Key Stakeholders The project team will identify key stakeholders who have the most influence on the project or who may

be impacted the most by it. These key stakeholders are those who also require the most

communication and management which will be determined as stakeholders are analyzed. Once

identified, the Program Manager will develop a plan to obtain their feedback on the level of

participation they desire, frequency and type of communication, and any concerns or conflicting

interests they have.

Based on the feedback gathered by the program manager, the determination may be made to involve

key stakeholders on steering committees, focus groups, gate reviews, or other project meetings or

milestones. Thorough communication with key stakeholders is necessary to ensure all concerns are

identified and addressed and that resources for the project remain available.

12

Stakeholder Analysis Once all the project stakeholders have been identified, the project team will categorize and analyze each

stakeholder. The purpose of this analysis is to determine the stakeholders’ level of power and influence,

plan the management approach for each stakeholder, and to determine the appropriate levels of

communication and participation each stakeholder will have on the project.

The project team will categorize stakeholders based on their organization or department. Once all

stakeholders have been categorized, the project team will utilize a power/interest matrix to illustrate

the potential impact each stakeholder may have on the project. Based on this analysis the project team

will also complete a stakeholder analysis matrix which illustrates the concerns, level of involvement, and

management strategy for each stakeholder.

The chart below will be used to establish stakeholders and their levels of power and interest for use on

the power/interest chart as part of the stakeholder analysis.

Project Name: DP Zero 1

Name Designation/Title Department Interest (1 - 5) Power (1 - 5)

a Gregg Barrett CEO Management 5 5

b Kevin Jones Program Manager Management 3 3

c Jim Bergmann

Head: Contract and

Commercial ManagementManagement

4 4

d Gordon Murray Technical Head Technical 4 4

e Bill Riley CEO Management 4 5

f Bill Fingerlow General Manager Management/Engineering 4 4

g Kenneth Swan Project Manager Management 3 3

h Jim Kasprzak Head: Engineering Engineering 4 4

i Jon Miles Senior Engineer Engineering 2 2

j Tyler Hook Senior Engineer Engineering 3 2

k Ray Banda Senior Engineer Engineering 4 2

l Charles Long Senior Engineer Engineering 2 2

m Leonardo Fioravanti CEO Management 4 5

n Marco Fernelli Chief Designer Design 4 4

o Louis Augeri Interior Chief Designer Design 3 3

p Francine Facchini Project Manager Design 3 3

q Jamie Allison Ford Racing Director Management 4 5

r Paul Barton

Commercial & Engineering

ManagerManagement

4 3

s Tom Franks Head of NVH Management 3 3

13

Below is the power/interest chart for the DP Zero 1 project stakeholders. Each letter represents a stakeholder in accordance with the key in the chart above.

Based on the power and interest analysis and chart above, stakeholders lower left quadrant will require

minimal management effort.

Stakeholder in the upper left quadrant, must be kept satisfied by ensuring concerns and questions are

addressed adequately.

Stakeholders, in the lower right quadrant, must be kept informed through frequent communication on

project status and progress.

Stakeholders, in the upper right quadrant, are key players and must be involved in all levels of project

planning and change management. Additionally, these stakeholders should be participatory members in

all project status meetings, gate reviews, and ad hoc meetings as required.

The stakeholder analysis matrix will be used to capture stakeholder concerns, level of involvement, and

management strategy based on the stakeholder analysis and power/interest matrix above. The

stakeholder analysis matrix will be reviewed and updated throughout the project’s duration in order to

capture any new concerns or stakeholder management strategy efforts.

14


Name Designation/Title Concerns Quadrant Strategy

a Gregg Barrett CEO Cost and reliability Key player Communicate frequent

updates

b Kevin Jones Program Manager Resource and scheduling Keep informed/keep

satisfied

Communicate resource

requirements early

c Jim Bergmann Head: Contract and Commercial

Management

Intellectual property and

management of

contractors

Key player Communicate frequent

updates

d Gordon Murray Technical Head Reliability and

performance

Key player Communicate project

specifications as

required

e Bill Riley CEO Scheduling and cost Key player Communicate project

specifications as

required

f Bill Fingerlow General Manager Resource scheduling and

cost

Key player Communicate resource

requirements early

g Kenneth Swan Project Manager Resource and scheduling Keep informed/keep

satisfied


requirements early

h Jim Kasprzak Head: Engineering Integration of new

components systems

Key player Solicit frequent

updates

i Jon Miles Senior Engineer Integration of systems Keep informed Solicit frequent

updates

j Tyler Hook Senior Engineer Scheduling of chassis

redesign

Keep informed Solicit frequent

updates

k Ray Banda Senior Engineer Performance and

reliability: suspension

mass and adjustable ride

height

Keep informed Communicate project

specifications as

required

l Charles Long Senior Engineer Performance: engine

cooling and mass

Keep informed Solicit frequent

updates

m Leonardo Fioravanti CEO Quality Key player Communicate frequent

updates

n Marco Fernelli Chief Designer Scheduling Key player Communicate resource

requirements early

o Louis Augeri Interior Chief Designer Quality and mass Keep informed/keep

satisfied

Solicit frequent

updates

p Francine Facchini Project Manager Resource and scheduling Keep informed/keep

satisfied


requirements early

q Jamie Allison Ford Racing Director Reliability Key player Communicate project

schedule and material

requirements ahead of

time to ensure delivery

r Paul Barton Commercial & Engineering

Manager

Cost of mass and

reliability requirements

Keep informed Communicate project

schedule and material

requirements ahead of

time to ensure delivery

s Tom Franks Head of NVH Cost and development

time frame

Keep informed/keep

satisfied

Communicate project

specifications as

required and solicit

frequent updates

15

COMMUNICATION MANAGEMENT PLAN This Communications Management Plan sets the communications framework for this project. It will

serve as a guide for communications throughout the life of the project and will be updated as

communication needs change. This plan identifies and defines the roles of persons involved in this

project. It also includes a communications matrix which maps the communication requirements of this

project. A project team directory is included in the appendix to provide contact information for all

stakeholders directly involved in the project.

Communications Management Approach The Program Manager will take a proactive role in ensuring effective communications on this project.

The communications requirements are documented in the Communications Matrix presented in this

document. The Communications Matrix will be used as the guide for what information to communicate,

who is to do the communicating, when to communicate it and to whom to communicate.

As with most project plans, updates or changes may be required as the project progresses or changes

are approved. Changes or updates may be required due to changes in personnel, scope, budget, or

other reasons. Additionally, updates may be required as the project matures and additional

requirements are needed. The Program Manager is responsible for managing all proposed and

approved changes to the communications management plan. Once the change is approved, the

Program Manager will update the plan and supporting documentation and will distribute the updates to

the project team and all stakeholders. This methodology is consistent with the project’s Change

Management Plan and ensures that all project stakeholders remain aware and informed of any changes

to communications management.

Project Documentation All project stakeholders will be provided with secure access to First Principles Technologies SharePoint

Server and will be issued a unique username and password following the project kick -off meeting. The

Program Manager is responsible for ensuring all project documentation is listed on SharePoint.

Stakeholder Overview Please see the Project Team Directory in the Appendix for contact details.

First Principle Technologies 12 Bay Drive Charleston, South Carolina

Project team: - Project Owner: Gregg Barrett, CEO - Program Manager: Kevin Jones - Contract and Commercial Management:

Jim Bergmann - Technical Head: Gordon Murray

16

Riley Technologies 170 Overhill Road Mooresville, North Carolina, 28117

Project Team: - CEO: Bill Riley - General Manager: Bill Fingerlow - Project Manager: Kenneth Swan - Engineering, chief vehicle engineer: Jim

Kasprzak - Engineering, electrical: Jon Miles - Engineering, chassis: Tyler Hook - Engineering, suspension: Ray Banda - Engineering, powertrain: Charles Long

Fioravanti USA Office 2810 Jamboree Road Newport Beach, California

Project Team: - CEO: Leonardo Fioravanti - Project Chief Designer: Marco Fernelli - Interior Chief Designer: Louis Augeri - Project Manager: Francine Facchini

Strategic Supply Partners:

Ford Motor Company 1 American Road Dearborn, MI 48126

Person: Ford Racing Director: Jamie Allison

Xtrac Mooresville 301 Cayuga Drive, Suite A Mooresville NC 28117

Person: Commercial & Engineering Manager: Paul

Barton

Ricardo Inc. Santa Clara Technical Campus 3540 Bassett Street Santa Clara, CA 95054

Person: Head of NVH: Tom Franks

Brake Supplier: To be determined

Person: To be determined

Suspension Supplier: To be determined Person:

To be determined

17

Communication Flowchart

18

Communications Matrix

Communication Type

Objective of Communication Medium Frequency Audience Responsible Output Format

Kickoff Meeting Introduce the project team

and the project. Review project objectives and management approach.

Face to Face

Conference Call

Once All stakeholders FPT: Program

Manager

Agenda

Meeting Minutes

Email and soft

copy archived on

project SharePoint site

Project Team Meetings

Review status of the project with the project stakeholders .

Face to Face

Conference Call

Weekly FPT Project Team

Riley Project

Team Fioravanti Project

Team

FPT: Program Manager

Agenda

Meeting Minutes

Project schedule

Email and soft

copy archived on project SharePoint site

Technical Design

Meetings

Discuss and develop technical

design solutions for the project.

Face to Face

Conference Call

As needed FPT Project Team

Riley Project

Team

Fioravanti Project

Team

FPT: Program

Manager

Agenda

Meeting Minutes

Email and soft

copy archived on

project SharePoint site

Escalation Reports (send to FPT Program

Manager)

Bring critical information impacting the project to the attention of the project team

Send to FPT

Program Manager via email

As needed FPT Program

Manager

FPT Project Team

FPT Program

Manager to call meeting or conference call

Project plan

Email and soft

copy archived on project SharePoint site

Accepted change requests

Provide information on approved change requests

Email As needed FPT Project Team

Riley Project

Team Fioravanti Project

Team

FPT: Program Manager

Project schedule Email and soft

copy archived on project

SharePoint site

19

Communication Escalation Process Email to be sent to the FPT Program Manager with the priority code (Priority 1, Priority 2 etc.) in the

email subject line. The FPT Program Manager will then notify the relevant decision makers for action.

Priority

Definition Decision Authority Timeframe for Resolution

Priority 1 Major impact to project or business operations. If not resolved quickly there will be a significant adverse impact to cost, schedule, scope,

quality

Gregg Barrett

Within 5 hours

Priority 2 Medium impact to project or business operations which may

result in some adverse impact to cost, schedule, scope, quality

Jim Bergmann Gordon Murray

Within one business day

Priority 3 Slight impact which may cause some minor scheduling difficulties with the project but no impact to

cost, scope, quality

FPT Program Manager

Within two business days

Meeting Locations The kickoff meeting: will be held at the Riley office.

The Riley office address is: 170 Overhill Road, Mooresville, North Carolina

Meetings in stage 1: will be held at the Riley office with other participants joining via conference call.

The conference call number is: 704 663 6323

Meetings in stage 2: will be held at the Fioravanti office with other participants joining via conference

call.

The Fioravanti office address is: 2810 Jamboree Road, Newport Beach, California

The conference call number is: 949 780 3284

20

Communication Plan Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



21

STATEMENT OF WORK

Specific deliverables are listed under the “Work Requirements” and “Schedule” sections of this SOW.

The scope of work for the DP Zero 1 project includes all planning, design, manufacturing, installation and

testing of stage 1 and stage 2.

Where stage 1 consists of: - Suspension package - Brake package - Chassis package - Powertrain package:

o Power Unit o Engine Management o Gearbox o Exhaust system

- Air-conditioning system package - Primary body package

Where stage 2 consists of:

- Interior package - Final Body and light cluster package

Not included in the scope of work for this project are:

- marketing activities - sales activities - ongoing research and development

Period of Performance The period of performance for the DP Zero 1 project is 210 days beginning on May 4th, 2015. Any modifications or extensions will be requested through the change request process.

Place of Performance Stage 1 of the vehicle build will take place at Riley Technologies located at 170 Overhill Road,

Mooresville, North Carolina.

Ford Motor Company will deliver the power unit to Riley Technologies and will provide a technician to

oversee the power unit installation at Riley Technologies.

Xtrac will deliver the gearbox to Riley Technologies and will provide a technician to oversee the gearbox

installation at Riley Technologies.

Ricardo will deliver the exhaust system to Riley Technologies and will provide a technician to oversee

the exhaust system installation at Riley Technologies.

22

The selected suspension supplier will deliver the suspension package to Riley Technologies and will

provide a technician to oversee the suspension installation at Riley Technologies.

The selected brake supplier will deliver the brake package to Riley Technologies and will provide a

technician to oversee the brake installation at Riley Technologies.

Stage 2 of the vehicle build will take place at Fioravanti, located at 2810 Jamboree Road, Newport

Beach, California

Work Requirements Stage 1:

- Design modifications to current Daytona Prototype chassis - Design modifications to vehicle nose, side skirts and rear diffuser - Design of vehicle rims - Design of vehicle exhaust system - Virtual vehicle (CAD) component and system integration (excluding damper and spring

components and brake package) - Technical submission for suspension package and brake package - Selection of suspension package and brake package - Construction of vehicle chassis - Construction of vehicle body - Installation of power unit - Installation of gearbox - Installation of exhaust system - Installation of suspension package - Installation of brake package - Installation of air-conditioning system package - Installation and integration of vehicle systems - Fitment of primary vehicle body - First vehicle test

Stage 2:

- Interior design finalization

- Light cluster design finalization

- Interior installation - Light installation - Interior testing - Light cluster testing - Second vehicle test

23

Schedule/Milestones

Summary Schedule

Project Milestone Target Date (dd/mm/yyyy)

Project Start 04/05/2015

Stage 1:

Virtual vehicle (CAD) component and system integration (excluding damper and spring components and brake package)

08/06/2015

Selection of suspension package and brake package 17/07/2015

Completion of vehicle chassis 27/07/2015

Installation and integration of vehicle systems 14/09/2015

First vehicle test 17/09/2015

Stage 2

Interior testing and light cluster testing 06/11/2015

Second vehicle test 13/11/2015

Project Complete

Acceptance Criteria The acceptance of all deliverables will reside with Gordon Murray, FPT Technical Head and Jim

Bergmann, FPT Head of Contract and Commercial Management. Mr. Murray and Mr. Bergmann are both

required to sign-off on a deliverable. Deliverables will be assessed in accordance with the agreed

contract specification.

Statement of Work Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann

24



SCOPE MANAGEMENT PLAN For this project, scope management will be the sole responsibility of the FPT Program Manager, Kevin

Jones. The scope for this project is defined by the Scope Statement and Work Breakdown Structure

(WBS).

Gordon Murray, FPT Technical Head and Jim Bergmann, FPT Head of Contract and Commercial

Management together with the project stakeholders will establish and approve documentation for

measuring project scope which includes deliverable quality checklists and work performance

measurements.

Proposed scope changes may be initiated by any project stakeholders. Change requests will be

submitted to the FPT Program Manager who will then submit the scope change request to the Change

Control Board for review. Upon approval of scope changes by the Change Control Board the FPT

Program Manager will update all project documents and communicate the scope change to all

stakeholders via email with the updated documentation placed on the SharePoint site.

Members of the Change Control Board:

- Gregg Barrett

- Jim Bergmann

- Gordon Murray

Priority Matrix

Time Performance Cost Constrain

Enhance ■ Accept ■ ■

25

Roles and Responsibilities The table below defines the roles and responsibilities for the scope management of this project.

Name Role Responsibilities


Gregg Barrett FPT Project Team:

Project Owner

- Change Control Board - Communication Escalation Process: Decision

maker on Priority 1 matters - Supplier selection

Kevin Jones FPT Project Team:

Program Manager

- manage all project tasks, scheduling, and communication regarding the project

- Facilitate scope change requests - Organize and facilitate scheduled change

control board meetings - Communicate outcomes of scope change

requests - Update project documents upon approval of all

scope changes - Communication Escalation Process: Decision

maker on Priority 3 matters

Jim Bergmann FPT Project Team:

Contract and

Commercial

Management

- Deliverable acceptance - Change Control Board - Communication Escalation Process: Decision


Gordon Murray FPT Project Team:

Technical Head

- Deliverable acceptance - Change Control Board - Communication Escalation Process: Decision


26

Riley Technologies

Bill Riley Riley Project Team:

CEO

- Riley Management, responsible for Riley Project deliverables

Bill Fingerlow Riley Project Team:

General Manager

- Riley Management, oversees Riley Project deliverables

Kenneth Swan Riley Project Team:

Project Manager

- manage all Riley project tasks, scheduling, and communication regarding the project

Jim Kasprzak Riley Project Team:

chief vehicle

engineer

- Integration of all stage 1 vehicle components and systems

Jon Miles Riley Project Team:

Engineering,

electrical

- Area of responsibility: All stage 1 vehicle electrical components and systems

Tyler Hook Riley Project Team:

Engineering, chassis

- Area of responsibility: Vehicle chassis

Ray Banda Riley Project Team:

Engineering,

suspension

- Area of responsibility: Vehicle suspension

Charles Long Riley Project Team:

Engineering,

powertrain

- Area of responsibility: Powertrain

27

Fioravanti

Leonardo

Fioravanti

Fioravanti Project

Team: CEO

Fioravanti Project

Team:

- Fioravanti Management, responsible for Fioravanti Project deliverables

Francine Facchini Fioravanti Project

Team: Project

Manager

- manage all Fioravanti project tasks, scheduling, and communication regarding the project

Marco Fernelli Fioravanti Project

Team: Project Chief

Designer

- Integration of all stage 2 design components

Louis Augeri Fioravanti Project

Team: Interior Chief

Designer

- Area of responsibility: Interior

Daniel Guigiaro Fioravanti Project

Team: Exterior Chief

Designer

- Area of responsibility: Exterior

Ford Motor Company

Jamie Allison Ford Racing:

Director

- Area of responsibility: Power unit

Xtrac

Paul Barton

Xtrac: Commercial

and Engineering

Manager

- Area of responsibility: Gearbox

28

Ricardo

Tom Franks Ricardo: Head of

NVH

- manage all Ricardo project tasks, scheduling, and communication regarding the project

Brake Supplier

TBD Supplier Brake

Package: TBD

- Area of responsibility: Brake package

Suspension Supplier

TBD Supplier Suspension

Package: TBD

- Area of responsibility: Suspension package

29

Work Breakdown Structure

30

Scope Management Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



31

COST MANAGEMENT PLAN The Program Manager, Kevin Jones, will be responsible for managing and reporting on the project’s cost

throughout the duration of the project. Prior to the weekly project team meeting, the Program

Manager will meet with FPT management to present and review the project’s cost performance for the

preceding week. Performance will be measured using earned value. The Program Manager is

responsible for accounting for cost deviations and presenting the Project Owner with options for getting

the project back on budget. The Project Owner has the authority to make changes to the project to

bring it back within budget.

Cost Management Approach Costs for this project will be managed at the third level of the Work Breakdown Structure (WBS).

Control Accounts (CA) will be created at this level to track costs. Earned Value calculations for the CA’s

will measure and manage the financial performance of the project. Credit for work will be assigned at

the work package level. Work started on work packages will grant that work package with 50% credit;

whereas, the remaining 50% is credited upon completion of all work defined in that work package.

Costs may be rounded to the nearest dollar.

Cost variances of ≥10% in the cost and schedule performance will change the status of the cost to

cautionary; as such, those values will be changed to amber in the project status reports. Cost variances

of ≥20% in the cost and schedule performance will change the status of the cost to an alert stage; as

such, those values will be changed to red in the project status reports. Cost variances of >20% in the

cost and schedule performance will require corrective action. Corrective actions will require a project

change request and be must approved by the Project Owner before it can become within the scope of

the project.

Measuring Project Costs Project performance will be measured using Earned Value Management. The following two Earned

Value metrics will be used to measure the project’s cost performance:

- Schedule Variance (SV) o ≥0.10 Amber o ≥0.20 Red

- Cost Variance (CV) o ≥0.10 Amber o ≥0.20 Red

Schedule Variance (SV) is a measurement of the schedule performance for a project. It’s calculated by

taking the Earned Value (EV) and subtracting the Planned Value (PV).

32

Calculation for the alert level:

1 – (EV/PV)

If ≤ 0 no action

If ≥ 0.10 amber

If ≥ 0.20 red

Cost Variance (CV) is a measurement of the budget performance for a project. CV is calculated by

subtracting Actual Costs (AC) from Earned Value (EV).

Calculation for alert level:

1 - (EV/AC)

If ≤ 0 no action

If ≥ 0.10 amber

If ≥ 0.20 red

Reporting Format Reporting for cost management will be included in the weekly project status report. The weekly project

status report will include a section labelled, “Cost Management”. This section will contain the Earned

Value Metrics identified in the previous section. All cost variances outside of the thresholds identified in

this Cost Management Plan will be reported on including any corrective actions which are planned.

Change Requests which are triggered based upon project cost overruns will be identified and tracked in

this report.

Cost Variance Response Process The Control Thresholds for this project are the alert levels described in the section “Measuring project

costs”. If the project reaches one of these Control Thresholds a Cost Variance Corrective Action Plan is

required.

The Program Manager will present the Project Owner with options for corrective actions within five

business days from when the cost variance is first reported.

Within two business days from when the Project Owner selects a corrective action option, the Program

Manager will present the Project Owner with a formal Cost Variance Corrective Action Plan.

33

The Cost Variance Corrective Action Plan will detail the actions necessary to bring the project back

within budget and the means by which the effectiveness of the actions in the plan will be measured.

Upon acceptance of the Cost Variance Corrective Action Plan it will become a part of the project plan

and the project will be updated to reflect the corrective actions.

Cost Change Control Process The cost change control process will follow the established project change request process. Approvals

for project budget/cost changes must be approved by the Project Owner.

Project Budget The budget for this project is detailed below. Costs for this project are presented in various categories:

Labour Costs $225 300

Material Costs $570 750

Total Project Cost $796 050

Management Reserve $50 000

34

WBS

IDTask Description

Estimating

Approach

Number of

resources

Estimated

Duration

(hrs)

Estimated

Interruptions

(hrs)

Labor Rate

$/hrLabor Cost Material Costs Total Cost

1.0 Chassis $ 280 600 $ 334 000

1.1 Design Modification Historical 2 54 $150 16 200$

1,2 CAD Integration Historical 3 3.0 $100 900$

1.3 Construction Historical 4 180.0 $50 36 000$

1.4 Test Historical 4 1.5 $50 300$

2.0 Brakes 52 150$ 70 000$

2.1 Technical Submission Historical 3 9.0 $150 4 050$

2.2 Supplier Selection Historical 3 15.0 $150 6 750$

2.3 Installation Historical 2 18.0 $100 3 600$

2.4 Integration Historical 3 7.0 $150 3 150$


3.0 Suspension 52 150$ 70 000$

3.1 Technical Submission Historical 3 9.0 $150 4 050$

3.2 Supplier Selection Historical 3 15.0 $150 6 750$




4.0 Gearbox 33 850$ 40 000$

4.1 CAD Integration Historical 3 3.0 $100 900$




5.0 Power Unit 63 250$ 70 000$





6.0 Body 30 700$ 73 000$

6.1 Design Modification Historical 2 70.0 $150 21 000$


6.3 Construction Historical 3 90.0 $50 13 500$

6.4 Fitment Historical 2 12.0 $50 1 200$

6.5 Paint Historical 3 18.0 $100 5 400$


7.0 Interior 40 000$ 92 500$

7.1 Design Historical 2 108.0 $150 32 400$


7.3 Test Historical 2 12.0 $50 1 200$

8.0 Air-conditioning 6 000$ 11 550$





9.0 Exhaust 12 050$ 35 000$

9.1 Design Historical 2 60.0 $150 18 000$


9.3 Installation Historical 2 6.0 $50 600$



Project Total 796 050$

Cost Estimates

35

Cost Management Plan Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



36

SCHEDULE MANAGEMENT PLAN The project schedule is the roadmap for how the project will be executed. The purpose of the schedule

management plan is to define the approach the project team will use in creating the project schedule.

This plan also includes how the team will monitor the project schedule and manage changes after the

baseline schedule has been approved. This includes identifying, analyzing, documenting, prioritizing,

approving or rejecting, and publishing all schedule-related changes.

Schedule Management Approach Project schedules will be created using the deliverables identified in the project’s Work Breakdown

Structure (WBS). Activity definition will identify the specific work packages which must be performed to

complete each deliverable. Activity sequencing will be used to determine the order of work packages

and assign relationships between project activities. Activity duration estimating will be used to calculate

the number of work periods required to complete work packages. Resource estimating will be used to

assign resources to work packages in order to complete schedule development.

Once a preliminary schedule has been developed, it will be reviewed by the project team and any

resources tentatively assigned to project tasks. The project team and resources must agree to the

proposed work package assignments, durations, and schedule. Once this is achieved the Project Owner

will review and approve the schedule and it will then be baselined.

The following will be designates as milestones for the project schedul e:

- Completion of (CAD) component and system integration (excluding damper and spring components and brake package)

- Selection of suspension package and brake package - Completion of vehicle chassis - Installation and integration of vehicle systems - First vehicle test - Interior testing and light cluster testing - Second vehicle test

Roles and responsibilities for schedule development are as follows:

The Program Manager will be responsible for facilitating work package definition, sequencing, and

estimating duration and resources with the project team. The Program Manager will validate the

schedule with the project team, stakeholders, and the Project Owner. The Program Manager will obtain

schedule approval from the Project Owner and baseline the schedule.

The project team is responsible for participating in work package definition, sequencing, and duration

and resource estimating. The project team will also review and validate the proposed schedule and

perform assigned activities once the schedule is approved.

37

The Project Owner will participate in reviews of the proposed schedule and approve the final s chedule

before it is baselined.

The project stakeholders will participate in reviews of the proposed schedule and assist in its validation.

Schedule Control The project schedule will be reviewed and updated as necessary on a weekly basis with actual start,

actual finish, and completion percentages which will be provided by task owners.

The Program Manager is responsible for holding weekly schedule updates/reviews; determining impacts

of schedule variances; submitting schedule change requests; and reporting schedule status in

accordance with the project’s communications plan.

The project team is responsible for participating in weekly schedule updates/reviews; communicating

any changes to actual start/finish dates to the Program Manager; and participating in schedule variance

resolution activities as needed.

The Project Owner will maintain awareness of the project schedule status and review/approve any

schedule change requests submitted by the Program Manager.

Schedule Changes and Thresholds If any member of the project team determines that a change to the schedule is necessary, the Program

Manager and team will meet to review and evaluate the change. The Program Manager and project

team must determine which tasks will be impacted, variance as a result of the potential change, and any

alternatives or variance resolution activities they may employ to see how they would affect the scope,

schedule, and resources. If, after this evaluation is complete, the Program Manager determines that any

change will exceed the established boundary conditions, then a schedule change request must be

submitted.

Submittal of a schedule change request to the Project Owner for approval is required if either of the two

following conditions is true:

- The proposed change is estimated to increase the duration of an individual work package by 10% or more.

- The change is estimated to increase the duration of the overall baseline schedul e by 10% or more.

Any change requests that do not meet these thresholds may be submitted to the Program Manager for

approval.

Once the change request has been reviewed and approved the Program Manager is responsible for

adjusting the schedule and communicating all changes and impacts to the project team, Project Owner,

38

and stakeholders. The Program Manager must also ensure that all change requests are archived in the

project records repository.

Scope Change Any changes in the project scope, which have been approved by the Project Owner, will require the

project team to evaluate the effect of the scope change on the current schedule. If the Program

Manager determines that the scope change will significantly affect the current project schedule, he may

request that the schedule be re-baselined in consideration of any changes which need to be made as

part of the new project scope. The Project Owner must review and approve this request before the

schedule can be re-baselined.

39

Network Information

Network Information

Activity Description Preceding Activity Activity Duration

A 6.1 Body - Design Modification - 12

B 1.1 Chassis - Design Modification - 9

C

1.2 Chassis - CAD Integration 4.1 Gearbox - CAD Integration

5.1 Power unit - CAD Integration 6.2 Body - CAD Integration

8.1 Air-conditioning - CAD Integration 9.2 Exhaust - CAD Integration

A B

5

D 2.1 Brakes - Technical Submission C 2

E 9.1 Exhaust - Design C 10

F 1.3 Chassis - Construction C 30

G 3.1 Suspension - Technical Submission C 2

H 6.3 Body - Construction C 15

I 7.1 Interior - Design C 18

J 2.2 Brakes - Supplier Selection D 3

K 3.2 Suspension - Supplier Selection G 3

L 5.2 Power unit - Installation F 4

M 4.2 Gearbox - Installation L 3

N 9.3 Exhaust - Installation E M

1

O 3.3 Suspension - Installation K N

3

P 2.3 Brakes - Installation J O

3

Q 8.2 Air-conditioning - Installation P 2

R 6.4 Body - Fitment H Q

2

S

2.4 Brakes - Integration 3.4 Suspension - Integration

4.3 Gearbox - Integration 5.3 Power unit - Integration

8.3 Air-conditioning - Integration 9.4 Exhaust - Integration

R 2

40

T

1.4 Chassis - Test 2.5 Brakes - Test

3.5 Suspension - Test 4.4 Gearbox - Test

5.4 Power unit - Test 6.6 Body - Test

8.4 Air-conditioning - Test 9.5 Exhaust - Test

S 1

U 7.2 Interior - Installation I T

7

V 7.3 Interior - Test U 2

W 6.5 Body - Paint V 3

X

1.4.2 Chassis - Test 2.5.2 Brakes - Test

3.5.2 Suspension - Test 4.4.2 Gearbox - Test

5.4.2 Power unit - Test 6.6.2 Body - Test

8.4.2 Air-conditioning - Test 9.5.2 Exhaust - Test 7.3.2 Interior - Test

W 1

41

Activity-on-Node Network Diagram

AON.xlsx

Schedule Management Plan Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



42

RISK MANAGEMENT PLAN The purpose of the risk management plan is to establish the framework in which the project team will

identify risks and develop strategies to mitigate or avoid those risks. However, before risks can be

identified and managed, there are preliminary project elements which must be completed. These

elements are outlined in the risk management approach.

Before risk management begins it is imperative that a foundation is established for providing structured

project information, thus, the following project elements were completed and defined prior to

developing this Risk Management Plan:

- Define work scope, schedule, resources, and cost e lements o Develop project WBS o Develop project schedule o Estimate project cost o Identify required resources o Establish performance measurement metrics

- Define minimum and maximum baseline thresholds

o Schedule o Cost

- Define Risk Management Roles and Responsibilities

o Program Manager chairs the risk assessment meetings o Project team participates in risk assessment meetings and members serve as meeting

recorder and timekeeper o Key stakeholders participate in risk assessment meetings

Risk Management Approach The approach taken to manage risk for this project includes a methodical process by which the project

team identifies, scores, and ranks the various risks. The most likely and the highest impact risks are

added to the project schedule to ensure that the assigned stakeholders take the necessary steps to

implement the mitigation response at the appropriate time during the schedule.

The assigned stakeholders will provide status updates on their assigned risks in the weekly project team

meetings, but only when the meetings include their risk’s planned timeframe. Upon the completion of

the project, during the closing process, the Program Manager will analyse each risk as well as the risk

management process. Based on this analysis, the Program Manager will identify any improvements that

can be made to the risk management process for future projects. These improvements will be captured

as part of the lessons learned knowledge base.

43

Risk Identification Risk Assessment Meeting

A risk assessment meeting was held with key team members and stakeholders. The risks identified

during this meeting were added to the project plan and Risk Assessment Matrix.

Historical Review of Similar Projects

The project team reviewed the history of similar projects in order to determine the most common risks

and the strategies used to mitigate those risks.

Risk Qualification and Prioritization In order to determine the severity of the risks identified by the team, a probability and impact factor

was assigned to each risk. This process allowed the Program Manager to prioritize risks based upon the

effect they may have on the project.

Risk Monitoring The most likely and greatest impact risks have been added to the project plan to ensure that they are

monitored during the time the project is exposed to each risk. At the appropriate time in the project

schedule a project stakeholder is assigned to each risk. During the weekly project team meeting the

assigned stakeholder for each risk will discuss the status of that risk; however, only risks which fall in the

current time period will be discussed. Risk monitoring will be a continuous process throughout the life

of this project. As risks approach on the project schedule the Program Manager will ensure that the

appropriate stakeholder provides the necessary status updates which include the risk status,

identification of trigger conditions, and the documentation of the results of the risk response.

Risk Mitigation and Avoidance The Program Manager has led the project team in developing responses to each identified risk. As more

risks are identified, they will be qualified and the team will develop avoidance and mitigation strategies.

These risks will also be added to the Risk Assessment Matrix and the project plan to ensure they are

monitored at the appropriate times and are responded to accordingly.

The risks for this project will be managed and controlled within the constraints of time, scope, and cost.

All identified risks will be evaluated in order to determine how they affect this triple constraint. The

Program Manager, with the assistance of the project team, will determine the best way to respond to

each risk to ensure compliance with these constraints.

44

In extreme cases it may be necessary to allow flexibility to one of the project’s constraints. Schedule

and cost for this project allows for flexibility as a last resort. If necessary, funding may be added to the

project in order to meet the scope constraint. Scope is a firm constraint that allows for no flexibility.

The schedule and cost constraints are flexible only in extreme cases where no other risk avoidance or

mitigation strategy will work.

Risk Assessment Matrix The Risk Assessment Matrix for this project is a log of all identified risks, their probability and impact to

the project. The Risk Assessment Matrix was created through the initial project risk management

meeting led by the Program Manager. During this meeting, the project team identified and categorized

each risk. Additionally, the team assigned each risk a score based on the probability of it occurring and

the impact it could potentially have.

Risk Event Event

Code

Likelihood

Impact

(1 – low, 5 – high)

Detection Difficulty (1 – low, 5 – high)

When

Technical

Error in Requirements Specification

T-A .05 3 4 Integration

Failure to meet Quantitative Performance

Requirements

T-B .05 4 2 Integration and

Testing

Failure to meet Reliability

Requirements T-C .15 4 4 Testing

Failure in Component Integration

T-D .10 3 3 Integration and

Testing External

Contractual E-E .05 4 4 Throughout Supply E-F .10 3 3 Installation

Weather E-G .05 3 3 Throughout Organizational

Project dependencies O-H .05 1 1 Throughout

Resources O-I .05 3 3 Throughout Funding O-J .05 4 2 Throughout

Project Management Error in Estimation PM-K .15 3 3 Throughout

Communication Failure

PM-L .05 3 2 Throughout

45

Risk Identification Table for Impact Scales

Relative Scale

Project Objective

1 Very low 2 Low 3 Moderate 4 High 5 Very high

Cost < 5% ≥ 5% ≥ 10% ≥ 20% ≥ 30%

Time < 10% ≥ 10% ≥ 20% ≥ 30% ≥ 40%

Scope

Scope decrease

barely noticeable

Minor areas of scope affected

Major areas of scope affected

Scope reduction

unacceptable to sponsor

Project end item

significantly compromised

Quality

Quality degradation

barely noticeable

Only very demanding applications are affected

Quality reduction requires sponsor approval

Quality reduction

unacceptable to sponsor

Project end item

significantly compromised

46

Risk Breakdown Structure

Project

Technical External Organisational Project Management

Communication

Performance

Reliability

Integration

Contractual

Supply

Weather

Requirements Project depedencies

Resources

Funding

Estimation

Planning

Controlling

47

Risk Severity Matrix

0.25

0.2

0.15

PM-K T-C

0.1

T-D, E-F

0.05

O-H T-A, E-G, O-I, PM-L T-B, E-E, O-J

1 2 3 4 5

Impact

Like

lih

oo

d

Major Risk

Moderate Risk

Low Risk

Risk Event

Technical

Error in Requirements

SpecificationT-A

Failure to meet Quantitative

Performance RequirementsT-B

Failure to meet Reliability

RequirementsT-C

Failure in Component

IntegrationT-D

External

Contractual E-E

Supply E-F

Weather E-G

Organizational

Project dependencies O-H

Resources O-I

Funding O-J

Project Management

Error in Estimation PM-K

Communication Failure PM-L

48

Risk Response Matrix

Risk Event Response

Contingency Plan

Trigger

Responsible Party

Technical

Error in Requirements Specification

Technical Review Dependent on outcome of

technical review Integration FPT Head of Technical

Failure to meet Quantitative Performance Requirements

Technical Review Contractual Review

Dependent on outcome of review

Integration FPT Head of Technical and FPT

Head of Contract and Commercial Management

Failure to meet Reliability Requirements

Technical Review Contractual Review

Dependent on outcome of review

Testing FPT Head of Technical and FPT

Head of Contract and Commercial Management

Failure in Component Integration Technical Review Dependent on outcome of

technical review Integration and Testing FPT Head of Technical

External

Contractual Meeting with counterparty

Dependent on outcome of meeting

Non-compliance with contract

FPT Head of Contract and Commercial Management

Supply Meeting with supplier Dependent on outcome of meeting. Initiate alternate

supply sources. Supply disruption

FPT Head of Contract and Commercial Management

Weather Project Stakeholder

meeting Dependent on outcome of

meeting Assessment of project

stakeholders FPT Program Manager

Organizational

Project Dependencies Project Stakeholder


meeting

Project Schedule (Schedule variance

threshold) FPT Program Manager

Resources Project Stakeholder


meeting

Project Schedule (Schedule variance

threshold) Technical and Quality

concerns

FPT Program Manager and FPT Head of Technical

Funding FPT Project Team

Meeting Initiate Financing Treasury report FPT Project Owner

49

Project Management

Error in Estimation Project Stakeholder


meeting Schedule variance, Cost

variance FPT Program Manager

Communication Failure Project Stakeholder


meeting Issue raised by project

stakeholders FPT Program Manager

50

Risk Management Plan Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



51

CHANGE MANAGEMENT PLAN

The Change Management Plan was created in order to set expectations on how the approach to

changes will be managed, what defines a change, the purpose and role of the change control board,

and the overall change management process. All stakeholders will be expected to submit or request

changes in accordance with this Change Management Plan and all requests and submissions will

follow the process detailed herein.

Change Management Approach The Change Management approach will ensure that all proposed changes are defined, reviewed, and

agreed upon so they can be properly implemented and communicated to all stakeholders. This

approach will also ensure that only changes within the scope of this project are approved and

implemented.

The Change Management approach is not to be confused with the Change Management Process

which will be detailed later in this plan. The Change Management approach consists of three areas:

- Ensure changes are within scope and beneficial to the project - Determine how the change will be implemented - Manage the change as it is implemented

The Change Management process has been designed to make sure this approach is followed for all

changes. Using this approach methodology will prevent unnecessary change from occurring and

focus resources only on beneficial changes within the project scope.

Definitions of Change There are several types of changes which may be requested and considered for the project.

Depending on the extent and type of proposed changes, changes project documentation and the

communication of these changes will be required to include any approved changes into the project

plan and ensure all stakeholders are notified. Types of changes include:

- Scheduling Changes: changes which will impact the approved project schedule. These changes may require fast tracking, crashing, or re-baselining the schedule depending on the significance of the impact.

- Budget Changes: changes which will impact the approved project budget. These changes may require requesting additional funding, releasing funding which would no longer be required, or adding to management reserves. May require changes to the cost baseline.

- Scope Changes: changes which are necessary and impact the project’s scope which may be the result of unforeseen requirements which were not initially planned for. These changes may also impact budget and schedule. These changes may require revision to WBS, project scope statement, and other project documentation as necessary.

The Program Manager must ensure that any approved changes are communicated to the project

stakeholders. Additionally, as changes are approved, the Program Manager must ensure that the

changes are captured in the project documentation where necessary. These document updates

must then be communicated to the project team and stakeholders.

52

Change Control Board The Change Control Board (CCB) is the approval authority for all proposed change requests

pertaining to the project. The purpose of the CCB is to review all change requests, determine their

impacts on the project risk, scope, cost, and schedule, and to approve or deny each change request.

The following table provides a list of the CCB members for the project:

Name Position CCB Role

Gregg Barrett Project Owner Chair

Jim Bergmann Contract and Commercial

Management

Member

Gordon Murray Technical Head Member

Kevin Jones Program Manager Member

As change requests are submitted to the Program Manager by the project team/stakeholders, the

Program Manager will log the requests in the change log and the CCB will convene as necessary to

review all change requests. In the event more information is needed for a particular change request,

the request will be deferred and sent back to the requestor for more information or clarification.

Roles and Responsibilities The following are the roles and responsibilities for all change management efforts:

Project Owner:

- Approve all changes to budget/funding allocations - Approve all changes to schedule baseline - Approve any changes in project scope - Chair the CCB

Program Manager:

- Receive and log all change requests from project stakeholders - Conduct preliminary risk, cost, schedule, scope analysis of change prior to CCB - Seek clarification from change requestors on any open issues or concerns - Make documentation revisions/edits as necessary for all approved changes - Participate on CCB

Project Team/Stakeholders:

- Submit all change requests on standard organizational change request forms - Provide all applicable information and detail on change request forms - Be prepared to address questions regarding any submitted change requests - Provide feedback as necessary on impact of proposed changes

53

Change Control Process The Program Manager has overall responsibility for executing the change management process for

each change request.

1) Identify the need for a change (Stakeholders) – Change requestor will submit a completed change request form to the Program Manager.

2) Log change in the change request register (Program Manager) – The Program Manager will keep a log of all submitted change requests throughout the project’s lifecycle.

3) Submit change request to CCB (Program Manager) – The Program Manager will submit the change request, to the CCB for review.

4) Obtain a decision on the change request (CCB) – The CCB will discuss the proposed change and decide whether or not it will be approved based on all submitted information.

5) Implement change (Program Manager) – If a change is approved by the CCB, the Program Manager will update and re-baseline project documentation as necessary.

54

Change Request Form


Project Owner: Gregg Barrett

Request Number:

Change Request Date:

Originator:

Review Request by:

Description of requested change: Reason for change:

Areas of impact of proposed change:

Scope: Schedule:

Cost: Risk:

Disposition Priority Funding Source Approve Emergency Management Reserve

Approve as amended Urgent Budget Reserve Disapprove Low Customer

Deferred Other

Sign-off Approvals

Program Manager

Date

Project Owner

Date

Head Technical

Date

Head Contract and Commercial Management

Date

55

Change Management Plan Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



56

HUMAN RESOURCE MANAGEMENT PLAN The human resources management plan is a tool which will aid in the management of this project’s

human resource activities throughout the project until closure. The human resources management

plan includes:

- Roles and responsibilities of team members throughout the project - Project organization chart - Staffing management plan

The purpose of the human resources management plan is to achieve project success by ensuring the

appropriate human resources are acquired with the necessary skills, team building strategies are

clearly defined, and team activities are effectively managed.

Roles and Responsibilities The roles and responsibilities for the project are essential to success. All team members must clearly

understand their roles and responsibilities in order to successfully perform their portion of the

project. For the project the following project team roles and responsibilities have been established:

Program Manager (1 position): Responsibility:

- to manage all project tasks, scheduling, and communication regarding the project. - to approve all budget expenditures up to, and including, the allocated budget amounts. (Any

additional funding must be requested through Mr. Jim Bergmann, head of Contract and Commercial Management at First Principles Technologies.)

- to interface with management as required, request resources, delegate responsibilities within the framework of the project, and to communicate with all contractors, as required, to ensure successful and timely completion of the project.

- report project status in accordance with the communications management plan. - facilitate scope change requests. - organize and facilitate scheduled change control board (CCB) meetings. - conduct preliminary risk, cost, schedule, scope analysis of change prior to CCB. - participate on CCB - communicate outcomes of scope change requests. - update project documents upon approval of all scope changes. - communication Escalation Process: Decision maker on Priority 3 matters

Project Owner (1 position): Responsibility:

- chair the CCB. - review of proposed schedule and approve the final schedule before it is baselined. - approve all changes to budget/funding allocations - approve all changes to schedule baseline - approve any changes in project scope - communication Escalation Process: Decision maker on Priority 1 matters

57

Contract and Commercial Management (1 position) Responsibility:

- review requests for additional funding. - establish and approve documentation for measuring project scope which includes

deliverable quality checklists and work performance measurements. - review and approve all deliverables. - review and approve all components of the project plan. - member of the CCB. - conduct contractual review in the event of failure to meet reliability requirements, as part of

the risk response. - meet with counterparty in the event of non-compliance with contract, as part of the risk

response. - meet with supplier in the event of a supply disruption, as part of the risk response - communication Escalation Process: Decision maker on Priority 2 matters

Technical Head (1 position): Responsibility:

- develop technical design solutions for the project. - oversee development of the technical submission for the suspension package and brake

package. - oversee technical evaluation of the suspension and brake package suppliers. - establish and approve documentation for measuring project scope which includes

deliverable quality checklists and work performance measurements. - review and approve all deliverables - member of the CCB - conduct technical review in the event of error found requirements specification, as part of

risk response - conduct technical review in the event of Failure to meet Quantitative Performance

Requirements, as part of the risk response - conduct technical review in the event of failure to meet Reliability Requirements, as part of

the risk response. - conduct technical review in the event of Failure in Component Integration, as part of the risk

response. - communication Escalation Process: Decision maker on Priority 2 matters

Project Organizational Charts The following RASCI chart shows the relationship between project tasks and team members. Changes will be proposed in accordance with the project’s change control process. As changes are made all project documents will be updated and redistributed accordingly.

RACI.xlsx

58

Staff Acquisition There is currently no staff acquisition schedule since the organization has the required staff with

required skill sets.

Training There is currently no training schedule since the organization has adequate staff with required skill

sets.

Recognition and Rewards Following the project kick-off meeting the Program Manager will schedule a meeting with FPT, Riley

and Fioravanti Management to explore possible recognition and reward options for the project.

Resource loaded/leveled baseline

Resource load.xlsx

Human Resource Management Plan Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



59

LESSONS LEARNED APPROACH The purpose of the lessons learned document is to capture the project’s lessons learned in a formal

document for use in future projects. This document may be used as part of new project planning for

similar projects in order to determine what problems occurred and how those problems were

handled and may be avoided in the future. Additionally, this document details what went well with

the project and why, so that future initiatives may capitalize on these actions. This document will be

formally communicated with the organization and will become a part of the organizational assets

and archives.

The lessons learned from the project will be compiled from project journal entries throughout the

project lifecycle. Lessons learned are also to be gathered from both realized and unrealized risks in

the project risk register as well as through interviews with project team members and other

stakeholder as necessary. The lessons learned from this project will be used as references for future

projects and contain an adequate level of detail so that other project managers may have enough

information on which to help base their project plans. The lessons learned in this document are

categorized by project knowledge area.

These knowledge areas consist of

- Stakeholder management - Communications management - Scope management - Cost management - Schedule management - Risk management - Change management - Human resource management

Lessons learned from this Project The following table will be used to list the lessons learned for the project. These lessons are

categorized by knowledge area. It is important to note that not only failures or shortcomings are

included but successes as well.

Category Description Problem/Success Impact Recommendation

Stakeholder Management

Communication Management

Scope Management

Cost Management

Schedule Management

Risk Management

60

Change Management

Human Resource Management

Lessons learned knowledge base The lessons learned from the project together with all project documentation will be archived on the

First Principles Technologies SharePoint Server. This information will be catalogued under the

project’s year (2015) and the project name (DP Zero 1) for future reference.

Lessons Learned Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



61

PROCUREMENT MANAGEMENT PLAN The Procurement Management Plan sets the procurement framework for this project. It will serve

as a guide for managing procurement throughout the life of the project and will be updated as

acquisition needs change. This plan identifies and defines the items to be procured, the types of

contracts to be used in support of this project, the contract approval process, and decision criteria.

The importance of coordinating procurement activities, establishing firm contract deliverables, and

metrics in measuring procurement activities is included. Other items included in the procurement

management plan include: procurement risks and procurement risk management considerations;

how costs will be determined; how procurement documentation will be used; and procurement

constraints.

Procurement management approach The Head of Contact and Commercial Management will provide oversight and management for all

procurement activities under this project. The Program Manager will work with the project team to

identify all items to be procured for the successful completion of the project. The Contract and

Commercial Management office together with the Technical Head will then review the procurement

list and begin the supplier selection and contracting process..

Procurement definition The following procurement items and services have been determined to be essential for project

completion and success.

Item/Service Justification Date

Brake package Critical component Selection made by

17/07/2015

Suspension package Critical component Selection made by

17/07/2015

In addition to the above list of procurement items, the following individuals are authorized to

approve purchases for the project team:

Name Role

Gordon Murray Technical Head

Jim Bergmann Contract and Commercial Management

Type of contracts All items and services to be procured for this project will be solicited under firm-fixed price

contracts. The contracts and commercial management office will solicit bids from suppliers. Supplier

62

bids will then be reviewed by the Technical Head, the Head of Contract and Commercial

Management and the Project Owner.

Procurement risk management All procurement activities carry some potential for risk which must be managed to ensure project

success. While all risks will be managed in accordance with the project’s risk management plan,

there are specific risks which pertain specifically to procurement which must be considered:

- Unrealistic schedule and cost expectations for suppliers - Manufacturing capacity capabilities of suppliers - Conflicts with current contracts and supplier relationships - Potential delays in delivery and impacts on cost and schedule - Potential that final product/service does not meet required specifications

These risks are not all-inclusive and the standard risk management process of identifying,

documenting, analysing, mitigating, and managing risks will be used.

As previously stated, project risks will be managed in accordance with the project’s risk management

plan. However, for risks related specifically to procurement, there must be additional consideration

and involvement. Project procurement efforts involve external organizations and potentially affect

current and future business relationships as well as internal supply chain and supplier management

operations. Because of the sensitivity of these relationships the project team will include the

Technical Head and the Head of Contract and Commercial Management in all project meetings and

status reviews.

Additionally, any issues concerning procurement actions or any newly identified risks wi ll

immediately be communicated to the Head of Contract and Commercial Management.

Cost determination For this project a Request for Proposal (RFP) will be issued to solicit proposals from various suppliers

covering how they will meet the technical requirements and the cost of doing so. The technical

requirements of the RFP will be compiled by the Technical Head while all non-technical sections will

be compiled by the Head of Contract and Commercial Management.

Procurement documentation The procurement management process consists of many steps as well as ongoing management of all

procurement activities and contracts. The goal must be to simplify procurement management by all

necessary means in order to facilitate successful completion of the project. To aid in simplifying

these tasks, the knowledge base of the Contract and Commercial Management Office will be used.

The Contract and Commercial Management Office maintains a clause and template library on FPT’s

Contract Management system that will be used for this project. The following documents will be

used (at a minimum) for project procurement activities:

63

- RFP o Background o Proposal process and timelines o Proposal guidelines o Technical specification o Proposal formats and media o Selection criteria o Pricing forms o Statement of work o Terms and Conditions

- Mutual non-disclosure agreement - Letter of intent - Firm fixed price contract - Procurement audit form - Procurement performance evaluation form - Lessons learned form

Procurement constraints There are several constraints that must be considered as part of the project’s procurement

management plan. These constraints will be included in the RFP and communicated to all suppliers.

Schedule:

- Project schedule is not flexible and the procurement activities and contract fulfilment must be completed within the established project schedule.

Technology:

- Specifications will be included in the statement of work as part of the RFP. While proposals may include suggested alternatives and/or enhancements, parts specifications must match those provided in the statement of work exactly.

Contract approval process The Program Manager will work with the project team, the Technical Head and the Head of Contract

and Commercial Management to define the item types, quantities, services and required delivery

dates. The contracts and commercial management office will then solicit bids from suppliers.

Supplier bids will then be reviewed by the Technical Head, the Head of Contract and Commercial

Management and the Project Owner, together constituting the Contract Review Board.

Once a contract has been approved by the Contract Review Board the Program Manager is

authorized to approve all expenditures up to, and including, the allocated amounts i n accordance

with the contract.

Decision criteria The criteria for the selection and award of procurement contracts under this project will be based on

the following decision criteria:

- Ability of the supplier to provide all items by the required delivery date

64

- Quality and Reliability - Cost including ongoing maintenance and replacement - Past performance - Technical expertise

Supplier management The Head of Contact and Commercial Management is ultimately responsible for managing suppliers.

In order to ensure the timely delivery and high quality of products from suppliers the Head of

Contract and Commercial Management together with the Head of Technical, will meet weekly with

each supplier to discuss the progress for each procured item. The meetings can be in person or by

teleconference. This forum will provide an opportunity to review each item’s development or the

service provided in order to ensure it complies with the requirements established in the project

specifications. It also serves as an opportunity to ask questions or modify contracts or requirements

ahead of time in order to prevent delays in delivery and schedule. The Program Manager will be

responsible for scheduling this meeting on a weekly basis until all items are delive red and are

determined to be acceptable.

Performance metrics for procurement activities The following metrics are established for supplier performance for this project’s procurement

activities. Each metric is rated on a 1-3 scale as indicated below:

Supplier Product

Quality

On Time

Delivery

Documentation

Quality

Technical

Expertise

Transactional

Efficiency

Service

Quality

Brake

Package

Supplier

Suspension

Package

Supplier

1 – Unsatisfactory 2 – Acceptable 3 - Exceptional

65

Procurement Management Plan Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



66

EXAMPLE STATUS REPORT Please see the Appendix for details concerning the calculations and interpretation of Earned Value.

Week 1: The work on task 6.1 was on schedule. The Actual Cost (AC) was 9000 USD and Planned Value (PV)

was 9000 USD. Task 6.1 is 42% complete.

The work of task 1.1 was on schedule. The AC is 9000 USD and PV is 9000 USD. Task 1.1 is 56%

complete.

Week 2: Work on Task 6.1 fell slightly behind schedule, due to some aerodynamic challenges encountered in

the redesign of the front splitter, engine intake and cooling and accommodating the rear diff user.

Earned Value (EV) was 8550 USD while PV was 9000 USD. AC came in at 10595 USD, higher than the

PV of 9000 USD due to the additional simulation work being required. Task 6.1 is 81% complete.

Work on Task 1.1 fell slightly behind schedule, due to some challenges in incorporating the body

redesign changes. EV was 6840 USD while PV was 7200 USD. AC was 7063 USD, higher than the PV of

7200 USD, due to the addition of a resource. Task 1.1 is 97% complete.

Week 3: The work outstanding from week 2 on Task 6.1 was completed. The remaining work on Task 6.1

scheduled for this week was also completed with an EV of 1800 USD, PV of 1800 USD and AC of 1800

USD. Task 6.1 Body: Design Modification, is now complete.

The work outstanding from week 2 on Task 1.1 was completed. The AC of 7416 USD exceeded the PV

of 7200 USD due to the addition of a resource. Task 1.1: Chassis: Design Modification is now

complete.

The CAD Integration activity started two days late due to the work still being done on Task 6.1 and

1.1. The EV for the week on the CAD Integration was 1782 USD compared to a PV of 5400 USD. Only

33% of the CAD Integration activity scheduled for week 3 was completed, however this is not a

serious issue.

Status Report: Week 2 % of week schedule EV AC PV CV SV SPI CPI % of task complete

Task

6.1 0.95 8550 10594.8 9000 -2044.8 -450 0.95 0.807 0.8125

1.1 0.95 6840 7063.2 7200 -223.2 -360 0.95 0.9684 0.977777778


Task

6.1 1 9000 9000 9000 0 0 1 1 0.416666667

1.1 1 9000 9000 9000 0 0 1 1 0.555555556

67

Week 4: All the work outstanding on the CAD Integration was completed this week. An additional resource

was added to assist in the work. This resulted in the AC exceeding the PV. The CAD Integration task is

now complete.

Task 2.1 Brakes: Technical, was started and completed according to schedule. PV and AC was 5400

USD.

Task 3.1 Suspension: Technical, was started and completed according to schedule. PV and AC was

5400 USD.

Task 9.1, 1.3, 6.3 and 7.1 are running behind schedule with only 33% of the work that was scheduled

this week having been completed. This was due to the work on the CAD Integration running two

days behind schedule.

Week 5: The work outstanding on Task 9.1, 1.3, 6.3 and 7.1 from week 4 was completed this week.

Task 9.1 was on schedule and the AC equalled the PV of 9000 USD. Task 9.1 is 80% complete.

Task 1.3 was on schedule and the AC equalled the PV of 6000 USD. Task 1.3 is now 26% complete.

Task 6.3 was of schedule and the AC equalled the PV of 4500 USD. Task 6.3 is now 53% complete.

Task 7.1 was on schedule and the AC equalled the PV of 9000 USD. Task 7.1 is now 44% complete.


Task

6.1 5% from week 2 9000 11124.54 9000 -2124.54 0 1 0.809022 0.833333333

100% of week 3 1800 1800 1800 0 0 1 1 1

1.1 5% from week 2 7200 7416.36 7200 -216.36 0 1 0.970827 1

1.2, 4.1, 5.1, 6.2, 8.1,

9.2 0.33 1782 1962 5400 -180 -3618 0.33 0.908257 0.2


Task

1.2, 4.1, 5.1, 6.2, 8.1,

9.2 67% from week 3 5400 5886 5400 -486 0 1 0.917431 0.6

100% of week 4 3600 3924 3600 -324 0 1 0.917431 1

2.1 1 5400 5400 5400 0 0 1 1 1

9.1 0.33 1800 1800 5400 0 -3600 0.333333 1 0.1

1.3 0.33 1200 1200 3600 0 -2400 0.333333 1 0.033333333

3.1 1 5400 5400 5400 0 0 1 1 1

6.3 0.33 900 900 2700 0 -1800 0.333333 1 0.066666667

7.1 0.33 1800 1800 5400 0 -3600 0.333333 1 0.055555556

68

Summary: At the end of Week 5 the EV is 101 400 USD and a PV of 101 400 USD. The Schedule Variance (SV) is

therefore 0 and the project is on schedule – this can also be seen with the Schedule Performance

Index (SPI) of 1.

The Cost Performance Index (CPI) is a little below 1 at 0.97 due to the AC being slightly higher at

104 551 than the EV at 101 400. The higher AC is primarily due to the higher costs associated with

Task 6.1 and Task 1.1 in Week 2, where additional resources were added to the project.

Summary EV AC PV CV SV SPI CPI

Total 101400 104550.9 101400 -3150.9 0 1 0.969862526

The expected status of the project at completion is given by the EAC(f) calculated below:

EAC(f) Forecasted estimate cost at completion

EAC(f)= AC+[(BAC-EV)/CPI]

Total AC at week 5 104550.9

Total BAC 226800

Total EV at week 5 101400

BAC-EV at week 5 125400

CPI at week 5 0.969863

EAC(f) at week 5 233847.6

Based on the EAC(f) calculated at Week 5, the project will exceed the total planned value (BAC) by

7048 USD. This of course assumes that the CPI remains constant over the remainder of the project.


Task

9.1 67% from week 4 5400 5400 5400 0 0 1 1 0.3

100% of week 5 9000 9000 9000 0 0 1 1 0.8

1.3 67% from week 4 3600 3600 3600 0 0 1 1 0.1

100% of week 5 6000 6000 6000 0 0 1 1 0.266666667

6.3 67% from week 4 2700 2700 2700 0 0 1 1 0.2

100% of week 5 4500 4500 4500 0 0 1 1 0.533333333

7.1 67% from week 4 5400 5400 5400 0 0 1 1 0.166666667

100% of week 5 9000 9000 9000 0 0 1 1 0.444444444

69

PROJECT CLOSE This document establishes formal acceptance of all the deliverables for the DP Zero 1 project. The

project has met all the acceptance criteria as defined in the requirements document and project

scope statement. A project review has been performed to verify that all deliverables meet

performance and specification requirements. Additionally a product evaluation has been performed

through two test sessions and it has been determined that the vehicle meets the quality and

functional requirements defined within this project.

The Program Manager is authorized to continue with the formal close out of this project. The

closeout process will include the scheduling of a post-project review meeting, documentation of

lessons learned, release of the Project teams, and the archive all relevant project documents.

Once the closing process is completed the Project Owner will be notified and the Program Manager

will then be released from the project.

Project Close Acceptance

_______________________________________________ Date: ______________________

Jim Bergmann



70

APPENDIX

PROJECT TEAM DIRECTORY The following table presents contact information for all persons identified in the communications

management plan. The email addresses and phone numbers in this table will be used to

communicate with these persons.

First Principle Technologies (FPT)

Project Role

Name Position at FPT Email Phone

Project Owner Gregg Barrett CEO [email protected] 719 555 9899

Program Manager Kevin Jones Program Manager [email protected] 719 555 9890

Contract and Commercial Management

Jim Bergmann Head: Contract and Commercial Management

[email protected] 719 555 9895

Technical Head Gordon Murray Technical Head [email protected] 719 555 9885

Riley Technologies

Project Role

Name Position at Riley Email Phone

Riley Management Bill Riley CEO [email protected] 704 663 6325

Riley Management Bill Fingerlow General Manager [email protected]

704 663 6323

Project Manager Kenneth Swan Project Manager [email protected]

704 663 6320

Engineering, chief vehicle engineer

Jim Kasprzak Head: Engineering

[email protected]

704 663 6315

Engineering, electrical

Jon Miles Senior Engineer [email protected]

704 663 6314

Engineering, chassis

Tyler Hook Senior Engineer [email protected]

704 663 6312

Engineering, suspension

Ray Banda Senior Engineer [email protected]

704 663 6311

Engineering, powertrain

Charles Long Senior Engineer [email protected]

704 663 6310

Fioravanti

Project Role

Name Position at Fioravanti

Email Phone

Fioravanti Management

Leonardo Fioravanti

CEO [email protected]

949 780 3298

Project Chief Designer

Marco Fernelli Chief Designer [email protected]

949 780 3284

Interior Chief Designer

Louis Augeri Interior Chief Designer

[email protected]

949 780 3280

71

Project Manager Francine Facchini

Project Manager [email protected]

949 780 3276

Ford Motor Company

Project Role

Name Position at Ford Email Phone

Power unit supply Jamie Allison Ford Racing Director

[email protected]

313 845 8648

Xtrac

Project Role

Name Position at Xtrac Email Phone

Gearbox supply Paul Barton Commercial & Engineering Manager

[email protected]

704 799 4489

Ricardo

Project Role

Name Position at Ricardo

Email Phone

Exhaust supply Tom Franks Head of NVH [email protected]

408 496 5344

Brake Supplier

Project Role

Name Position at Email Phone

Brake supply Suspension Supplier

Project Role

Name Position at Email Phone

Suspension supply

72

EARNED VALUE DETAILS

PV The planned time-phased value of the work

that is scheduled

EV Earned value is simply percent complete times

its budgeted cost of the work

EV = % Complete * PV

AC Actual cost of the work completed

CV Cost variance adjusted budget costs to the

actual spent costs

CV = EV-AC

CPI Cost performance index is a measure of cost

efficiency on a project

CPI = EV/AC

SV Schedule variance: How much work that has

been done compared with how much should

have done at this point in time

SV = EV-PV

SPI Schedule performance index is a measure of

schedule efficiency on a project

SPI = EV/PV

BAC The total planned value of the project

Earned Value calculations used in the Example Status Report

EV calculations.xlsx

73

GUIDANCE ON CREATING HIGH PERFORMANCE TEAMS In terms of laying the groundwork for high performance teams, the presentation below titled

“Netflix Culture: Freedom & Responsibility” was developed at Neflix by Patty McCord and posted by

CEO Reed Hastings on SlideShare. Building on the presentation Ikhlaq Sidhu at UC Berkeley produced

a useful summary which has been included below.

Culture - High Performance - Netflix.pdf

How to build high performance teams

by Ikhlaq Sidhu

Chief scientist, faculty director and founding director, Center for Entrepreneurship & Technology,

IEOR department, College of Engineering, UC Berkeley

[The} key idea is that this type of organizational culture is not like a family. Instead, its much more

like a professional sports team. Professionals are paid at top rates. The goal is to hire stars for every

position. The rationale is that each high performer can deliver 10x in performance. And unlike a

family, they don’t mind when its time for a player to leave. The culture also does not provide career

planning. The best long-term security is to have a have a great reputation of having accomplished

great things and the skills to match.

Of course high performance teams are flat (non-hierarchical) and they typically value innovators,

conflict (required to seek out the best of ideas), and clear, direct communication.

Other concepts for high performance teams are:

Results-oriented. Hard work is actually irrelevant, only the results matter. The firm won’t measure anyone’s time in the office or even vacation days. In fact, there is not even an expense policy. The guidance is to simply use common sense to do what is right for the organization.

Low Process/High Flexibility. High performers thrive on freedom. However, as firms grow, they use processes to combat the complexity from scaling. This has a tendency to cripple innovation and drive out high performers. The proposal made in this slide set is to grow by hiring only truly high performing people and to avoid adding process and new rules. This leaves the organization flexible so that it can adapt to the inevitable changes yet to come.

Context-focused not delegation-focused. There is some highly relevant advice for managers as well. As we know, high performers thrive on freedom, so consider this concept from Antoine De Saint-Exupery, “If you want to build a ship, don’t drum up the people to gather wood, divide the work, and gi ve orders. Instead teach them to yearn for the vast and endless sea.” According to McCord, “The best managers figure out great outcomes by setting the appropriate context, rather

74

than trying to control people.” Don’t set top-down decisions, don’t use management approvals, and don’t defer to committees. And planning and process should never be valued over result. “When one of your people does something dumb, don’t blame them. Instead: Ask yourself what context you failed to set.” And, “when you are tempted to control, ask yourself what context you could set instead.”

The document explains the behaviors that a high performance culture expects. According to its author, high performance culture is not for everyone. And for that matter, it’s not for every organization.

Questions to consider:

1. How would you know whether a “high performance culture” is right for your organization’s mission?

2. Could this be established in pockets of the organization or does it need to be driven top -down and implemented everywhere?

3. What are the drawbacks or downsides to high performance team culture?

(Sidhu, 2011)

75

PERFORMANCE IMPROVEMENT Setting the stage for project management – a primer on the basics:

The following three points have been proposed as key areas of focus for attaining success in project

management within the organisation:

- The appointment of a project manager with authority and responsibility over the project

lifecycle

- Establishment of an organisational culture conducive to the creation of high performance

teams. Please refer to the section “Guidance on creating high performance teams”.

- Implementation of the project lifecycle within the organisation

This introduction on performance improvement in project management will focus on the project

lifecycle, providing a high level overview of the four stages.

Project Lifecycle (Larson and Gray, 2010)

Four stages of the project lifecycle:

- Definition

- Planning

- Execution

- Closing

76

The Defining Stage

In the defining stage we ask ourselves the fundamental question; what is that we wish to accomplish

and how will we go about attaining our objective(s)?

The output of this process will be our project objective. The project objective should be clearly

defined, understandable and communicated to all project participants. Additional outputs at this

stage at a high level will include the definition of goals along the way that will help us in achieving

our objective, the skills and competencies of required team members, high level specifications, tasks

and responsibilities of team participants.

The project objective sets the course for the project and should be instilled in the hearts and minds

of all participants.

The Planning Stage

At this stage we get stuck into the details, leaving no stone unturned in an effort to establish

schedules, budgets, resources requirements and identify project risks. With planning we go through

that tough mental effort of understanding all that we can about how we are going to lay the ground

work and muster the troops to achieve project success. In this stage we build upon the work done in

the defining stage as we align goals with budgets, responsibilities with resources, tasks with

schedules and concern ourselves with risk management – always hoping for the best but being

prepared for the worst.

The planning stage is fertile ground for the seeds of project failure – so don’t let them germinate by

being negligible with the planning. Research by Daniel Kahneman and Amos Tversky has shown that

people tend to be overly optimistic and underestimate task completion times. Bent Flyvbjerg has

proposed an approach called reference class forecasting to mitigate the planning fallacy.

At a high level reference class forecasting entails:

- Identifying an appropriate reference class

- Obtain the statistics of the reference class and use to generate a baseline prediction

- Use specific information about the case to adjust the baseline prediction

The Executing Stage

The third stage of the project lifecycle is the execution stage. The execution stage is typically the

longest stage in the project lifecycle and includes the formulation of status reports, change

management, quality management and forecasting. The execution stage is where the rubber me ets

the road, our objective starts to take on a more tangible form as our plans are translated into action.

Good planning in the prior stage should result in smooth sailing in the execution stage , however

storms can form at any time and it is then that the value of a risk management plan will be put to

the test.

Management and control are critical in the execution stage, with the point of reference being the

schedule, cost and scope produced during the planning stage.

77

The Closing Stage

The closing stage typically covers the delivery of the final product/service (the objective defined at

the very start), a post project review should now be conducted and the closing stage may also

involve the redeploying of project resources. Post project review is an important component of the

project lifecycle and one that is often overlooked. Post project review serves as the input for

improvements in future project planning, as all the learning that occurred throughout the project

lifecycle is formalised as lessons learned.

78

REFERENCE Sidhu, I. (2011). How to build high performance teams. [blog].

Retrieved from http://blogs.berkeley.edu/2013/08/06/11254/ Larson, E. W., & Gray, C. F. (2010). Project management: The managerial process with MS Project

(5th ed.). McGraw-Hill Higher Education. [ISBN-13: 978-1259186400]

http://blogs.berkeley.edu/2013/08/06/11254/

Automotive

Road and Track Vehicle - Project Document