moser.bryan

Global Project Design © 2009 www.gpdesign.com

Rapid, Collaborative Planning for Global Teams

through Project Design

Bryan R. [email protected]

NASA Challenge 2009

February 24-25, 2009

Slide 1

Global Project Design © 2009 NASA Challenge 2009 www.gpdesign.com

Outline 1. The Challenge of Global Projects

2. Project Design:Rapid, Accurate, & Shared Plans including Forecast of Coordination

3. Case Study: Global Product Development

4. Conclusion

Slide 2


1. The Challenge of Global Projects

NASA Challenge 2009

Slide 3


Challenges of Global Projects

Teams from different time zones, work cultures, costs, and abilities.

Subsystems and services to be integrated in an overall solution, yet the “central” team does not have complete control

Costs and risks from coordination, communication, re‐work, and quality are 40% or greater of real effort

Expected Results difficult to predict with significantly greater consequences if ignored

Slide 4


Work In 1909:

An Industrial Age

Ways of WorkingStandard Work Narrow specialtiesExpert managementAutomated resources

Slide 5

Communication, Uncertainty, Communication, Uncertainty, & Adaptive Behavior & Adaptive Behavior

are Avoidedare Avoided


Century old assumptions strongly

embedded

False precision of detail becomes substitute for awareness &

adaptive learning

Slide 6

The Gantt Chart Circa 1914

Not included in century old methods:Complex Dependence amongst activitiesCommunication & MeetingsDecisions, Exceptions, and Re-work Travel, Time Zones, and WorkdaysReasons for Waiting related to others

The Missing Half of Plans is

CoordinationCoordination


2. Project Design:Rapid, Accurate, & Shared Plans

including Forecast of Coordination

NASA Challenge 2009

Slide 7


Planning and Designing Are Very Different

Slide 8

PlanVerb. To work out in

some detail how something is to be done or

organized.

Planning may be sufficient for routine, repeatable projects with limited uncertainty

DESIGN is essential to optimize performance and manage risk in enterprise initiatives

DesignDesignVerb. To create the form or structure of something in a

skillful or artistic way.


BusinessBusinessResultResultTypicalTypical

Project Design:

Multiple Forecasts are prototype

“crashes” of real project

Slide 9

Cost Cost (M$)(M$)

3818 24 28 32 36

12

15

24

21

18

BusinessBusinessTargetTarget

Hoped ForHoped For

PrePre--LaunchLaunchForecastsForecasts

Likely ResultLikely Resultwith Aswith As--Is BehaviorIs Behavior

Optimized Optimized PlanPlan

Feasible & FocusedFeasible & Focusedfor Targeted Scopefor Targeted Scope

Option 1Option 1

TradeTrade--off off for timefor time

Option 2Option 2

TradeTrade--off off for costfor cost

Duration (months)Duration (months)

1. Project Model& Simulation

2. Design Iteration& Optimization

3. Trade-Off Dialogue on Feasible Plans


Scope:Locations,

Teams (OBS), Product (PBS),

and Phases (WBS)

Slide 10


Architecture:Complex

dependence (concurrent &

mutual )

Slide 11


Real‐time Collaborative Modeling

In different languages

& points of view

Slide 12

SIMULATORUnique insight from predictive analytics

• Analyzes coordination effort & costs

• Real-world behavior & uncertainty

• Constraints of team distribution

• Detailed output from hi-level input

Project DesignDESIGNER

Visual models to capture project & complexity

• Top-down & linked to strategy

• Product, work, & teams

• Global roles & priorities

• Concurrent dependencies

Smart Dialogue & Team Collaboration

FORECASTReview of realistic plans, scenarios & options

•Product & phase schedules

•Team progress, efforts, costs

•Concurrency, wait, & re-work

• opportunities & riskSlide 13

Global Project Design ©2009

www.gpdesign.com


Simulation generates

forecasts rapidly

Includes coordination

effort, costs and schedule impact

Slide 14


Teams examine Forecasts from

multiple viewpoints: WBS & PBS

Slide 15


Coordination is real effort.

Impact on schedule clearly

visible.

Slide 16


Progress Forecasts

Slide 17Percent of Effort

Shown with range of standard deviation and high/low of forecasts

Percent of EffortPercent of EffortShown with range of standard Shown with range of standard

deviation and high/low of forecastsdeviation and high/low of forecasts

Progress in Real World Units,

not just Spending & Percent

Progress in Progress in Real World Units, Real World Units,

not just not just Spending & PercentSpending & Percent

DrawingsDrawings

DocumentsDocuments

ModulesModules

TestsTests

PartsParts


Frequent Iterations& What If Scenarios

50 or more plans for a complex project in days

Slide 18

Model #Raw FTE

hrs Forecast Effort hrsWait %

Coord %

Go‐Livedate

Cost$ Description Realistic?

114 4704 6891 8% 11% 12/24/07 258,692$ Added meeting to first modeling approach no

131 4704 6838 7% 23% 12/12/07 257,368$ Execute Commit not hard gateway no

138 4600 5735 1% 9% 02/19/08 287,472$ simple assignments no mutual deps no

139 4600 6450 9% 9% 02/14/08 325,420$ simple assignments & 1 mutual dep somewhat

143 4600 10157 35% 8% 02/23/08 427,561$ added 3 mutual deps somewhat

144 4600 9082 23% 11% 01/05/08 360,000$ Some blended assignments almost

147 4600 7439 12% 18% 12/24/07 293,500$ Blended assignments & PMs as Decide almost (but cost)

148 4600 7753 14% 15% 12/20/07 264,988$ All Arcana efforts priced at 0 yes

153 4600 6748 8% 16% 12/11/07 246,496$ From 4 to 5 IT developers in SF yes

154 4600 7067 15% 13% 12/06/07 265,325$ From 3 to 4 AST Developers yes


Estimation of Coordination Activity

How can we estimate coordination?

Slide 19


Dependence an architectural

measure of need

Slide 20

DependenceDependence

Team 1Team 1 Team 2Team 2

What does my team need in the progress & results from others?

DEMANDfor coordination

Can we predict the amount of coordination effort required to effectively complete our direct work?


E A C D B G F

E X

A X X

C X X X X

D X X

B X X X

G X X X X

F X X X

Dependence

Design Structure Matrix (DSM)

Slide 21

A B C Level of Dependence

A A • • • Small

B • B • Medium

C • • C • Large

Level of DependenceTo Partition Tightly Coupled Tasks

McCord, Eppinger, Aug 1993

A B C

A 4 .2

B .4 7 .5

C .3 .1 6

Time Duration & ProbabilityTo Predict Total DurationWork Transformation Matrix

Smith, Eppinger, Apr 1994

A B C

A X X

B X

C X X X

Task Dependency in Matrix FormGoal is to sequence and partitionSome tasks are too tightly linked

D. Steward, 1981


Aircraft Global Development

Project

4 major subsystems with 13 Key activities and Dependence

Slide 22

Part6 Part1 Part16 Part5spec

IF

mfg

rvw

IF

mfg

rvw

IF

mfg

rvw

IF

mfg

rvw

specPart6 IF fs 6ri 5ri fsPart6 mfg co 3r time-basedPart6 rvw co (finish to start)Part1 IF fs 2r 2r coPart1 mfg 3r co continuous flow Part1 rvw co (parallel)Part16 IF fs 4iPart16 mfg co otherPart16 rvw co (information...)Part5 IF fsPart5 mfg 4ri 1ri 5ri 5r coPart5 rvw co

release co co co co

1ri early some results&info2r early most results 5r parallel half results3r early all results 5ri parallel half info & results4i early/para, some info 6ri late most info & results4ri early/para some results&info

downstream

activity

upstream activity


Sum of Remaining Activity_From

Activity_To Electronic Design

Motor design

Signal Design

A &Pkg_Design

Shell Design

Electronics Proto

Motor Proto

Shell Proto

Signal Proto

Test & Ship

Electronic Design 288

Motor Design 168

Signal Design 93

A &Pkg_Design 968

Shell Design 288

Electronics Proto 168

Motor Proto 800

Shell Proto 320

Signal Proto 288 288

Test & Ship 288 168 128 93 168 380

Sum of Remaining Team_From

Team_To GAC Design

T1 Supplier

T2 Plastics_Team

T2 Electronics

T2 Signal Engineers

T2 Motor

GAC Design 456

T1 Supplier 968 668 93 168 168 128

T2 Plastics_Team 320

T2 Electronics 549

T2 Signal Engineers 576

T2 Motor 800

For coordination Team structure

matters

Architecture determines if dependence

stretches across teams

23

Dependencies by Activity (DSM) mapped to Dependence across Teams


Why dependence is not enough

Coordination is interaction across the architecture to allow downstream effective independence.

Teams that aren’t dependent have no need to coordinate.

Even if demanded, coordination is not guaranteed to occur.

Coordination requires attention, priority, & capacity .

Interaction, communication, meetings, learning, and response consume TIME AND BUDGET.

Slide 24


Coordination Distance is the Supply Side

Slide 25

DistanceDistanceDependenceDependence


What does my team need in the progress & results from others?

What is my team’s ability to coordinate with others?

DEMANDfor coordination

SUPPLYof coordination

Can we predict the amount of coordination effort required to effectively complete our direct work?


Team_Name GAC Design

T1 Supplier

T2 Plastics_Team

T2 Electronics

T2 Signal Engineers

T2 Motor

GAC Design 0.5 1.1 1.8 1.4 1.2 1.3

T1 Supplier 1.1 0.2 1.7 1.3 1.1 1.5

T2 Plastics_Team 1.9 1.8 0.3 1.7 2 1.7

T2 Electronics 1.4 1.3 1.7 0.1 1.2 1.4

T2 Signal Engineers 1.2 1.1 2 1.2 0 1.5

T2 Motor 1.3 1.5 1.7 1.4 1.5 0.2

Coordination Distance is a Measure of

Team To Team Coordination

Ability

26

0.0: Within small teams with shared tacit knowledge, distance approaches “0”

1.0: Between teams with average shared work background, common native language, and co-location, distance is a nominal “1”

Coordination Distance is both a macro-level and micro-level measure


Global Factors which influence Coordination Distance

Slide 27

Communication efficiencySome parties working in 2nd languageLess shared work backgroundTeam Size & CapacityPriority of attention to interaction vs. direct work

Distribution & time zonesOverlap of work hoursLatency/ reaction to issuesTravels costs and time

Exception handling behaviorLocal work culture & assumptions differ, distractQuality priorities, re-work capacity and attentionHigh chance of misreading indicators


Sum of Remaining Team_From

Team_To GAC Design

T1 Supplier

T2 Plastics_Team

T2 Electronics

T2 Signal Engineers

T2 Motor

GAC Design 456

T1 Supplier 968 668 93 168 168 128

T2 Plastics_Team 320

T2 Electronics 549

T2 Signal Engineers 576

T2 Motor 800

Team_Name GAC Design

T1 Supplier

T2 Plastics_Team

T2 Electronics

T2 Signal Engineers

T2 Motor

GAC Design 0.5 1.1 1.8 1.4 1.2 1.3

T1 Supplier 1.1 0.2 1.7 1.3 1.1 1.5

T2 Plastics_Team 1.9 1.8 0.3 1.7 2 1.7

T2 Electronics 1.4 1.3 1.7 0.1 1.2 1.4

T2 Signal Engineers 1.2 1.1 2 1.2 0 1.5

T2 Motor 1.3 1.5 1.7 1.4 1.5 0.2


Coordination Coordination ActivityActivity

Coordination = Dependence X

Distance

28(Moser 1997)

Coordination Dependency Matrix Coordination Distance Matrix


Sum of Coordination Cost %

GAC Design

T1 Supplier

T2 Plastics_Team

T2 Electronics

T2 Signal Engineers

T2 Motor

GAC Design 5% 0% 0% 0% 0% 0%

T1 Supplier 23% 3% 4% 5% 4% 4%

T2 Plastics_Team 13% 0% 0% 0% 0% 0%

T2 Electronics 0% 0% 0% 1% 0% 0%

T2 Signal Engineers 0% 0% 0% 15% 0% 0%

T2 Motor 23% 0% 0% 0% 0% 0%

Distribution of Coordination Activity across

Teams

29

Team to team coordination activity

Changes phase to phase

Sum of Coordination Cost % Phase_From Team_From1. Design Phase

2. Prototype Phase

3. Assembly Phase

Phase_To Team_To GAC Design

T1 Supplier

T2 Electronics

T2 Plastics_Team

T2 Electronics

T2 Signal Engineers

T2 Motor

T1 Supplier

1. Design Phase

GAC Design 5% 0% 0% 0% 0% 0% 0% 0%

T1 Supplier 23% 0% 0% 0% 0% 0% 0% 0%

T2 Electronics 0% 0% 1% 0% 0% 0% 0% 0%

2. Prototype Phase T2 Plastics_Team 13% 0% 0% 0% 0% 0% 0% 0%

T2 Signal Engineers 0% 0% 8% 0% 8% 0% 0% 0%

T2 Motor 23% 0% 0% 0% 0% 0% 0% 0%

T2 Electronics 0% 0% 0% 0% 0% 0% 0% 0%

3. Assembly Phase T1 Supplier 0% 1% 0% 4% 5% 4% 4% 2%


Coordination Distance

Summary

If work is complex, teams large, and dependence stretches across distant teams, coordination activity tends to increase

Simulator handles dependence and distance interaction on a micro, transactional level.

Distances at a transactional level create local direct costs and increased duration

The architecture determines if local coordination causes systemic and propagating impacts

Systemically, what happens if coordination activity is not budgeted and prioritized?

Slide 30


3. Case Study:Product Development across 4 Global Regions

Retrospective Analysis

Slide 31


Case Description New product family of complex machinery for multiple regional markets

Approximately 150,000 hrs of effort for design & development. 5 Gateways.

85% of scope was visible before G2. 54% from original product family scope

31% for options, not addressed until after G2.

15% from scope increase at G3.

32

Gateways

G0 – start G1 – conceptG2 – design G3 – engineerG4 – manufactureG5 – release Original Scope

Original Scope & Options

Original Scope, Options, & Scope Increase


Scenarios: Original, Options, & Scope Increase

A retrospective analysis: starting condition data used to ask

“What could we have known ahead of time?”

Three Scenarios were modeled; each simulated using

critical path (CPM) & global factors (GPD) settings.

CPM refers to the Critical Path Method for scheduling as

used in traditional project tools. CPM ignores

communication, time zones, mutual dependence, re‐work,

and other global factors.

GPD refers to analysis by GPD's TeamPort which

incorporates communication, complex concurrency, re‐

work, time‐zones and other factors.

33

Original Scope



Original Scope



Comparison of Forecasts: Schedule Gateways

Gateways

G0 – start G1 – conceptG2 – design G3 – engineerG4 – manufactureG5 – release

Slide 34Global Project Design ©

2009www.gpdesign.com NASA Challenge 2009

Comparison of Forecasts: Cost x 4th Gateway

35

@ G1

@ G2

@ G3

@ G4

Actual

PM PM forecasts by project team at each Gate during project.

CPMCPM forecasts (critical path) ignore coordination, concurrency, and re-work realities.

GPDGPD forecasts consider coordination, concurrency, re-work, time-zones and other global project realities

CPMCPM & GPDGPD forecasts generated by TeamPort

PMPM

CPMCPM

GPD GPD

Gateways

G0 – start G1 – conceptG2 – design G3 – engineerG4 – manufacture

Original Scope



Global Project Design ©2009

www.gpdesign.com


Conclusion

Teams in global projects can succeed through collaborative design of plans, simulating progress including coordination, exposing

assumptions, and generating situational awareness.

Slide 36


The Results of Project Design

Slide 37

Project design generates a plan. And options. The plan represents teams’ consensus of role, feasibility, optimality, and coordination approach.

The plan is a social instrument; a dialogue amongst teams, not just a control instrument. Teams interact from their own point of view.

Failure is visual before starting; allows team leaders to re-think how to participate. Architecture and complex dependence emphasized.

The exercise exposes ideological assumptions and prevents wishful thinking. Teams see sensitivity of total project results to their own actions.

Situational awareness and performance emerge as teams understand, commit, rehearse, and adapt ongoing with the plan.

moser.bryan

Technology

project complexity

limited uncertainty

rework slide

costsandsche slide

wbspbs slide

conclusion slide

rework travel

feasible plans