Towards a Work Breakdown Structure for Net Centric System of Systems Engineering and Management 20th International Forum on COCOCMO Workshop October 2005 Gan Wang gan.wang@baesystems.com Jo Ann Lane jolane@usc.edu Ricardo Valerdi rvalerdi@mit.edu Barry Boehm boehm@cse.usc.edu CS-1 1 3/14/2016 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 2 3/14/2016 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 3 3/14/2016 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/FoS 4 3/14/2016 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 5 3/14/2016 Net Centric SoS WBS Goals Provide − Standardized, yet flexible, prototypical WBS for net centric SoS engineering and management programs – a standard template to develop programspecific 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 6 3/14/2016 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 7 3/14/2016 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 8 3/14/2016 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 9 3/14/2016 Basic Foundations of SoS WBS 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 10 3/14/2016 Emerging Scalable Spiral Process Observe new/updated objectives, Orient with respect to stakeholders • Usage monitoring • Risk/Opportunity analysis • Competition, technology, marketplace ISR • Business case/mission analysis constraints, alternatives priorities, feasibility, risks • Prototypes, models, simulations Operate as current system Accept new system Act on plans, specifications • Keep development stabilized • Change impact analysis, preparation for next cycle (miniOODA loop) Decide on next-cycle capabilities, architecture upgrades, plans • Stable specifications, COTS upgrades • Development, integration, V&V, risk management plans • Feasibility rationale Life Cycle Architecture Milestone for Cycle Source: USC-CSE 11 3/14/2016 Three-Team Execution Model • Emerging technologies • New threats • Operational environment changes … 1. Plan-Driven Team 2. IV&V Team 3. Agile Rebaselining Team Environmen t Change Factors Agile Team Spiral Charlie Requirements KPPs Architecture Baseline • Requirement creeps • Emerging applications • Unforeseen complexities … Agile Team Internal Change Factors Plan-Driven Team Spiral Bravo Requirements KPPs Architecture Baseline IV&V Team Spiral Alpha Requirements KPPs Architecture Baseline SoS Evolutionary Spirals Time 12 3/14/2016 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 13 3/14/2016 SoS Program WBS Level 1 Level 0 The SoS Program The SoS in Operation Spiral Alpha Spiral Bravo Spiral Charlie Program Office Development IV&V Team PlanDriven Team Agile Team 14 3/14/2016 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 PlanDriven 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 15 3/14/2016 The SoS in Operation – the Legacy Level 2 Level 1 The SoS in Operation Operational Plans Member Systems Operational Organizations Level 3 Operational Doctrine Operational Architecture Operational Processes Resources and Budgets Subplans Organization 1 Organization 2 … Organization k Peer Systems Operational Maintenance & Support Operational Facilities Communications Infrastructure Peer System 1 Peer System 2 … Peer System p System 1 System 2 … System n Data Centers Networks Processes & Procedures Support Centers Support Organizations Training Services Logistics Depots Maintenance Services Site 1 Site 2 … Site m 16 3/14/2016 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 17 3/14/2016 Spiral Alpha – Current Development Increment Plan-Driven Team Phase/Spiral Plan Level 3 Level 2 Level 1 Spiral Alpha Operational Requirements Requirements by Type Mission Objectives & Constraints Proposal The WBS Resource & Budgets Estimates Integrated Master Plan & Schedule Subplans The SoS Version Alpha The Capability Model Performance, Cost, and Schedule Objectives & Thresholds Lifecycle Support Systems Member Systems Communications Infrastructure Peer Systems System 1 Peer System 1 … … System n Peer System p Retired System n+1 … Retired System n+k Operational Architecture Baseline Functional Allocation & Synthesis Products Key Performance Parameters The Validated SoS The Integrated and Verified SoS The Deployed SoS Requirements, Plan & Processes Operational Plans & Processes Integration, Assembly, Test & Checkout Systems Systems Integration Labs & Test Facilities Personnel System 1 … System s Operational Organizations Operational Facilities Systems to be Integrated CONOPS M&S & Analysis Models IV&V Team Training Functions Requirements, Plan & Processes Existing Infrastructure Operational Test & Evaluation Systems Added Infrastructure Integration Labs & Test Facilities Validation Data Personnel 18 3/14/2016 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 19 3/14/2016 Single System Level 4 Level 3 The System The System Plan The System Design System Requirements The Subsystems …Subsystems i The Operational System The Validated System …Subsystems n Level 5 Subsystems 1 The Integrated and Verified System Maintenance & Support Systems Operational Personnel (dedicated) Operational Facility (dedicated) Manuals & Procedures Operational Data • Modified version of Ruskin’s model • Lifecycle orientation and O&M extensions • Prototypical system WBS for any of the systems in the SoS Support Systems Training Function Support Personnel (dedicated) Support Facility (dedicated) Maintenance & Spares 20 3/14/2016 Level 3 Level 2 Level 1 Spirals Bravo and Charlie Spiral Bravo (Charlie) Agile Team The SoS Version Bravo (Charlie) Baseline Phase/Spiral Plan Operational Requirements Mission Objectives and Constraints The WBS Resource & Budgets Estimates Subplans Prioritized Performance, Cost, and Schedule Objectives Prioritized Requirements by Type The Capability Model CONOPS Operational Architecture Baseline Functional Allocation & Synthesis Products Key Performance Parameters M&S & Analysis Models 21 3/14/2016 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 22 3/14/2016 Level 4 Level 3 Level 2 Level 1 Program Office – The Supporting Enterprise The Program Office The Program Mission Mission Statement Lifecycle Objectives Doctrine & Policies Capability Models Integrated Master Plan Integrated Master Schedule Business Case Documents Sub-plans The WBS Capability Needs Documents Lifecycle Architecture Products Joint Capabilities Documents (JCDs) Initial Capabilities Documents (ICDs) Integrated Architecture Products Capability Roadmap Capability Development Documents (CDDs) Capability Production Documents (CPDs) Suboffices The Program Plan Budget & Accounting Functions Legal & Contract Functions Acquisition & Supply Functions Systems Engineering & Integration Functions Stakeholder Group PM End Users Systems Integrator PARM/OEM/System Suppliers Labs Peer Program Offices Operations Offices HR Function IT Support Function Administrative Support Functions 23 3/14/2016 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 24 3/14/2016 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 25 3/14/2016 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 26 3/14/2016 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 27 3/14/2016 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 28 3/14/2016 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 29 3/14/2016 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… 30 3/14/2016 References 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) B. Boehm, “The Future of Software and Systems Engineering Processes,” USC-CSE-TR-2005-507, 2005 Boehm, B. and Turner, R., Line Dancing with Elephants – the Systems Engineering of Network-centric Complex systems of Systems (NCSOS), SSCI Member Forum, 2005 A. Ruskin, “Using 100% Product-Oriented Work Breakdown Structures to Unify System Engineering and Project Management,” ICSE-INCOSE, 2004 A. Sage and C. Cuppan, “On the Systems Engineering and Management of Systems of Systems and Federations of Systems,” Information.Knowledge.Systems Management, 2001 M. Jamshidi, “System-of-Systems Engineering – a Definition,” IEEE SMC 2005, Hawaii, October 2005 J. Lane and R. Valerdi, “Synthesizing System-of-Systems Concepts for Use in Cost Estimation,” IEEE SMC, 2005 J. Lane, “COSOSIMO Workshop Minutes,” 2005 C. Dickerson and et al, Using Architectures for Research, Development and Acquisition, OASD-NII, 2004 P. Jain, and C. Dickerson, “Family-of-Systems Architecture Analysis Technologies,” INCOSE, 2005 D. Bracamonte, “An Adaptive Automated Model for formatting & Presenting Life Cycle Costs,” ISPP Proceedings, 1993 ISO/IEC 15288, Systems Engineering – System Life Cycle Processes, 2002 DoD Instruction 5000.2, Operation of Defense Acquisition System, 2000 ANSI/EIA 632, Process for Engineering a System, 1999 J. Martin, “Overview of the EIA 632 Standard – ‘Processes for Engineering a System’ (Tutorial G)” MIL-HDBK-881, DoD Work Breakdown Structure, 1993 31 3/14/2016 32 3/14/2016 Example of Product-Oriented WBS System-level WBS… The System The System Plan The System Design The Integrated System Postand Verified Accomplishment System Products The Validated The Subsystems System System Requirements Subsystems 1 The Subsystem i Plan … Subsystems i The Subsystem i Design Subsystem i Requirements … Subsystems n The Integrated and Verified Subsystem i The Subsystem i’s Sub-Subsystems Subsystem i PostAccomplishment Products The Validated Subsystem i … for engineering and constructing a system Source: A. M. Ruskin 33 3/14/2016