1. CS-1 6/17/2015 1 6/17/2015 Towards a Work Breakdown Structure for Net Centric System of Systems Engineering and Management 20 th International Forum on COCOCMO Workshop October 2005 Gan Wang gan.wang@baesystems.com gan.wang@baesystems.com Ricardo Valerdi rvalerdi@mit.edu rvalerdi@mit.edu Jo Ann Lane jolane@usc.edu jolane@usc.edu Barry Boehm boehm@cse.usc.edu boehm@cse.usc.edu

2. 2 6/17/2015 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

3. 3 6/17/2015 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

4. 4 6/17/2015 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

5. 5 6/17/2015 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

6. 6 6/17/2015 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

7. 7 6/17/2015 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

8. 8 6/17/2015 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

9. 9 6/17/2015 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

10. 10 6/17/2015  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

11. 11 6/17/2015 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

12. 12 6/17/2015 Spiral Bravo Three-Team Execution Model Plan-Driven TeamIV&V Team Environmen t Change Factors Internal Change Factors Agile Team Spiral Charlie Requirements KPPs Architecture Baseline Requirements KPPs Architecture Baseline Requirements KPPs Architecture 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

13. 13 6/17/2015 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

14. 14 6/17/2015 SoS Program WBS The SoS Program The SoS in Operation Spiral AlphaSpiral BravoSpiral CharlieProgram Office Plan- Driven Team IV&V Team Agile Team Level 0 Level 1 Development

15. 15 6/17/2015 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

16. 16 6/17/2015 The SoS in Operation – the Legacy The SoS in Operation Operational Plans Operational Organizations Member Systems Peer Systems Communications Infrastructure Operational Maintenance & Support Operational 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 Level 1 Level 2 Level 3

17. 17 6/17/2015 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

18. 18 6/17/2015 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 Personnel Requirements, Plan & Processes Operational Test & Evaluation Systems Integration Labs & Test Facilities Validation Data Personnel Level 1 Level 2 Level 3

19. 19 6/17/2015 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

20. 20 6/17/2015 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 1Subsystems iSubsystems 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 Level 3 Level 4 Level 5

21. 21 6/17/2015 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) Level 1 Level 2 Level 3

22. 22 6/17/2015 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

23. 23 6/17/2015 Program Office – The Supporting Enterprise The Program Office The Program Mission Capability Models Suboffices The 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 Level 1 Level 2 Level 3 Level 4

24. 24 6/17/2015 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

25. 25 6/17/2015 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

26. 26 6/17/2015 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

27. 27 6/17/2015 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

28. 28 6/17/2015 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

29. 29 6/17/2015 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

30. 30 6/17/2015 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…

31. 31 6/17/2015 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,” 2005 8)C. Dickerson and et al, Using Architectures for Research, Development and Acquisition, OASD-NII, 2004 9)P. Jain, and C. Dickerson, “Family-of-Systems Architecture Analysis Technologies,” INCOSE, 2005 10)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, 2002 12)DoD Instruction 5000.2, Operation of Defense Acquisition System, 2000 13)ANSI/EIA 632, Process for Engineering a System, 1999 14)J. Martin, “Overview of the EIA 632 Standard – ‘Processes for Engineering a System’ (Tutorial G)” 15)MIL-HDBK-881, DoD Work Breakdown Structure, 1993

32. 32 6/17/2015

33. 33 6/17/2015 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 Products The Validated System Subsystems 1Subsystems iSubsystems 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 Products The Validated Subsystem i Source: A. M. Ruskin System-level WBS… … for engineering and constructing a system