bryan.moser

34
Cross-Center Systems Development: Coordination Architectures and Practices Presented at: NASA PM 2010 William Grossmann Bryan Moser National Institute of Aerospace Used with Permission

Upload: nasapmc

Post on 28-May-2015

13.880 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Bryan.moser

Cross-Center Systems Development: Coordination Architectures and Practices

Presented at: NASA PM 2010William Grossmann

Bryan MoserNational Institute of Aerospace

Used with Permission

Page 2: Bryan.moser

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

Page 3: Bryan.moser

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.

Page 4: Bryan.moser

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

Page 5: Bryan.moser

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

Page 6: Bryan.moser

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)

Page 7: Bryan.moser

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)

Page 8: Bryan.moser

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.

Page 9: Bryan.moser

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)

Page 10: Bryan.moser

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.

Page 11: Bryan.moser

Benefits of Project Design

• Architectural Judgement for Teams

• Forecast Accuracy through Converging Iteration

• Integration into Information Architecture & Practices

Page 12: Bryan.moser

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

Page 13: Bryan.moser

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

Page 14: Bryan.moser

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.

Page 15: Bryan.moser

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.

Page 16: Bryan.moser

• 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

Page 17: Bryan.moser

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

Page 18: Bryan.moser

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

Page 19: Bryan.moser

Coordination is Real Effort and Impact on Schedule Clearly Visible

19

Team Effort Forecasts

Page 20: Bryan.moser

Visual, Collaborative Design: Demonstration

• Movie here

Page 21: Bryan.moser

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.

Page 22: Bryan.moser

OperationalStates

As DesignedProduct Structure

Master ProductionSchedule

Information Architecture: Lifecycle Model

As-Maintained As-Built

Iterated Project Design Product/Organizational

StructureFunctions

System Specifications

Page 23: Bryan.moser

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

Page 24: Bryan.moser

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.

Page 25: Bryan.moser

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

Page 26: Bryan.moser

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.

Page 27: Bryan.moser

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

Page 28: Bryan.moser

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

Page 29: Bryan.moser

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

Page 30: Bryan.moser

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

Page 31: Bryan.moser

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

Page 32: Bryan.moser

CONCLUSION

Page 33: Bryan.moser

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

Page 34: Bryan.moser

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