Moser.bryan

Rapid, Collaborative Planning
for Global Teams
through Project Design

Bryan R. Moser
bryan@gpdesign.com

NASA Challenge 2009
February 24-25, 2009

Slide 1

Global Project Design © 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

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

1. The Challenge of Global Projects

NASA Challenge 2009

Slide 3


Challenges of Teams from different time zones, work cultures,
Global Projects 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: Ways of Working
An Industrial Standard Work
Age Narrow specialties
Expert management
Automated resources

Communication, Uncertainty,
& Adaptive Behavior
are Avoided
Slide 5


The Missing Half of Plans is
Century old Coordination
assumptions
strongly
embedded

False precision of
detail becomes
substitute for
awareness &
adaptive learning The Gantt Chart Circa 1914

Not included in century old methods:
Complex Dependence amongst activities
Communication & Meetings
Decisions, Exceptions, and Re-work
Travel, Time Zones, and Workdays
Slide 6 Reasons for Waiting related to others


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

NASA Challenge 2009

Slide 7


Planning and
Designing Are
Very Different
Plan Design
Verb. To work out in
Verb. To create the form or
some detail how
structure of something in a
something is to be done or
skillful or artistic way.
organized.

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

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

Slide 8


Cost
(M$)
Project Design:
24
Pre-Launch
Multiple Forecasts
Forecasts are 1. Project Model
Business
& Simulation
prototype 21
Result
Typical
“crashes” of real Option 1
project Likely Result
Trade-off
Trade-
for time with As-Is Behavior
18 Optimized
Plan
Feasible & Focused
15 for Targeted Scope 2. Design Iteration
& Optimization
Business
Target
Hoped For
12
Option 2 3. Trade-Off Dialogue
Trade-off
Trade- on Feasible Plans
for cost

18 24 28 32 36 38
Slide 9
Duration (months)


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


Project Design
DESIGNER
Visual models to capture project & complexity
• Top-down & linked to strategy
• Product, work, & teams
• Global roles & priorities
• Concurrent dependencies

Smart Dialogue & Team Collaboration SIMULATOR
Unique insight from predictive analytics
• Analyzes coordination effort & costs
• Real-world behavior & uncertainty
• Constraints of team distribution
• Detailed output from hi-level input

FORECAST
Review of realistic plans, scenarios & options
•Product & phase schedules
•Team progress, efforts, costs
•Concurrency, wait, & re-work
Slide 13
• opportunities & risk 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

Drawings
Drawings

Documents
Documents

Modules
Modules

Tests
Tests

Parts
Parts

Progress in
Progress in
Percent of Effort
Percent of Effort Real World Units,
Real World Units,
Slide 17 Shown with range of standard
Shown with range of standard not just
not just
deviation and high/low of forecasts
deviation and high/low of forecasts Spending & Percent
Spending & Percent


Frequent Raw FTE Wait Coord Go‐Live Cost
Model # hrs Forecast Effort hrs % % date $ Description Realistic?
Iterations 114 4704 6891 8% 11% 12/24/07 $                    258,692 Added meeting to first modeling approach no

& What If 131
138
4704
4600
6838
5735
7%
1%
23%
9%
12/12/07 $                    257,368 Execute Commit not hard gateway
02/19/08 $                    287,472 simple assignments no mutual deps
no
no

Scenarios 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

50 or more plans 147
148
4600
4600
7439
7753
12%
14%
18%
15%
12/24/07 $                    293,500 Blended assignments & PMs as Decide
12/20/07 $                    264,988 All Arcana efforts priced at 0
almost (but cost)
yes

for a complex 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
project in days

Slide 18


Estimation of
Coordination Activity

How can we estimate coordination?

Slide 19


Dependence an Team 1 Team 2
architectural
measure of need
Can we predict the amount of coordination effort
required to effectively complete our direct work?

Dependence

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

DEMAND
Slide 20 for coordination


A B C
E A C D B G F
Dependence A X X
E X

Design Structure B X A X X

Matrix (DSM) C X X X X
C X X X
D X X

B X X X
Task Dependency in Matrix Form
Goal is to sequence and partition G X X X X

Some tasks are too tightly linked F X X X
D. Steward, 1981

A B C Level of Dependence
Level of Dependence
To Partition Tightly Coupled A A • • • Small
Tasks B
• B • Medium
McCord, Eppinger, Aug 1993 C •
• C
• Large

A B C
Time Duration & Probability
A 4 .2
To Predict Total Duration
Slide 21 Work Transformation Matrix B .4 7 .5

Smith, Eppinger, Apr 1994 C .3 .1 6


Aircraft Global upstream activity
Part6 Part1 Part16 Part5
Development s
Project p m r m r m r m r
e I f v I f v I f v I f v
c F g w F g w F g w F g w
4 major Part6 IF
spec
d fs 6ri 5ri fs
subsystems with o a Part6 mfg co 3r time-based
Part6 rvw co (finish to start)
13 Key activities w c Part1 IF fs 2r 2r co
and Dependence n t Part1 mfg 3r co continuous flow
s i Part1 rvw co (parallel)
t v Part16 IF fs 4i
Part16 mfg co other
r i
Part16 rvw co (information...)
e t Part5 IF fs
a y Part5 mfg 4ri 1ri 5ri 5r co
m Part5 rvw co
release co co co co

1ri early some results&info
2r early most results 5r parallel half results
3r early all results 5ri parallel half info & results
4i early/para, some info 6ri late most info & results
4ri early/para some results&info

Slide 22


Sum of Remaining Activity_From

n to
sig ign ro
De ign ign es n sP oto ot o ip
ic es es _D sig nic Pr ro
to
Pr Sh
on rd lD kg De tro P al
ctr to na &P ell lec tor ell n st
&
Activity_To Ele Mo Sig A Sh E Mo Sh Sig Te

Electronic Design 288
Dependencies by Activity
For coordination Motor Design 168
(DSM) mapped to
Team structure Signal Design 93
Dependence across Teams
matters A &Pkg_Design 968

Sum of Remaining Team_From
Shell Design 288

Architecture e rs
Electronics Proto 168
m ine
ea
determines if es
ign
up
pli
er
sti
cs
_T
ctr
on
ics
na
l E ng
oto
r
Motor Proto 800
CD S Pla Ele Sig M
GA
dependence Shell Proto
Team_To

320
T1 T2 T2 T2 T2

stretches across Signal Proto
GAC Design
288 288
456

teams Test & Ship 288 168 128 93 168 380

T1 Supplier 968 668 93 168 168 128

T2 Plastics_Team 320

T2 Electronics 549

T2 Signal Engineers 576

23 T2 Motor 800


Why dependence Coordination is interaction across the architecture
is not enough 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 Team 1 Team 2
Distance is the
Supply Side
Can we predict the amount of coordination effort
required to effectively complete our direct work?

Dependence Distance

What does my team What is my team’s
need in the progress & ability to coordinate
results from others? with others?

DEMAND SUPPLY
Slide 25 for coordination of coordination


0.0: Within small teams with shared tacit knowledge, distance
Coordination approaches “0”
Distance is a
Measure of 1.0: Between teams with average shared work background,
common native language, and co-location, distance is a
Team To Team
nominal “1”
Coordination
Ability Coordination Distance is both a macro-level and micro-level
measure
e rs
a m ine
Te nic
s ng
sig
n er s_ lE
pli tic tro na r
De up s c oto
C 1S Pla Ele Sig 2M
Team_Name GA T T2 T2 T2 T

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

26
T2 Motor 1.3 1.5 1.7 1.4 1.5 0.2


Global Factors
which influence
Communication efficiency
Some parties working in 2nd language
Coordination
Less shared work background
Distance
Team Size & Capacity
Priority of attention to interaction vs. direct work

Distribution & time zones
Overlap of work hours
Latency/ reaction to issues
Travels costs and time

Exception handling behavior
Local work culture & assumptions differ, distract
Quality priorities, re-work capacity and attention
High chance of misreading indicators
Slide 27


Team 1 Team 2
Coordination =
Dependence X
Distance Coordination Dependency Matrix Coordination Distance Matrix
Sum of Remaining Team_From

ers ers
ea
m ine am ine
_T ics ng Te ics ng
n er cs on lE sig
n r s_ on lE
sig pli sti ctr na tor pp
lie tic ctr na tor
De up De s
C 1S Pla Ele Sig Mo C Su Pla Ele Sig Mo
Team_To GA T T2 T2 T2 T2 Team_Name GA T1 T2 T2 T2 T2

GAC Design 456 GAC Design 0.5 1.1 1.8 1.4 1.2 1.3

T1 Supplier 968 668 93 168 168 128 T1 Supplier 1.1 0.2 1.7 1.3 1.1 1.5

T2 Plastics_Team 320 T2 Plastics_Team 1.9 1.8 0.3 1.7 2 1.7

T2 Electronics 549 T2 Electronics 1.4 1.3 1.7 0.1 1.2 1.4

T2 Signal Engineers 576 T2 Signal Engineers 1.2 1.1 2 1.2 0 1.5

T2 Motor 800 T2 Motor 1.3 1.5 1.7 1.4 1.5 0.2

Coordination
28 Activity (Moser 1997)


Sum of Coordination Cost %

rs
am ee
Te s gin Team to team
n r s_ nic lE
n
sig lie tic tro na r
De pp oto
Distribution of G AC T 1 Su
T 2P
las
T2
Elec
T 2 Sig
T 2M coordination
activity
Coordination GAC Design 5% 0% 0% 0% 0% 0%

Activity across Changes phase
to phase
Teams T1 Supplier 23%
Sum of Coordination Cost %
3% 4% 5%
Phase_From Team_From
4% 4%
1. Design 2. Prototype 3. Assembly
Phase Phase Phase

ers
am ine
T2 Plastics_Team 13% 0% 0% n 0% r 0% ic s 0% s_Te nic
s ng r
sig lie on c o lE pli
e
De pp le ctr sti ctr na tor up
C 1S
u
2E Pla Ele Sig Mo 1S
Phase_To Team_To GA T T T2 T2 T2 T2 T

1.
GAC Design 5% 0% 0% 0% 0% 0% 0% 0%
Design Phase
T2 Electronics 0% 0% 0% 1% 0% 0%

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

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

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

T2 Motor 23% 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%

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


Coordination If work is complex, teams large, and dependence
Distance stretches across distant teams, coordination
Summary
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.

Gateways 85% of scope was visible before G2.
54% from original product family scope
G0 – start
G1 – concept 31% for options, not addressed until after G2.
G2 – design 15% from scope increase at G3.
G3 – engineer
G4 – manufacture
G5 – release Original Scope

Original Scope &
Options

Original Scope,
Options, & Scope
32 Increase


Scenarios: A retrospective analysis:  starting condition data used to ask
Original, Options, “What could we have known ahead of time?”
& Scope Increase
Three Scenarios were modeled;  each simulated using
critical path (CPM) & global factors (GPD) settings.

Original Scope CPM refers to the Critical Path Method for scheduling as
Original Scope & used in traditional project tools.  CPM ignores
Options
communication, time zones, mutual dependence, re‐work,
Original Scope,
Options, & Scope and other global factors.
Increase

GPD refers to analysis by GPD's TeamPort which
incorporates communication, complex concurrency, re‐
work, time‐zones and other factors.

33


Comparison of Forecasts: Schedule Gateways
Original Scope

Original Scope &
Options

Original Scope,
Options, & Scope
Increase

Gateways

G0 – start
G1 – concept
G2 – design
G3 – engineer
G4 – manufacture
G5 – release

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

Comparison of Forecasts: Cost x 4th Gateway
Original Scope

Original Scope &
Options

Actual
Original Scope,
Options, & Scope
Increase
@ G4 GPD

PM Gateways
@ G3

@ G2
G0 – start
CPM G1 – concept
@ G1
G2 – design
G3 – engineer
G4 – manufacture
PM forecasts by project team at each Gate during project.

CPM forecasts (critical path) ignore coordination, concurrency,
and re-work realities.
GPD forecasts consider coordination, concurrency, re-work,
time-zones and other global project realities
35

Global Project Design ©
CPM & GPD forecasts generated by TeamPort 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 generates a plan. And options. The plan
Project Design 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
Slide 37 ongoing with the plan.


Moser.bryan

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Moser.bryan

Similaire à Moser.bryan (20)

Plus de NASAPMC

Plus de NASAPMC (20)

Dernier

Dernier (20)

Moser.bryan