Presentation is loading. Please wait.

Presentation is loading. Please wait.

USC CSSE Annual Research Review Los Angeles, CA March 2006 Agile Defense Acquisition: Possibility or pipe dream? Richard Turner Systems and Software Consortium.

Similar presentations


Presentation on theme: "USC CSSE Annual Research Review Los Angeles, CA March 2006 Agile Defense Acquisition: Possibility or pipe dream? Richard Turner Systems and Software Consortium."— Presentation transcript:

1 USC CSSE Annual Research Review Los Angeles, CA March 2006 Agile Defense Acquisition: Possibility or pipe dream? Richard Turner Systems and Software Consortium Herndon, VA USA turner@systemsandsoftware.org

2 ©2005 USC-SSCI 2 The Systems and Software Consortium A not-for-profit collaboration of member companies Objective is to improve business performance by enhancing software and systems engineering Members benefit by leveraging SSCI Staff’s – technical talent – broad industry-wide perspective Rule #4 : The best companies are the best collaborators Thomas L. Friedman, The World is Flat. 2005, p. 352 Rule #4 : The best companies are the best collaborators Thomas L. Friedman, The World is Flat. 2005, p. 352

3 ©2005 USC-SSCI 3 Topics The difficulty of line dancing with elephants (a tale of agility) What’s new What’s the same What are our opportunities

4 ©2005 USC-SSCI 4 Elephants Dancing Independently Individually fairly reliable Competitively differentiated Don’t do the same steps May not be listening to the same music Not particularly attractive as a group

5 ©2005 USC-SSCI 5 Elephants Line Dancing – sort of Looks good early, but… The line can break down

6 ©2005 USC-SSCI 6 Elephants Resynching Need ways to check the steps and resynchronize with the leader

7 ©2005 USC-SSCI 7 Elephants Resynched and Dancin’! And off they go! Elephants are easy, think about all the humans involved with acquiring complex systems! Need a new (or different) paradigm for acquisition Evolving value-based risk-driven process – Humans are part of both the value equation and the risk evaluation

8 ©2005 USC-SSCI 8 Acquisition is primarily a human activity Done by humans, with human activities – Creativity (concepts, requirements) – Negotiation (discussion, trade-offs) – Intimidation (power, authority, process) – Bureaucracy (aversion to change, careers) Acquisition success is human-driven – Focus on end user/warfighter – Economic drivers – Political vectors Barriers to success are also human – Laws to prevent graft – Regulations that establish and protect turf – Budget decisions (+ or -) Communication is key

9 ©2005 USC-SSCI 9 What’s New in Defense Acquisition Quadrennial Defense Review Defense Acquisition Performance Assessment (The Kadish Review) Business Transformation Agency

10 ©2006 SSCI 10 Quadrennial Defense Review More “jointness” between Services and among warfighter, acquisition and resource communities – Portfolio management – Solution assessment informed by “technological feasibility and cost-per-increment of capability improvement” Emphasizes agility, flexibility, responsiveness and effectiveness – Agile decision making – Risk-based (vice cost-based) source selection – Time-certain approach (more later)

11 ©2005 USC-SSCI 11 Defense Acquisition Performance Review Latest in a long line of major reviews Led by Gen. Ronald Kadish, USAF (ret) – Vice President, Booz Allen Hamilton – Former Director, Missile Defense Agency Insightful analysis of current system Acknowledges disconnects and instability – Actions taken locally without consideration of impact – “Gov’t-induced and long-standing cycle of instability” Recommends radical changes “[The Acquisition System] must be agile – to an unprecedented degree – to respond quickly to urgent operational needs from across the entire spectrum of potential conflicts.”

12 ©2005 USC-SSCI 12 Current Acquisition System (DAPA)

13 ©2005 USC-SSCI 13 Pertinent Recommendations Create Stable Program Funding Account and Management Reserve to mitigate budget perturbations Delegate authority to PMs to defer non-KPP requirements to future blocks or spirals Time-certain Delivery requirements DDR&E coordinate Service S&T transition plans DDR&E actively participate in process at Joint level Move Milestone B (decision to move into System Development and Demonstration) to PDR

14 ©2005 USC-SSCI 14 Time-certain Development Timeboxing approach (when coupled with new PM authority to defer requirements) Enforces evolutionary acquisition by making time the focus of the up front requirement statement – Maximum number of years is mandated (nominal 6 years to MS A) – Start and end dates are defined – Driving processes (requirements, budget, source selection, etc.) are revamped to support Applies after MS B

15 ©2005 USC-SSCI 15 Business Transformation Agency Evolved from Business Management Modernization Program (BMMP) program – Reports to OUSD(AT&L) Responsible for DoD Business Enterprise Architecture and Enterprise Transition Plan – BEA is DODAF based (IBM Lead) – Goal: Integrate all DoD business systems into a single architecture – Compliance to the BEA required for funding (enforced by Investment Review Boards)

16 ©2005 USC-SSCI 16 What’s the same Emphasis on systems engineering – SEP – Program Support Assessments Aversion to using “spiral” and “evolutionary” – Seen as too complex – DAPA report could impact this Shrinking industrial sources – Emphasis on COTS-based solutions (even ships)

17 ©2005 USC-SSCI 17 Key technical issues remain Estimation and progress measurement at the system and system of systems level Management approaches for complex SoSs – Supplier chain acquisition and monitoring – Large-scale integration facilities – Simulation-based testing effectiveness, coverage Software and information assurance Integration of SwE and SE within current acquisition system Net-centric systems – Infrastructure availability, reliability – Information overload

18 ©2005 USC-SSCI 18 Opportunities: Agile Acquisition Rehabilitate spiral – Revisit USC-SEI workshop results – Reinterpret in light of agility – Leverage QDR and DAPA reports – Make it simpler to implement and recognize Disciplined agility Embrace (or at least acknowledging) change Interpret and integrate OSD systems engineering acquisition lifecycle for agility Develop ways to effectively pilot (simulate?) and compare/evaluate new acquisition and development lifecycle approaches – including human components – Boehm three-tier Value-based Risk-driven approach – DAPA Time-certain – OSD Multi-V

19 ©2005 USC-SSCI 19 Backup Slides And Information

20 ©2005 USC-SSCI 20 The Need for Network-centric Complex Systems of Systems Lack of integration among stovepiped systems causes – Unacceptable delays in service – Uncoordinated and conflicting plans – Ineffective or dangerous decisions – Inability to cope with fast-moving events Increasing NCSOS benefits – See first; understand first; act first – Network-centric operations coordination – Transformation of business/mission potential – Interoperability via Integrated Enterprise Architectures

21 ©2005 USC-SSCI 21 Complexity of Solution Spaces Large software size: 10-100 MLOC Number of external interfaces: 30-300 Number of “Coopetitive” suppliers: 20-200 – Even more separate work locations Depth of supplier hierarchy: 6-12 levels Number of coordination groups: 20-200 – Reviews, changes, risks, requirements, architecture, standards, procedures, technologies, -ilities, integration, test, deployment, personnel, infrastructure, COTS,… – Key personnel spend 60 hours/week in meetings Multi-platform, hybrid comms, intelligent components Unprecedentedness Emergence Rapid change Multi-cultural globalization

22 ©2005 USC-SSCI 22 Effect of Waterfall SEMP and Spiral SDP Delays in starting critical software infrastructure – OS, networking, DBMS, transaction processing, … Infeasible infrastructure – Premature performance requirements (e.g., 1 second) Premature hardware selection overconstrains software – Can also induce premature COTS commitments Waterfall-based progress payments undermine- spiral tasks – Develop prototypes or get paid for specifications

23 ©2005 USC-SSCI 23 Emergent Requirements and Rapid Change Global connectivity and competition accelerate emergence and change – More ripple effects of technology, marketplace changes Increased need for agility, continuous learning – Need to balance agility and plan-driven dependability – Decline of THWADI (That’s how we’ve always done it) – Beware! Avoid technical agility + administrative THWADI – Keep good THWADI: Your corporate memory Hybrid agile/plan-driven processes needed for larger systems Need for incremental processes, methods, tools, skills Need for pro-active technology, marketplace monitoring – Example: Internet spiral Education: Need to learn how to learn

24 ©2005 USC-SSCI 24 Rapid Change and High Dependability: Need Simultaneous Agility and Discipline Discipline for planning, structure, assurance – Foundations (architecture, organizations) Planning for foreseeable change – Thorough V&V Agility to handle the environment – Rapid, continuous, often unforeseeable change – Concurrent engineering Of requirements, architecture, hardware and software Of development and evolution Of many suppliers and integrators – Simultaneous agile and disciplined change management is critical

25 ©2005 USC-SSCI 25 A Value-based, Risk-driven Approach Framework for integrating systems, hardware, and software engineering Distinguishing intellectual content of systems engineering – Vs. physical-science content of AE, ChE, EE, ME, … Clean mapping onto traditional, legacy process milestones (DoD, RUP, MBASE,…) Synchronizes and stabilizes concurrent engineering Enables both high assurance and agile adaptation to rapid change Distinguishes project termination from project failure – Termination: cost-effective windup of calculated risk Scalable up to NCSOS and down to small web applications

26 ©2005 USC-SSCI 26 NCSOS Acquisition: More Like Doing C4ISR - than purchasing fruitcake C4ISR: Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance No detailed plan survives the first engagement Acquisition C4ISR via spiral OODA loops – Observe, Orient, Decide, Act – Vs. Requirements, Delay, Surprise Concurrent tasking, collaboration technology essential – Spanning deep chains of command Customer, LSI, IPT’s (C4ISR), Decision Support, COP Refresh, Sensor Fusion, Sensors, Sensor components Common strategy essential; micro-planning risky Competition, technology, marketplace ISR essential Rapid adaptability essential, but Stable development increments essential as well How the Government purchasing agents buy fruitcake...

27 ©2005 USC-SSCI 27 Acquisition C4ISR Via Spiral OODA Loops Life Cycle Architecture Milestone for Cycle 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

28 ©2005 USC-SSCI 28 Next-Development Increment (DI) Definition Review Preparation: A Concurrent Agile SE OODA Loop Assess changes during previous DI – Changes in Operational Concept, key scenarios, COTS, interoperating systems – Previous-DI scope changes – Feedback from assessments, users – Determine feasible scope of next DI Coordinate scope changes with affected stakeholders – Users, assessors, interoperators, SISOS elements, suppliers, future-DI managers, upper management Prepare review content – Scope definition and rationale, SISOS element requirements, change summary, top-N risk list, candidate pilot users and major external assessments

29 ©2005 USC-SSCI 29 Emerging VBRD Method: Implications Concurrent incremental develop/V&V/rebaseline enables agile/plan-driven process solution SOS inception and elaboration phases generate agile/plan-driven product solution D/V/R activities – Need different contract incentives – Need different skill strengths, but some rotation is healthy Enables risk-driven tailoring to different solutions Technology/Competition/Marketplace monitoring enables value-based competitive agility Method scales-up to Future Combat System/JSF- type projects, down to campus web-services

30 ©2005 USC-SSCI 30 Increment N Baseline Increment N+1 Baseline The Emerging VBRD Approach: Increment Activites Rapid Change High Assurance Agile Rebaselining for Increment N+1 and V&V Short, Stabilized Development of Increment N V&V of Increment N Increment N Transition/O&M Increment N-1 V&V Unforeseeable Change (Adapt) Short Development Increments Increment N+1 V&V Stable Development Increments Continuous V&V ConcernsArtifacts Deferrals Foreseeable Change (Plan)

31 ©2005 USC-SSCI 31 The Emerging VBRD Approach: A Complete Program SOS Inception SOS Elaboration Agile DI 2 (OOD) Re-baseline DI 1 Construction (A) DI 1 V&V Agile DI 3 (OOD) Re-baseline DI 2 Construction (A) DI 2 V&V Agile DI 4 (OOD) Re-baseline DI 3 Construction (A) DI 3 V&V DI 1 Transition, O&M DI 2 Transition, O&M SOS LCO SOS, DI 1, DI 2 B/L LCA DI 2 LCA Changes DI 3 B/L LCA Changes DI 3 B/L LCA Changes Capability Drop DI 3 Transition, O&M Capability Drop

32 ©2005 USC-SSCI 32 The Internet Spiral Process Ref: USAF-SAB Information Architectures Study, 1994 Approved Internet Standard Approved Draft Standard Approved Proposed Standard Unapproved Proposed Standard IESG Approval IETF Review IETF Review IETF Review Working Group Review Full Implementation Widespread Implementation and Test Multiple Implementation and Test Equipment Working Group Evolution Unapproved Draft Standard Unapproved Internet Standard IESG = Internet Engineering Steering Group IETF = Internet Engineering Task Force

33 ©2005 USC-SSCI 33 The Emerging VBRD Approach: A Notional Spiral DOD 5000 Continue VBRD for Capability Increments

34 ©2005 USC-SSCI 34 SISOS Acquisition: Critical Success Factors Risk-driven spiral processes and organizations – Project manager’s risk/opportunity team Stabilized evolutionary builds – Concurrent plan-driven construction, agile rebaselining – Anchor point milestones and Feasibility Rationales Rethinking supplier management – Teambuilding and plans/architecture participation – Balanced agile/plan-driven contracts, award fees Knowing when not to system engineer – Example: Product line architecture vs. best-of-breed supplier selection


Download ppt "USC CSSE Annual Research Review Los Angeles, CA March 2006 Agile Defense Acquisition: Possibility or pipe dream? Richard Turner Systems and Software Consortium."

Similar presentations


Ads by Google