Bryan.moser
-
Upload
nasapmc -
Category
Technology
-
view
13.881 -
download
0
Transcript of Bryan.moser
Cross-Center Systems Development: Coordination Architectures and Practices
Presented at: NASA PM 2010William Grossmann
Bryan MoserNational Institute of Aerospace
Used with Permission
Outline
• Introduction
• The State of Complex System Development
• Perfect Storm Leads to Decline in Judgement
• Visualization & Simulation across Subsystems
• Case Study
• Conclusions & Benefits for NASA
Introduction
Today's aerospace products are more complex while being developed by teams located across the globe.
The challenge is to optimally organize, direct, and manage these teams, their
interactions, dependencies, and priorities during the program.
The State of Complex Product Development
• Multiple layers of system and subsystem, with substantive design responsibility layers down
• Complex dependencies fall across subsystems owned by different teams
• Dispersed teams and supply chain with less chance of a shared, common background
• Pressure to proceed in a dramatically concurrent fashion, increasing risk of rework, poor quality, and delay
Perfect Storm Leading to Decline of Judgment
• Thinning of the work force
• Variation in work practices globally
• Dependencies across major subsystems
• Cost of coordination is high
Thinning of the work force
• reductions in projects combined with reductions in hiring changed the age - experience composition
• a decline in opportunities for design experience– highly qualified technical workers to consider field less desirable.
• engineers will work on fewer projects in their lifetimes– less experience across a broad spectrum of technologies
• gaps of years between development of new systems– specifically trained and experienced workers may be lost.
(National Research Council, 2001)
Variation in work practices globally• Technical: to think mathematically, Sound knowledge of basic
science, knowledge of a specific discipline, Maintenance of current knowledge and practice
• Personal: Ability and willingness to learn, Appreciation of limits to knowledge, Good communication skills, and international dimensions
• Professional: Commitment to high standards, of personal and ethical responsibilities, Ability to handle uncertainty, to communicate effectively, in more than one language including English
• Managerial: Ability to work in a team, Appreciation of management concepts and issues, Ability to lead and manage personal, financial and technical resources
(National Academy of Engineering 2004)
Impact of dependencies across subsystems
“Boeing has undertaken a grand business experiment with the Dreamliner. In a bid to tap the best talent and hold down costs, the aerospace icon has engaged in extreme outsourcing, leaving it highly dependent on a far-flung supply chain that includes 43 "top-tier" suppliers on three continents. It is the first time Boeing has ever outsourced the most critical areas of the plane, the wing and the fuselage. About 80% of the Dreamliner is being fabricated by outside suppliers, vs. 51% for existing Boeing planes...”
Holmes, S. (June 19, 2006)“The 787 Encounters Turbulence”, BusinessWeek.
Cost of coordination is high
• A 2004 NIST report claims– 40% of engineering spent locating and
validating information– 30% of costs wasted due to poor
communication between teams – leading to a loss of US$15.8 billion annually
• The cost of failing to provide effective coordination leads to serious project consequences, including significant schedule slip, cost overruns, and project cancellation
(National Institute of Science and Technology 2004)
OUR APPROACH
Visualization & Project Simulation across Subsystems Our approach uses a collaborative project design method for complex projects, including the activity of coordination across teams and subsystems. The method is powered by a simulation and visualization engine to gain shared situational awareness. Sustainable, visual tools allow teams to keep their focus on real progress, coordination overhead, and systemic product/system risk throughout.
Benefits of Project Design
• Architectural Judgement for Teams
• Forecast Accuracy through Converging Iteration
• Integration into Information Architecture & Practices
Judgement for Teams through Architectural Project Design
• The Past - activity of product development was sufficiently consistent over the career of an engineer that this architectural view became embedded in their professional judgement
• Now - the visualization and simulation becomes a learning centred planning exercise through collaborative modelling that stimulates and enhances judgement
• Result - promotes accelerated convergence on shared objectives and options for proceeding
Project Design Introduction
-- Basic R&D at MIT, U Tokyo, U Conn 1994-1999 –-- Applied in Industry since 2001 --
-- Platform for Program Strategy Dialogue ---- Collaborative Visual Design --
-- Forward-looking Forecasts and Analytics --
Rapid modeling & simulation of complex projects & portfolios
13September 2009
Collaborative Visual Model showing PBS & Mutual Dependence
• Shows the (PBS) Product Breakdown Structure and its relationship to the Activities
• Mutual and concurrent dependence can be captured, and impact simulated.
Visual Modelling from OBS Point of View
• Shows Organizational Relationship and Primary Responsibilityfor each Activity
• The multiple views of the same project stimulate real time dialogue and insights.
• An engaging experience for team leaders similar to: – practices for sports competition– field exercises in the military– rehearsals for performance
• Early mission studies don’t normally include feasibility from a PM point of view
• With Project design, program feasibility can be weighed as part of the overall mission strategy
Rapid, Iterative Forecasts Lead to Situational Awareness
Forecast Accuracy through Converging Iteration
• As a project design exercise proceeds, relevantelements in a model and forecasts of likely schedule, cost, and risks improve
• Teams are stimulated to understand when, where and why coordination occurs
• Understanding that lack of coordination will cause systemic, propagating delay, rework, and poor quality is critical
Forecasts include Work, Coordination and Wait Driven Low Utilisation
• Coordination activities across teams are least likely to be predicted based on previous judgement
Includes coordination effort, costs and schedule impact
Coordination is Real Effort and Impact on Schedule Clearly Visible
19
Team Effort Forecasts
Visual, Collaborative Design: Demonstration
• Movie here
INTEGRATION INTO INFORMATION ARCHITECTURE & PRACTICES
Our approach helps identify the most appropriate information architecture for a complex system, shows how the information architecture relates to product, process, and organizationalstructures and how they can persist and evolve. Further, our approach outlines how teams can forecast, budget and perform coordination activities using the information architecture.
OperationalStates
As DesignedProduct Structure
Master ProductionSchedule
Information Architecture: Lifecycle Model
As-Maintained As-Built
Iterated Project Design Product/Organizational
StructureFunctions
System Specifications
Growth of Information Through Project Activity
Info
rmat
ion
& L
earn
ing
0
100% Shuttle
Engines
controls wiring
- - - -
- - - -- - - -
Concept
Commis.
Field Testing
Assembly
ManufacturingDetailed Design
Engineering andBusiness Processes
Product/Project Information
Information Generation, Archiving and, Distribution
computer
Product, Project, OrganizationalInformation Structure
Operation,Maintenance,Training
Achieving Value via Interplay of Architectures
Information that spans products, teams, and generations. Sustainable, relevant, and evolving rather than a passive data dump. (~50 years+).
Systems and artifact structure and elements: as required, as designed, as built, as operated and maintained. Through retirement and generational re-use. (~30 years+).
Organization focus and activity tied to teams, budgets, deliverables, and schedule with finite start and completion (~10 years+).
Objective centered activity day to day, week to week across architectures (product, process, org). Guided by SE, PM, and embedded work culture standards.
Case Study
• Sikorsky S 92: an example of a six location, four continent partnership that includes all aspects of the aircraft, from marketing through service
Product Life Cycle as a Partnership based Activity (1992-)
ActivityIntegrator
ActivityDecomposed
marketingdesignengineeringproductiondeliveryservice
partnership
SikorskyUSA
MHIJapan
EmbraerBrazil
JingdezhenChina
GamesaSpain
Taiwan AerospaceTaiwan
+ designability
± activity quality± product quality
26
Six location, four continent partnership that includes all aspects of the aircraft,
from marketing through service.
Dependency by Subsystem Developer
p1 p2 p3 p4 p6 p9 p10 p11p5
p7
p8
p13
p14
p15
p16
p17
p18
p19
p20
p5 p7 p8 p13 p14 p15 p16 p17 p18 p19 p20
p1
p2
p3
p4
p6
p9
p10
p11
Dependency shown as number of interfaces shared by subsystems.
Partner Subsystems
Integrator Subsystems
27
Dependence across 4 key Subsystems
28
Dependence driven by system architecture, not just standard work processes. These drive demand for coordination (or
wait and rework) in unexpected ways.
Dependence as demand for interaction by teams.
Coordination is activity to satisfy the need for interaction.
Subsys6 Subsys1 Subsys16 Subsys5spec
IF
mfg
rvw
IF
mfg
rvw
IF
mfg
rvw
IF
mfg
rvw
specSubsys6 IF fs 6ri 5ri fsSubsys6 mfg co 3r time-basedSubsys6 rvw co (finish to start)Subsys1 IF fs 2r 2r coSubsys1 mfg 3r co continuous flow Subsys1 rvw co (parallel)Subsys16 IF fs 4iSubsys16 mfg co otherSubsys16 rvw co (information...)Subsys5 IF fsSubsys5 mfg 4ri 1ri 5ri 5r coSubsys5 rvw corelease 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
dow
nstr
eam
sys
tem
act
iviti
es
upstream system activities
Development Project Model & Simulation Results
• Product Architecture, Workflow, and Partnering (Org) Architectures had been selected separately.
• “Perfect Storm”: The combination of concurrency, time zones, and dispersed decision making of rework drove propagating quality issues.
• Traditional schedulers predicted 5 years to 1st prototype, these models predicted ~ 9 years. And showed where this delay would originate.
29September 2009
Actual Results: Changes by Subsystem
300
280
260
240
220
200
180
160
140
120
100
80
60
40
20
01000950900850800750700650600550500450400350
days
p1p2p3p4p5p6p7p8p9p10p11p12p13p14p15p16p17
3 subsystems spanning organization architecture drove most rework (as
predicted).
Duration to 1st prototype 4 years later than traditional
CPM schedules (as predicted).
A middle phase (Engineering) of the development project. Change propagating across systems was not predicted in the traditional schedule.
30
Complex Development: “How fast is too fast?”
Initial, complicating assumption• Partners should proceed as quickly as possible once specs available
Result• Unexpected communication & wait• Large amounts of re-work
Correction• forecast coordination and its impacts ahead of time
• allocate and manage coordination when and where most valuable• promote concurrency only when systemically beneficial
• change flow of relative progress = "slow-up", "speed down“31
CONCLUSION
Emphasis on Coordination Practices Integrated with Both SE and PM
Systems Engineering
Coordination Management
Project Management
Practices
Standards
Critical Opportunity for Improvement in Complex Dispersed Multi-System
Development
Key Benefits for NASA
• Accurate forecasts of feasible concurrency, subsystem integration, schedule and risks
• Coordination: value prediction and allocation, waste reduction, & ongoing adjustment
• Information Architecture: Sustainable & Integrated into Practices
• Situational Awareness across dispersed Centers & Suppliers