ESD.36J System & Project Management · ESD.36J System & Project Management ... Reducing Project...
-
Upload
trannguyet -
Category
Documents
-
view
221 -
download
2
Transcript of ESD.36J System & Project Management · ESD.36J System & Project Management ... Reducing Project...
+
-
ESD.36J System & Project Management
Dynamics of Project Performance
System Dynamics and Project Management
Lecture #19, SD Class 7 & 8? (11/6/00)
Copyright © 2003 James M. Lyneis
+
-Typical project dynamics ...
Project Staffing
Typical Plan
... Result in schedule &/or budget overrun
TimeCopyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 2
+
-What can we do to avoid/minimize in ...
� … project preparation (design) √
� … project planning √ – except overlap/concurrency
� … risk management � … change management � … execution and adaptation
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 3
+
-
Strategic Process & Organization Issues
� Waterfall vs. spiral vs. adaptive vs. …? � Autonomous (dedicated) integrated product
team vs. functional? � System vs. modules? � How much phase overlap and concurrency? � How much to subcontract, make vs. buy?
How do we assess what is right for our project?
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 4
+
-
What are the pros and cons of above alternatives in the context of the model framework?
� Direct impacts of alternatives (one-off vs. dynamic) -� Scope
� productivity
� quality
� rework discovery
� strength of productivity and quality effects
� ...� Secondary impacts (assessed via simulation)
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 5
+
-How do we know these values?
� First time, you don’t ==> make educated guesses. Remember -� Better than mental models alone � Can do sensitivities – e.g., how bad would
the scope increase have to be before Spiral was not helpful for this type of project
� Once project finishes, can get a good estimate of the impact for use in future planning
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 6
+
-
General Conclusions re. Process and Teaming
� An iterative development process and/or integratedproduct team can improve performance if projectconditions would otherwise cause significantundiscovered rework
� The benefits of these approaches increase with theuncertainty (risk) in the development, i.e., the amountof potential rework
� Cautions -- alternatives may … � … not help for truly “exogenous” changes � … involve additional scope, or � … involve short-term implementation costs (for new
processes/tools/structures) which may negate the benefits of the alternatives
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 7
Topics+
-
• Planning – A look at issues in overlap and concurrency
• A System Dynamics View of Risk Management
• A Systems Dynamics View of Change Management and Dispute Resolution
• A System Dynamics View of Execution and Adaptation
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 8
+
-
Strategic Process & Organization Issues
� Waterfall vs. spiral vs. adaptive vs. …? � Autonomous (dedicated) integrated
product team vs. functional?� System vs. modules?� How much phase overlap and
concurrency? � How much to subcontract, make vs. buy?
How do we assess what is right for ourproject?
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 9
+
-Reducing Project Duration, The Plan ...
Traditional project
Overlap phases
Compress each phase
Planned Duration
Phase 1
Phase 1
Phase 2
Phase 2
Phase 1
Phase 2
Copyright © 2003 - ESD.36J SPM James M. Lyneis
+
-
Phase Overlap & Concurrency: More Overlap ...
Pros Cons
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 11
+
-
Phase Overlap & Concurrency: More Overlap ...
Pros
� Speed development by starting downstream phases before upstream finished � ... �
Cons � Requires more resources at peak overlap � Executing downstream work before upstream is ready reduces productivity � Executing downstream work with partial or incorrect information creates potential quality problems � ….
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 12
Ph
+
-Reducing Project Duration, The Pitfalls ...
Traditional Projects Rarely Meet Plan Because of Rework
Traditional project
Overlap phases
Compress each phase
ase 2
Planned Duration Actual
Phase 1
Phase 1
Phase 2
Phase 1
Phase 2
Rework Rework
Copyright © 2003- ESD.36J SPM James M. Lyneis
n Actual
Phase 2 ReworkRework
+
-Reducing Project Duration, The Pitfalls ...
And simply overlapping phases often creates more rework because
Traditional project
Overlap phases
Compress each phase
Planned Duratioincompleteness and undiscovered errors in upstream work cause errors in downstream work.
Phase 1
Phase 1
Phase 2
Phase 1
Phase 2 More Rework?
Rework
Copyright © 2003 - ESD.36J SPM James M. Lyneis
+
-Alternatively -- Reduce Unplanned Rework!
- ESD.36J SPM James M. Lyneis
Ph
Compress each phase
Reduce Rework
ase 2
Planned Duration Actual
Phase 1
Phase 1
Phase 2
Rework Phase 1
Phase 2
Phase 2 Phase 1
Rework
More Rework?
More Rework?
More Rework?
Rework
Rework Rework
Copyright © 2003
Traditional project
Overlap phases
+
-
This is not to say that overlap or compression, if carefully planned, cannot be done …
� DSM, ICE approaches as methods for effectively planning concurrency/overlap?
� Critical chain approaches to remove padding?
� … other thoughts?
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 17
+
-
Note that staffing strategies, concurrency, and process (iteration) models are interrelated ...
Adapted from: Smith, Preston G. and Reinersten, Donald G., Developing Products in Half the Time, 2nd Edition, John Wiley & Sons, 1998.
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 18
Conventional staffing practices force development efforts into phases that become dominated by specific functions.
Product Concept
Time
Staffing Level
Product Introduction
MARKETING
ENGINEERING
MANUFACTURING
+
- require a more level staffing … as iteration, teaming, and/or concurrency
Adapted from: Smith, Preston G. and Reinersten, Donald G., Developing Products in Half the Time, 2nd Edition, John Wiley & Sons, 1998.
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 19
Dedicated staffing forces overlapping and cross-functional interaction.
Product Concept
Staffing Level
Product Introduction
MANUFACTURING
ENGINEERING
MARKETING
Time
+
-Conclusions re. Phase Overlap
� Quality as well as “availability” is critical indetermining the readiness of starting downstreamwork phases
� In many cases, it may be better to devote staff tofinding and fixing errors than starting downstreamphases
� If downstream progress is necessary to discoveryupstream rework, careful planning and monitoring areneeded to minimize the adverse consequences ofprogressing downstream with low quality upstreaminformation
continued ...
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 20
+
-
Conclusions re. Phase Overlap (cont.)
� Increased phase overlap requires greater upstream and downstream communication to facilitate starting downstream work with partial information, and avoiding/finding upstream rework ==> teams that may lower productivity, but increase quality and reduce rework discovery time
� … � ...
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 21
+
-Topics
• Planning – A look at issues in overlap and concurrency
• A System Dynamics View of Risk Management
• A Systems Dynamics View of Change Management and Dispute Resolution
• A System Dynamics View of Execution and Adaptation
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 22
+
-
Decomposition of Risk Management (from Professor Warmkessel)
Risk Identification
Risk Assessment
Risk Mitigation
Risk Tracking & Handling
Risk Management
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 23
+
- For Certain Risks, SD Can Help …
Risk Identification
Risk Assessment
Risk Mitigation
Risk Tracking & Handling
Risk Management
Identify Risks & Quantify Range of
- ESD.36J SPM 9/23/03
Direct Impacts Copyright © 2003 James M. Lyneis 24
+
- For Certain Risks, SD Can Help …
Risk Identification
Risk Assessment
Risk Mitigation
Risk Tracking & Handling
Risk Management
Identify Risks & Assess Total Quantify Range of Impact of Risks Direct Impacts Alone & In
Combination Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 25
+
- For Certain Risks, SD Can Help …
Risk Identification
Risk Assessment
Risk Mitigation
Risk Tracking & Handling
Risk Management
Design EffectiveIdentify Risks & Assess Total Mitigation,Quantify Range of Impact of Risks Including WhatDirect Impacts Alone & In
Combination To Monitor Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 26
+
-Examples of Risks
� Technology – E.g., uncertain technology, technology leap
� Functionality – E.g., uncertain customer requirements
� Programmatic -� Availability and quality of information from
others (suppliers, other projects, platforms) � Availability of staff or other resources
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 27
+
- For Certain Risks, SD Can Help …
Risk Identification
Risk Assessment
Risk Mitigation
Risk Tracking & Handling
Risk Management
Design EffectiveIdentify Risks & Assess Total Mitigation,Quantify Range of Impact of Risks Including What ToDirect Impacts Alone & In
Combination Monitor Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 28
- ESD.36J SPM9/23/03 29
+
-
Copyright © 2003James M. Lyneis
Risk Identification and Quantification --Learning from Prior Projects
Model prior project(s)Quantify all deviations to project vis a vis original plan and input as time series or parametric changes
Estimate direct impactsFine tune quantification via calibration to actual data
Add to “data base” of sources and magnitude of changes to original plans
+
-Specify “Direct Impacts” In Terms Of ...
� Changes in scope � Changes in quality � Effects on productivity and quality � Effects on staffing � ….
… via changes to normal parametersor via time series inputs
Indirect and total impacts aredetermined by the model
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 30
+
- Development Example – Automotive
Based on a simulation model, major sources of risk ranked interms of impact on schedule and delivered quality(Analysis of 11 projects):
1. Late information and/or changes 2. Resource availability
� Slow ramp up, lower peak, forced ramp down to meet budget � Inadequate skills mix
3. New processes, missing enablers, or new materials 4. Organization &/or geographic changes 5. Aggressive program assumptions
� Compressed timing, inadequate budget, lean allowance for prototypes
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 31
+
- For Certain Risks, SD Can Help …
Risk Identification
Risk Assessment
Risk Mitigation
Risk Tracking & Handling
Risk Management
Design EffectiveIdentify Risks & Assess Total Mitigation,Quantify Range of Impact of Risks Including What ToDirect Impacts Alone & In
Combination Monitor Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 32
+
-Risk Assessment
� Set up model to represent plan (if possible)
� Using prior project data base, determine possible risks and range of impact
� Test individually and in combination
The numbers may not be accurate, but the thought process coupled with sensitivity analysis improves risk
management. Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 33
+
-
For Example: The “Class6” Base Case
Experience on prior projects indicates significant risk of late rework with the clarification of customer needs:
� Uncertain customer requirements cause quality problems early in the project� normal quality = .95
� all other parameters as in Homework1 Model� Assume waterfall model with functional
organization structure
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 34
+
-
The Base Case Overruns ...Graph for Staff Level
20
15
10
5
0
C
C
om
ost: 26
pletion:
3 Perso
Month
n-m
38.
onths
875 (30
(115
planned)
plan)
Plan
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 Time (Month)
Staff Level : Class6 Waterfall People Staff Level : Class6 Plan People
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 35
+
- For Certain Risks, SD Can Help …
Risk Identification
Risk Assessment
Risk Mitigation
Risk Tracking & Handling
Risk Management
Design EffectiveIdentify Risks & Assess Total Mitigation,Quantify Range of Impact of Risks Including WhatDirect Impacts Alone & In
Combination To Monitor Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 36
+
-Risk Mitigation
� Determine possible methods of mitigation for risks likely to impact this project
� Assess cost-benefit, including indirect impacts via reduced productivity and increased rework
� Implement up front, or monitor and implement pre-defined action plan
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 37
+
-
For Example, Mitigating Risk From Uncertain Customer Requirements: Strategic Process & Organization Issues
� Waterfall vs. spiral vs. adaptive vs. …?
� Autonomous (dedicated) integrated product team vs. functional?
� System vs. modules? � How much phase overlap and
concurrency?
� [How much to subcontract, make vs. buy?]
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 38
+
-
Automotive Development: Risk Mitigation Actions
� “Disciplined” Product Development: � Contain workscope by maximizing reuse � Focus on quality rather than early milestones � Minimize late changes � Accelerate rework discovery
� Staffing: � Get planned resources on time (“fight”, external, …) � Minimize sustained overtime � Additional and accelerated training � Colocation
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 39
+
-
ESD.36J System & Project Management
A Case Example: The Peace Shield Air Defense System
Copyright © 2003 James M. Lyneis
+
-The Peace Shield Program
� Hughes (now part of Raytheon): A major US aerospace company that regularly develops large-scale air defense systems
� The problem: Frequent budget overruns resulted in lengthy claim disputes between Hughes and their customers; this contract was won competitively after being taken from another contractor in trouble
� System dynamics model was used for: � Bid support and risk assessment; � On-going project management � Post-project benchmarking and policy assessment
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 41
DownstreamProgress,Availability,& Quality Effects
Upstream ReworkDiscovery Effects
Support effects
+
-
SRS Code & Unit
Integration
Mgt. & Admin.
Op. & Main/
ILS
HW Installation
Software System
Program Management Office
Customer Hardware Subcontractors Other HASI Programs
CONUS
Project Phases Software Development
Development
Top Level & Detailed
Design Test & Type II
Test
Type I Test KOSA
& ICO Test Engineering Software Support
Logistics
Downstream Progress, Availability, & Quality Effects
Upstream Rework Discovery Effects
Support effects
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 42
+
-Bid Support and Risk Assessment
� Adapted model of prior CCSdevelopment
� Assessed risks associated with critical assumptions � amount of code from prior project that does
not require change and could be used as is(“liftability”)
� availability of experienced staff� vendor delays� …
� Estimated likely competitor bid Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 43
+
- and how much “undiscovered rework” in “Liftability” – How much “work really done”
the “lifted” code?
Quality
Progress
Rework
Productivity
Work To Be Done
Undiscovered Rework
Known Rework
Work Really Done
“Base Case”:
80%
Discovery 20%
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 44
+
-Man-Months
Liftability Most Critical and Uncertain ... Total Development Man-Months
6000
5000
4000
2000
2000
1000
0 Peace 100% of 60% of 40% of 20% of 0% of Shield lift usable lift usable lift usable lift usable lift usable Base as is as is as is as is as is
PMO
Software
System Engineering
Test
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 45
+
-Estimate Competitor Bid
� Competitor inexperience in this type of project likely to result in unrealistically low bid � Submit a low bid, but still profitable if
managed aggressively � Carefully define work scope assumptions � Aggressively manage program to control
costs, including early emphasis on rework discovery, use of experienced staff, and management of customer expectations
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 46
+
-Mitigation ...
� … concentrate early program efforts on flushing out as-yet-undiscovered rework in the lifted work, rather than steeply ramping up staff to accomplish new work
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 47
+
-
Project Planning: Based on Model Analyses, Adopt New Process and Organization …
� Implementation of a “teaming” structure and other improved processes (including worse before better impacts) � Upstream and downstream staff involved in design
and review for all phases � Customer participation in design reviews
� Implementation of a new staffing strategy for software engineering and coding � Delay start of downstream phase � Delay roll-off of staff from phase and assign to
rework discovery Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 48
+
-Peace Shield Was Very Successful ...
“In my 26 years in acquisition, this [Peace Shield Weapon System] is the most successful program I’ve
ever been involved with, and the leadership of the U.S. Air Force agrees.”
Darleen Druyun
Program Manager March-April 1996
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 49
+
-Post-project benchmarking ...
1800 Past Program
1600
1400
1200
1000
800
600Peace Shield
400
200
0 0
1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002
Peace Shield
Past Program
Cumulative Effort
Staff Levels
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 50
+
-What caused the differences between Peace Shield and Past Program?
z Differences in work scope?
z External Conditions?
z Management policies and processes?
And how can a company learn from these differences, and therefore
z Bid better?
z Plan better?
z Manage better?
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 51
+
-
The same model accurately replicated Peace Shield ...
0
Data and Plans in mid-1993
Simulated
1991 1992 1993 1994 1995
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 52
+
- policy & risk (external) changes only … and the Past Program with management
0
Simulated
Data
1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 53
+
-
Programs overlayed highlight difference ...
1800 Past Program
1600
1400
1200
1000
800
600Peace Shield
400
200
0 0
1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002
Peace Shield
Past Program
Cumulative Effort
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 54
+
-Major external differences
Peace Shield -� Lower scope and fewer changes � Fewer vendor delays & hardware
problems � Better hiring conditions (less delay)
(Some of these are sources of risk)
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 55
+
-
Removing external sources of difference from the past program ...
Cumulative Effort
Past Program
External Differences Removed
1800Past Program
1600
1400
1200
1000External Removed
800
600
400
200
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 56
+
-
Removing external sources of difference from the past program ...
Cumulative Effort
Past Program
External Differences Removed
Peace Shield Schedules
1800Past Program
1600
1400
1200
1000External Removed
800
600
400
200
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 57
+
-Management differences
Peace Shield -� Adopted teaming structure including
customer involvement in design reviews � Different staffing strategy by phase of
work
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 58
+
-
Delayed Roll-off of Staff and Later Start of Downstream Phases on Peace Shield
Start of S/W Coding
Past Peace C&C Shield
0% 10% 20% 30% 40%
S/W Design Complete
Program Year Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 59
+
-
Peace Shield: Reduce Overlap and Unplanned Rework!
Past Project: Overlap phases
Peace Shield: Reduce duration by reducing rework in upstream phases
Planned Duration Actual
Phase 1
Phase 2
Phase 2 Phase 1
More Rework?
Rework
Rework Rework
Copyright © 2003 - ESD.36J SPM James M. Lyneis
+
-Teaming, Delayed Roll-off of Staff, and Customer involvement in Design Reviews Contributed to Shorter Rework Discovery Times on Peace Shield
Rework Discovery Delay(Months)24
22
20
18
16
14
12
10
8 6 4 2 0
1 2 3 4 5 6 7 8 9 10 11
Past Program
Peace Shield
Program Year
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 61
+
-Removing management differences ...
Cumulative Effort
Peace Shield
Past Program
External Differences Removed
Peace Shield Schedules
1800Past Program
1600
1400
1200
1000
800
600Peace Shield
400
200
0 0
1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 62
+
-
Where Did The Cost Improvement Come From?
External Conditions 44%Policies & Processes 56%
Teaming & OtherImprovements
Better HiringConditions
3%
Fewer Vendor & Hardware Problems
Different Staffing Policies
More Experienced
Scope Differences & Fewer Customer Changes
19%
19%
People 24%
13%
22%
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 63
Topics+
-
• Planning – A look at issues in overlap and concurrency
• A System Dynamics View of Risk Management
• A Systems Dynamics View of Change Management and Dispute Resolution
• A System Dynamics View of Execution and Adaptation
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 64
+
-
What are differences between “changes” and “quality” problems?
� Changes represent truly unknowable,uncontrollable, exogenous impacts(often can be compensated for) � competitor introduces a new feature � ...
� “Quality” problems can be anticipatedand dealt with in the design andmanagement of the project � buffers, prototypes, process, ...
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 65
+
-
Changes can impact a project in a number of direct ways:
�Added work scope �Added hours, without changes in
“scope”�Work obsoleted�Work made uncertain because of
possible changes �Late/deficient information or equipment�Diversion of management time
How much, when, how long Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 66
+
-Estimating Impact & Mitigation
�What is the total cost and schedule impact of the change, if mitigatingactions are not taken?�What actions will reduce the extent of
the disruption -� Schedule relief? Slipping interim
milestones? � Additional budget? � Management actions (overtime, hiring, ...)? �Should the change be made, and how
should we be compensated (if possible)Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 68
+
- Graph for Work Done
100
75
50
25
0 0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60
Time (Month)
Work Done : Class7 Changes Task Work Done : Class7 Plan Task
9/23/03 - ESD.36J SPM Copyright © 2003 James M. Lyneis 69
+
-Graph for Staff Level
20
15
10
5
0 0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60
Time (Month)
Staff Level : Class7 Base People Staff Level : Class7 Changes 20-15 People
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 70
+
-
Impact Increases the Later the Change ...
Test
Plan
Changes, 20%@ Month 5
Changes, 20%@ Month 10
Changes, 20%@ Month 15
Finish Cost(person-mos)
30.5 119.33
31.625 143.25 (+20%)
32.2 152.35 (+28%)
32.875 161.73 (+36%) Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 71
+
-… and the Larger the Change
Test Finish Cost(person-mos)
Plan 30.5 119.33
Changes, 10%@ Month 15 31.69 138.35 (+16%, 1.6X)
Changes, 20%@ Month 15 32.875 161.73 (+36%, 1.8X)
Changes, 30%@ Month 15
34.1 186.6 (+56%, 1.9X)
9/23/03 - ESD.36J SPM Copyright © 2003 James M. Lyneis 72
+
-Cost impact can be mitigated ...
Graph for Staff Level20
15
10
5
0
Changes
Changes, SlipSchedule
Plan
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 Time (Month)
Staff Level : Class7 Changes People Staff Level : Class7 Plan People Staff Level : Class7 Changes Slip Schedule People
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 73
+
- Graph for Quality
1
0.9
0.8
0.7
0.6
Plan
Changes, pSliSchedule
Changes
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 Time (Month)
Quality : Class7 Changes Fraction Quality : Class7 Plan Fraction Quality : Class7 Changes Slip Schedule Fraction
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 74
+
-Change Scenarios
Test Finish Cost(person-mos)
Plan 30.5 119.33
Changes 32.875 161.73 (+36%)
Changes, Slip Schedule 34.2 139.78 (+17%)
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 75
+
-
ESD.36J System & Project Management
Delay and Disruption Disputes
Copyright © 2003James M. Lyneis
+
-Delay and disruption
Schedule and cost growth resulting from the effects of unplanned changes or unanticipated problems.
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 77
+
-
How SD in Project Management got started: Ingalls Shipbuilding vs. US Navy
� Ingalls Shipbuilding won contract for 9 LHA’s and30 DD963 destroyers in 1969 and 1970.
� Firm fixed price contract structure
� $500 million cost overrun on the programs (Ingallsand Navy agreed on $150 direct cost – the rest?)� Navy – bad management � Ingalls – D&D
� Ingalls sues Navy claiming design changescaused delay and disruption Source: Cooper, Kenneth G., 1980, Naval Ship Production: A Claim Settled
and a Framework Built. Interfaces. 10(6) (December), 20-36. Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 78
+
-
The big question: ‘How would the program have performed absent customer-responsible events & conditions?’
Customer-Responsible Events & Conditions Total Program Labor (Equiv. People)
Real Program
l i
l ion Time
ii
i
le
l
l
i i l
l
i
ll
Work Quality to Date
Scheduled Comp et on
Time
Expected Comp et Availabil ty
of Prerequis tes
Perce ved Progress
Schedule Pressure
Out-of-Sequence Work
Mora
Expected Hours at
Comp et
Hours Expended
to Date
Skill & Experience
Hiring
Equiva ent Staff on Project
Staffing Requested
Progress
Rework Discovery
Turnover Organ zat onaSize
Changes
Staff
Productivity Quality
Added Work Obso eted
Work
Overt me
Time Remaining
Work To Be Done
Undiscovered Rework
Known Rework
Work Rea y Done
As-Built Data
StartingProgram
Conditions ion
TIME
Company Actions
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 79
+
-One simple, extreme solution
The first thing we do,let’s kill all the lawyers …
William ShakespeareHenry VI, Part 2, IV. ii.
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 80
+
-
All changes from plan (both customer and company) are specified in terms of their direct impacts on the project:
�Added work scope �Added hours, without changes in “scope” �Work obsoleted �Work made uncertain because of possible
changes �Late/deficient information or equipment �Diversion of management time
How much, when, how long Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 81
+
-
Answering the big question is a three-step process
� Step 1: Use the program simulationmodel to re-create history with thecustomer-responsible events & conditionsincluded
� Step 2: Remove the customer-responsible events & conditions and re-simulate the program
� Step 3: Analyze the differences betweenthe two program simulations – they comprise and explain the total customer-responsible cost & schedule growth.
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 82
+
-
Step 1: Re-creating program history (including customer claim items)
Program Labor Total Fab, Assy, Inst'n Mgmt. & Support Design Flight Test
Equi
vale
nt P
eopl
e (h
undr
eds) Dash
are Aed linesircraft
Program data
TIME
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 83
+
-
Step 2: Remove customer claim items and resimulate
Customer-Responsible Events & Conditions Total Program Labor (Equiv. People)X
l i
l ion Time
ii
i
le
l
l
i i l
l
i
ll
Simulation Model
Work Quality to Date
Scheduled Comp et on
Time
Expected Comp et Availabil ty
of Prerequis tes
Perce ved Progress
Schedule Pressure
Out-of-Sequence Work
Mora
Expected Hours at
Comp et
Hours Expended
to Date
Skill & Experience
Hiring
Equiva ent Staff on Project
Staffing Requested
Progress
Rework Discovery
Turnover Organ zat onaSize
Changes
Staff
Productivity Quality
Added Work Obso eted
Work
Overt me
Time Remaining
Work To Be Done
Undiscovered Rework
Known Rework
Work Rea y Done
As-Built Data Absent Customer Items
Starting Program
Conditions ion
TIME
Company Actions
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 84
+
-
Step 3: The claim is the difference between the simulations...
Program Cumulative Labor Hours As Built Data Absent Customer Items
Labo
ur H
ours
(mill
ions
)
Budget hours
Cust.-driven labor growth
It would have needed...
Actual
87 88 89 90 91 92 93 94 95 96
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 85
+
-Actual vs. Would-Have for Ingalls
LHA Program StaffingAnnual Staffing (Person Years)
0
20
40
60
80
100
120
140
160
Actual History Would-Have Been
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 86
+
-
…which includes the added delay and disruption costs stemming from customer changes
Full Impact of
Unplanned Events &
Conditions: $447M
& Disruption from $300M
$147M
$53M
Direct Cost of
0
Cum
ulat
ive
Prog
ram
Cos
ts$M
illio
n
Original Budget
Start Date Scheduled
Actual History
Cost of Unanticipated Delay
Customer Changes
Customer Changes
Overruns caused by Ingalls
Actual End Date End Date
US Navy initially acknowledged only the direct costs their changes caused – a small portion of the total $500M budget overrun
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 87
+
-
Ingalls was even able to quantify specific sources of cost growth
% Impact on Cost Growth for the LHA Program
Reduced Drawing Inadequate Loss of Quality Skill Level Learning Out-of-Sequence Work
6% 3% 3% 29% Delayed/ReducedQuality of PriorConstruction
14%
Other Labor Impacts Excessive Schedule
22% Pressure 23%
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis
Source: Analysis of Delay and Disruption in the LHA and DD Programs, June 1978, table 5.5 (after p134).
+
-The Navy’s starting position
“If you think you’re going to get 10 cents from us with this black box hocus-pocus simulation model, you’re nuts.”
But after a review by MIT System Dynamics Professors …
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 89
+
-
How it all got started: Ingalls Shipbuilding vs. US Navy
� Case settled out of court for $447 million
� Model-generated analysis was the basisfor $200-300 million of the claim. Source: Cooper, Kenneth G., 1980, Naval Ship Production: A
Claim Settled and a Framework Built. Interfaces. 10(6) (December), 20-36.
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 90
+
-Since the beginning ...
� More than 30 contract disputes � In excess of $4 billion in dispute, with
average recovery of 75% vs. 40% withtraditional methods
� All disputes have settled out of court,avoiding lengthy litigation
� More than 75 proactive applications � In excess of $25 million in consulting
fees � Conservatively saved clients $5 billion
on cost and schedule performance Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 91
+
-
Why has system dynamics been so successful?
�Transparent and logical cause-effect structure � Facilitates discussion with adversaries � Focuses discussion on assumptions, rather than
outcomes �Highly validated model -
� Accurate re-creation of project history (essentialfor allocating costs to causes)
� Concurrence of project managers that structureand behavior are right
� Use of models for managing other projects � Reasonableness of behavior under a wide range
of conditions Copyright © 2003
9/23/03 - ESD.36J SPM James M. Lyneis 92
+
-
Why has system dynamics been so successful? (cont.)
�“What-if …” capability -� What “would-have” happened � Project future consequences � Demonstrate management reasonableness
and impact mitigation
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 93
+
-Topics
• Planning – A look at issues in overlap and concurrency
• A System Dynamics View of Risk Management
• A Systems Dynamics View of Change Management and Dispute Resolution
• A System Dynamics View of Execution and Adaptation
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 94
+
-
Selected Issues in Execution & Adaptation
� Managing Risks and Changes: � Schedule adjustments � Staffing strategies
A Strategic View – Deciding in advance the best way to handle problems if
they arise
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 95
+
-
In the face of a projected schedule overrun, is it better to slip as soon as you know it or wait and see if corrective actions will help?
Copyright © 20039/23/03 - ESD.36J SPM James M. Lyneis 96
+
- Graph for Staff Level 20
15
10
5
0
No Slip
Slip Early (and all along)
Slip Late
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 Time (Month)
Staff Level : Class7x Base People Staff Level : Class7x Slip Late People Staff Level : Class7x Slip Early People
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 97
+
-Graph for Cumulative Effort Expended
400
300
200
100
0
Slip Early (and all along)
No Slip
Slip Late
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 Time (Month)
Cumulative Effort Expended : Class7x Base Month*Person Cumulative Effort Expended : Class7x Slip Late Month*Person Cumulative Effort Expended : Class7x Slip Early Month*Person
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 98
+
-Conclusions
� If project priorities favor cost over schedule, it’s better to slip the schedule early rather than wait until the damage is done. [Note: if rework creation is high enough, not slipping early can make the project finish later!]
� Use buffers early.
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 99
+
-
ESD.36J System & Project Management
Staffing Strategies
Copyright © 2003James M. Lyneis
+
-Selected Staffing Issues
� Should staff be added to a late project (Homework 4 question)? � Unless new staff are 100% productive from
day 1, adding staff increases cost; � And, can make project later if the quality hit
is large enough � Should you start with the expected full
team, or staff up gradually?
Copyright © 2003 9/23/03 - ESD.36J SPM James M. Lyneis 101