CS-104/18/23

104/18/23

Towards a Work Breakdown Structure

for Net Centric System of Systems Engineering and Management

20th International Forum on COCOCMOWorkshop

October 2005

Gan WangGan Wang gan.wang@baesystems.com Ricardo ValerdiRicardo Valerdi rvalerdi@mit.edu

Jo Ann LaneJo Ann Lane jolane@usc.edu Barry BoehmBarry Boehm boehm@cse.usc.edu

204/18/23

Outline

Background, motivation, goals and scope− Relevant needs and trends in SoS system engineering and management− Development objectives

Basic foundations for the SoS WBS− Product-oriented structure− Scalable Spiral Model − Three-team construct

Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS)

Implications and anticipated benefits Conclusions

304/18/23

Background

Systems engineering needs and trends− Increasing focus on capability-based acquisition− Increasing focus on user/value− Increasing complex systems of systems

• Disproportional increase in complexity and interdependency• Disproportional increase in needs for interoperability

− Increasing COTS, Open Source, reuse, and legacy integration New challenges in systems engineering and program management

− Evolutionary, rather than revolutionary− Capability, rather than functionality− Lifecycle perspective, rather than acquisition focused− Heterogeneous, rather than homogeneous− Negotiation, rather than mandate

404/18/23

Motivation for Net Centric SoS WBS

A step into continuing understanding of net centric SoS systems engineering and management− What is common, what is different?− New scopes and emphases

• Beyond traditional systems engineering considerations• Emerging behaviors and risk from evolutional process

− What is/belongs, what is/does not?− What works, what does not?

Time to step back and rethink− Systematic− Holistic− Mission and capability focused

New Perspective Required for Net Centric SoS/FoSNew Perspective Required for Net Centric SoS/FoS

504/18/23

Motivation (cont.)

No standard or commonly-accepted WBS above system level− Traditional program/project management focuses on system and

performance• Build-to-spec, requirement-driven, waterfall-ish

− Existing WBS constructs are system development focused – difficult to scale upward

• Development/acquisition centric, little attention to O&M • Interpretabilities and independencies disregarded• Enterprise context absent

Tool needed for integrated systems engineering and program management in net centric SoS programs

− Facilitates the unification of SoS SE and PM− Emerging systems engineering method: Capability Planning

Basis for cost estimating

604/18/23

Net Centric SoS WBS Goals

Provide− Standardized, yet flexible, prototypical WBS for net centric SoS engineering

and management programs – a standard template to develop program-specific WBS

− Reference model for SoS program management, systems engineering and cost estimating

− Full SoS life cycle “cradle-to-grave” perspective and support− Systematic and holistic approach− Basic analysis framework for decision making− Clear, consistent and commonly accepted terminology definition− Tailorable and adaptable model

704/18/23

Goals (cont.)

Integrate community-accepted best practices− General systems engineering and program management lifecycle− System-level WBS − Program and practice examples− Existing international standards

• ISO/IEC 15288: Systems Engineering – System Life Cycle Processes• DoD 5000.2: Operation of the Defense Acquisition System• ANSI/EIA 632 Processes for Engineering a System• MIL-HDBK-881: Work Breakdown Structure

Leverage leading development in net centric SoS systems engineering and processes, e.g.,− Spiral development model− Capability-based acquisition− Capability planning and investment analysis practices

804/18/23

Net Centric SoS WBS Scope

Target SoS/FoS type programs− With the charter to evolve mission capabilities of a SoS/FoS− Prototypical program lifecycle perspective

Consider− Program management and the supporting enterprise functions− Systems engineering and integration products− Development and O&M environments− Governance model

Capture three basic components of the SoS engineering and management practices− Systems

• Components and relationships• Infrastructure

− Processes• Program management• Systems engineering & integration• Technology development• Operations and support

− People• Management and acquisition authorities• Teams• Stakeholder community

904/18/23

Outline

Background, motivation, goals and scope− Relevant needs and trends in SoS system engineering and management− Development objectives

Basic foundations for the SoS WBS− Product-oriented structure− Scalable Spiral Model − Three-team construct

Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS) – Top-level View

Anticipated benefits and conclusions

1004/18/23

Product-oriented Work Breakdown Structure− “Product”: physical entity, organization, function/service− Processes and activities associated with products

Scalable Spiral Process Model− Risk-driven OODA loops

Three-team execution model− Plan-driven team− IV&V team− Agile Rebaselining Team

Basic Foundations of SoS WBS

1104/18/23

Emerging Scalable Spiral Process

Decide on next-cycle capabilities, architecture upgrades, plans

• Stable specifications, COTS upgrades

• Development, integration, V&V, risk management plans

• Feasibility rationale

Act on plans, specifications

• Keep development stabilized

• Change impact analysis, preparation for next cycle (mini-OODA loop)

Orient with respect to stakeholders priorities, feasibility, risks

• Risk/Opportunity analysis

• Business case/mission analysis

• Prototypes, models, simulations

Observe new/updated objectives, constraints, alternatives

• Usage monitoring

• Competition, technology, marketplace ISR

Operate as current system

Accept new system

Source: USC-CSE

Life Cycle Architecture Milestone for Cycle

1204/18/23

Spiral Bravo

Three-Team Execution Model

Plan-Driven Team IV&V Team

Environment Change

Factors

Internal Change Factors

Agile Team

Agile Team

Spiral Charlie

RequirementsKPPsArchitecture Baseline

RequirementsKPPsArchitecture Baseline

RequirementsKPPsArchitecture Baseline

1. Plan-Driven Team

2. IV&V Team

3. Agile Rebaselining Team

• Emerging technologies• New threats• Operational environment changes…

• Requirement creeps• Emerging applications• Unforeseen complexities…

SoS Evolutionary Spirals

Spiral Alpha

Time

1304/18/23

Outline

Background, motivation and goals− Relevant needs and trends in SoS system engineering and management− Development objectives

Basic foundations for the SoS WBS− Product-oriented structure− Scalable Spiral Model − Three-team construct

Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS)

Implications and anticipated benefits Conclusions

1404/18/23

SoS Program WBS

The SoS Program

The SoS in Operation

Spiral Alpha Spiral Bravo Spiral Charlie Program Office

Plan-Driven Team

IV&V Team

Agile TeamAgile Team

Lev

el 0

Lev

el 1

Development

1504/18/23

The SoS Program WBS (cont.)

The SoS in Operation: consists of legacy systems, current operational organizations, “as-is” doctrine and CONOPS

− Important in understanding the baseline “as-is” architecture and business case analysis

Spiral Alpha: current development increment executed by the Plan-Driven Team, with relative stable capability objectives, requirements, architecture baseline, and clear deliverables

Spiral Bravo: next development increment in planning by the Agile Rebaselining Team; new baseline based on near- to mid-term capabilities needs, priorities and new technologies in test labs

Spiral Charlie: future development increment in planning by the Agile Rebaselining Team; new baseline based on future capability needs, priorities and emerging technologies

Program Office: the supporting enterprise with a mission and resources to accomplish the mission

− Three teams under it− Enterprise-level/(DoD) DOTMLPF support

1604/18/23

The SoS in Operation – the Legacy

The SoS in Operation

Operational Plans

Operational Organizations

Member Systems

Peer Systems

Communications Infrastructure

Operational Maintenance &

SupportOperational

Facilities

Operational Doctrine

Operational Architecture

Operational Processes

Resources and Budgets

Subplans

Organization 1

Organization 2

…

Organization k

System 1

System 2

…

System n

Peer System 1

Peer System 2

…

Peer System p

Site 1

Site 2

…

Site m

Support Centers

Support Organizations

Training Services

Logistics Depots

Maintenance Services

Data Centers

Networks

Processes & Procedures

Lev

el 1

Lev

el 2

Lev

el 3

1704/18/23

The SoS in Operation – Dealing With Legacy

Operations & Maintenance (O&M) centric Coping with “as-is” architecture, capability and interoperability

− Inconsistent doctrine, processes− Different CONOPS− Partial interoperability− Ad hoc communications protocols− Gaps and overlaps in functionality

Adapt to emerging behaviors (trial and error, “learning the rope”) Typically managed by different program offices or service organizations Source for new capability needs and acquisition requirements Baseline for business case analysis, e.g., ROI

1804/18/23

Spiral Alpha – Current Development Increment

The SoS Version Alpha

Phase/Spiral Plan

Operational Requirements

The Capability Model

Peer Systems

Member Systems

Lifecycle Support Systems

Communications Infrastructure

Spiral Alpha

Operational Plans & Processes

Systems

Operational Organizations

Operational Facilities

Training Functions

The Integrated and Verified SoS

The Validated SoS

The Deployed SoS

Mission Objectives & Constraints

Proposal

The WBS

Resource & Budgets

Estimates

Integrated Master Plan & Schedule

Subplans

Performance, Cost, and Schedule Objectives & Thresholds

Requirements by Type

CONOPS

Operational Architecture Baseline

Functional Allocation & Synthesis Products

Key Performance Parameters

M&S & Analysis Models

System 1

…

System n

Retired System n+1

…

Retired System n+k

Peer System 1

…

Peer System p

System 1

…

System s

Existing Infrastructure

Added Infrastructure

Plan-Driven Team

IV&V Team

Requirements, Plan & Processes

Integration, Assembly, Test & Checkout Systems

Integration Labs & Test Facilities

Systems to be Integrated

PersonnelRequirements, Plan & Processes

Operational Test & Evaluation Systems

Integration Labs & Test Facilities

Validation Data

Personnel

Lev

el 1

Lev

el 2

Lev

el 3

1904/18/23

Spiral Alpha (cont.)

Responsible by the Plan-Driven Team; verified and validated by the IV&V Team

Relative stable requirements and delivery goals Development/acquisition objective: operational capability Development methodology predominantly focused on function allocation

and synthesis (integration)− Rather than performance-driven at the system level

Increasing emphasis on COTS systems integration More waterfall like development model Post-Milestone A/pre-MS B (DoD 5000) entry typically The delivery becomes the new “as-is” SoS in Operation

2004/18/23

Single System

The System

The System Plan

System Requirements

The System Design

The Integrated and Verified

System

The Subsystems

The Operational System

The Validated System

Subsystems 1 Subsystems i Subsystems n… …

Maintenance & Support Systems

Operational Personnel (dedicated)

Operational Facility (dedicated)

Manuals & Procedures

Operational Data

Support Systems

Training Function

Support Personnel (dedicated)

Support Facility (dedicated)

Maintenance & Spares

• Modified version of Ruskin’s model

• Lifecycle orientation and O&M extensions

• Prototypical system WBS for any of the systems in the SoS

• Modified version of Ruskin’s model

• Lifecycle orientation and O&M extensions

• Prototypical system WBS for any of the systems in the SoS

Lev

el 3

Lev

el 4

Lev

el 5

2104/18/23

Spirals Bravo and Charlie

Phase/Spiral Plan

Operational Requirements

The Capability Model

Mission Objectives and Constraints

The WBS

Resource & Budgets

Estimates

Subplans

Prioritized Performance, Cost, and Schedule Objectives

Prioritized Requirements by Type

CONOPS

Operational Architecture Baseline

Functional Allocation & Synthesis Products

Key Performance Parameters

M&S & Analysis Models

Agile Team The SoS Version Bravo (Charlie) Baseline

Spiral Bravo (Charlie)

Lev

el 1

Lev

el 2

Lev

el 3

2204/18/23

Spirals Bravo and Charlie (cont.)

Principal deliverables are capability and architecture models Principal responsibility of the Agile Team

− Working independently from the Plan-Driven Team− May take on the overall SE&I role for the program

Lifecycle perspective for evolution Focused on prioritization of future capability increments Primary repository of future/postponed capability needs and

requirements for acquisition Primary drivers for future capability needs:

− Changing user needs− Changing environment or threats− Emerging technologies− Budget and resource constraints− Lessons Learned

Pre-concept phase or pre-Milestone A activities typically Basis for future Spiral Alpha WBS

2304/18/23

Program Office – The Supporting Enterprise

The Program Office

The Program Mission

Capability Models

SubofficesThe Program Plan

Stakeholder Group

Mission Statement

Lifecycle Objectives

Doctrine & Policies

Capability Needs Documents

Lifecycle Architecture Products

Joint Capabilities Documents (JCDs)

Initial Capabilities Documents (ICDs)

Capability Development Documents (CDDs)

Capability Production Documents (CPDs)

Integrated Architecture Products

Capability Roadmap

Integrated Master Plan

Integrated Master Schedule

Business Case Documents

Sub-plans

The WBS

Budget & Accounting Functions

Legal & Contract Functions

Acquisition & Supply Functions

Systems Engineering & Integration Functions

HR Function

IT Support Function

Administrative Support Functions

PM

End Users

Systems Integrator

PARM/OEM/System Suppliers

Labs

Peer Program Offices

Operations Offices

Lev

el 1

Lev

el 2

Lev

el 3

Lev

el 4

2404/18/23

Program Office (cont.)

The supporting enterprise ensuring successful evaluation of the SoS capabilities based on mission

− Provides Organizational or (DoD) MOTMLPF supports to projects− Provides infrastructure (e.g., IT) support

Lifecycle evolutionary perspective Planning, managing, doctrine and oversight roles

− Manages the three teams – Plan-Driven, IV&V and Agile PM role in the stakeholder group includes a stakeholder liaison function

− Emerging and important function for SoS/FoS programs Reports to acquisition/service branch

− To (commercial) general manager System Integrator is a role, not an entity

− It has four potential job descriptions simultaneously: • On the three teams• The systems engineering & integration/capability planning at the program level

2504/18/23

Outline

Background, motivation and goals− Relevant needs and trends in SoS system engineering and management− Development objectives

Basic foundations for the SoS WBS− Product-oriented structure− Scalable Spiral Model − Three-team construct

Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS)

Implications and anticipated benefits Conclusions

2604/18/23

Implications of Scalable Spiral Model

Evolution-oriented and capability-focused Risk-driven and mission assurance Good transition for the culture and legacy program management

− Good talent pool for Plan-Driven Team Less material-oriented deliverables from early spiral(s)

− Architecture baseline more a focus Different operational philosophy and management skill set

− Build-to-spec will not work− “Best value” objectives− Cost, risk and schedule as independent variables

Requires forward-looking vision and a new breed of PMs

2704/18/23

Implications of Standardized SoS-Level WBS

Two prevalent structures:− Product-oriented− Activity-based

Integration with process-oriented and activity-based structures− Start with one structure at the top and integrate elements of the other at

lower levels Need to provide clear and consistent definition of terms

− Or potential risks of double-counting− Need for glossary and data dictionary

Possible different organizations for different purposes− Different development models

Less clear boundary for scope and division of responsibility− Are the day-to-day operational activities (and personnel) “sunk cost”?− Whose responsibility is it to establish doctrine, program office or larger

enterprise? Implications to cost estimating Linkage to other architecture products

2804/18/23

Anticipated Benefits

Provides a reference model for SoS/FoS engineering and management Defines a common set of terminology related to SoSs Enables visibility and insights into unique issues related to SoSs Provides a holistic view for SoS engineering and program management,

particularly in terms of− Interoperability− Complexity and interdependency− Ownership and governance model− Conflict management− Decision framework

Facilitates further understanding of the − Effort and cost in acquiring and owning an SoS− Methodology that can be applied to estimate this cost

Promotes the unification of systems engineering and project management for SoS− Linkage between architecting/engineering activities to the economic effect

2904/18/23

Outline

Background, motivation and goals− Relevant needs and trends in SoS system engineering and management− Development objectives

Basic foundations for the SoS WBS− Product-oriented structure− Scalable Spiral Model − Three-team construct

Net centric System of Systems (SoS) Program Work Breakdown Structure (WBS)

Implications and anticipated benefits Conclusions

3004/18/23

Conclusions To Date

General systems engineering principles and project management practices do apply to net centric SoS

Traditional system-oriented WBS construct is inadequate, and there are added ingredients in WBS for net centric SoS, from− Added complexity− Different scope, objectives and strategy− Different environment

Two different acquisition focuses:− System: functionality− System of systems: capability

And, therefore, two different development strategies:− System: waterfall− System of systems: scalable spiral

Not a complete WBS, but a step towards that direction A lot to learn, and more to explore…

3104/18/23

References

1) B. Boehm, “The Future of Software and Systems Engineering Processes,” USC-CSE-TR-2005-507, 2005

2) Boehm, B. and Turner, R., Line Dancing with Elephants – the Systems Engineering of Network-centric Complex systems of Systems (NCSOS), SSCI Member Forum, 2005

3) A. Ruskin, “Using 100% Product-Oriented Work Breakdown Structures to Unify System Engineering and Project Management,” ICSE-INCOSE, 2004

4) A. Sage and C. Cuppan, “On the Systems Engineering and Management of Systems of Systems and Federations of Systems,” Information.Knowledge.Systems Management, 2001

5) M. Jamshidi, “System-of-Systems Engineering – a Definition,” IEEE SMC 2005, Hawaii, October 2005

6) J. Lane and R. Valerdi, “Synthesizing System-of-Systems Concepts for Use in Cost Estimation,” IEEE SMC, 2005

7) J. Lane, “COSOSIMO Workshop Minutes,” 20058) C. Dickerson and et al, Using Architectures for Research, Development and Acquisition, OASD-NII,

20049) P. Jain, and C. Dickerson, “Family-of-Systems Architecture Analysis Technologies,” INCOSE, 200510) D. Bracamonte, “An Adaptive Automated Model for formatting & Presenting Life Cycle Costs,” ISPP

Proceedings, 1993 11) ISO/IEC 15288, Systems Engineering – System Life Cycle Processes, 200212) DoD Instruction 5000.2, Operation of Defense Acquisition System, 200013) ANSI/EIA 632, Process for Engineering a System, 199914) J. Martin, “Overview of the EIA 632 Standard – ‘Processes for Engineering a System’ (Tutorial G)”15) MIL-HDBK-881, DoD Work Breakdown Structure, 1993

3204/18/23

3304/18/23

Example of Product-Oriented WBS

The System

The System Plan

System Requirements

The System Design

The Integrated and Verified

System

The Subsystems

System Post-Accomplishment

ProductsThe Validated

System

Subsystems 1 Subsystems i Subsystems n… …

The Subsystem i Plan

Subsystem i Requirements

The Subsystem i Design

The Integrated and Verified Subsystem i

The Subsystem i’s Sub-Subsystems

Subsystem i Post-Accomplishment

ProductsThe Validated Subsystem i

Source: A. M. Ruskin

System-level WBS…

… for engineering and constructing a system