Agile Procurement and Lessons Learned from Agile-based Projects

Transcription

1 Project Delivery Summit 2016 Session 7 Agile Procurement and Lessons Learned from Agile-based Projects November 1, 2016

2 Opening Remarks

3 Learning Objectives Understand a pragmatic approach to Agile procurement and contracting in a public sector environment Review lessons learned from large modernization projects delivered using an Agile approach Learn how to avoid common pitfalls and mistakes in Agile transformation within a large organization 3

4 Agenda 10.15am 10.45am Agile Procurement Scott Dalessio, Grant Thornton 10.45am 11.10am Panel Discussion Jim Butler, DGS, Chief Procurement Officer Jim Kammerer, OSI, Chief, Acquisition and Contracting Services Division Ben Flores, CDT/STPD, Assistant Deputy Director Peter Kelly, CWDS, Deputy Director 11.10am 11.35am Agile Lessons Learned Udghosh Bhambore, Grant Thornton 11.35am 12.00pm Panel Discussion Peter Kelly, CWDS, Deputy Director Karen Johnson, DHCS, Chief Deputy Director Paul Smith, CDCR, EIS, Deputy Director 4

5 Agile Procurement 5

6 Procurement Challenge Key part of landscape Big, growing for years Deep rooted, intertwined Expensive, risky to replace Hard to remove A lot like your legacy system! These challenges drive procurement risk 6

7 Root Causes Large IT modernization procurements often become risky, costly, and unproductive mistakes that do not deliver intended outcomes 1 Duration is proxy indicator for size, complexity, uncertainty, cost 7

8 Needed Change There is a history of having large federal [state] IT programs, where $100M would not be considered big, and that mindset needs to go away. - Federal CIO Respondent Large = difficult to understand, plan, estimate, organize, and deliver 8

9 Pattern for Success A pattern from nature: strangler vines. Seed in tree branches over time, work there way down, rooting in ground, eventually strangling host tree Strangler pattern: incrementally create a new system around the edges of the old, letting it grow, module at a time, until the old system is replaced Martin Fowler Improve procurement success by using architecture to define smaller, less risky, manageable solution boundaries 9

10 Business Case There is strong business case, and wide endorsement, for modular approach, but its not just enabled by changes to architecture and delivery approaches 10

11 Delivery Aligned Procurement There are obstacles to aligning acquisition processes to support modular delivery model. Without this alignment, it is difficult to move away from large scale implementations to modular development and realize the full potential of Agile methods. - Federal CIO Respondents 11

12 Align, Don t Abandon, Procurement Rigor DETERMINE Design BUSINESS REQUIREMENTS PHASE 2 PHASE CONDUCT Mobilize MARKET RESEARCH 3 DEVELOP SOURCING STRATEGY 4 ACQUISITION PLANNING & STRATEGY DEVELOPMENT OUTCOME: DEFINED BUSINESS REQUIREMENTS & IDENTIFICATION OF SAVING OPPORTUNITIES OUTCOME: UNDERSTANDING OF COST DRIVERS & VENDOR CAPABILITY, INTEREST, & CAPACITY OUTCOME: DEFINED SOURCING STRATEGY TO ACHIEVE BUSINESS OBJECTIVES & MISSION NEEDS OUTCOME: DEFINED ACQUISITION FRAMEWORK & STRATEGY TO ACHIEVE BUSINESS GOALS SOLICITATION SOURCE 5 Plan Plan DEVELOPMENT 1 SELECTION 1 PHASE 6 PHASE 7 1 PHASE NEGOTIATE & Plan AWARD CONTRACT(S) 8 POST-AWARD IMPLEMENTATION OUTCOME: SOLICITATION PACKAGE COMPLETION & READY FOR RELEASE OUTCOME: IDENTIFICATION & JUSTIFICATION OF WHICH VENDOR(S) PROVIDES THE BEST VALUE OUTCOME: GOVERNMENT & VENDOR PARTNERSHIP W/MUTUALLY BENEFICIAL TERMS & CONDITIONS OUTCOME: ADVISORY SUPPORT TO PROMOTE SUCCESSFUL PROGRAM EXECUTION & MONITORING CHANGE MANAGEMENT 12

13 To Deliver Agile Procurement Capability Segregate program work within less lengthy, risky modules and align contracts with vendor core competencies Employ specialists and unhinge program success from the performance of a single vendor and single contract Incrementally fund contracts in alignment with changing needs, priorities, and updated release plans Qualify vendors based on demonstrated, hands-on ability to perform in-scope program work Separate underperforming vendors and quickly engage alternative service providers, with minimal disruption Link contract payments to vendor performance and delivered value of working software Measure performance, motivate improvement, evaluate price reasonableness, and maintain pricing pressures 13

14 7 Enabling Practices for Agile Procurement 1 Segregate Service Requirements Diversify delivery responsibilities to unhinge program success from the performance of a single vendor. Separate platform and architecture services from product development, so that specialists can be engaged. 2 Use Multi-Award Indefinite Delivery Contract Vehicles Establish pool of pre-qualified, competent, and price competitive vendors. This provides ability to contract modular development services on release basis and switch to alternative vendors without significant disruption. 3 Define smaller, less risky, more manageable product boundaries that Use Modular limit dependency on individual vendors and enable modular acquisition. Use Architecture architecture to segregate work and, using IDV pool, contract with specialists. 4 Use Streamlined Procurement Practices Use Project Charter-based Statement of Objectives to define Task Order (TO) scope. Select TO vendors from the IDV pool by applying streamlined vendor selection procedures that heavily favor competitive prototyping. 14

15 7 Enabling Practices for Agile Procurement 5 6 Use Release Plans to Incrementally Fund Work Define Deliverables as Working Software When awarding TOs, initially fund only the Release Planning Task. Treat development Tasks as optional (price determinable via formula into contract). Incrementally fund optional Tasks as Release Plans are mutually agreed and with do consideration for performance metric from prior releases. Base contract performance measurement and payment schedules on delivery high quality software, not ceremony or iteration completion. Directly ties payment continuum to acceptance of in-scope features. 7 Measure Performance Use inspect and adapt metrics to monitor vendor performance and progress. Use metrics, collected during previously executed releases, as basis for evaluating source selection options, for executing optional release development TOs, and for testing realism of proposed release plans. 15

16 Key Concept: Reducing Single Vendor Dependence Similar to general housing contractor or city planner: provides blueprints, not detailed designs PMO providing governance and management control Integration Vendor providing architecture and API Harness Development vendors building program products Vendor setbacks and changes don t disrupt other product teams Separate from development to facilitate minimally disruptive vendor changes Platform vendor providing deployment pipeline management 16

17 Key Concept: Release Plan Driven Contracting Develop Charter Define Features Elaborate Stories Plan Releases Inspect & Forecast Implement Stories Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Release 4 Release 1 Release 2 Release 3 S6 S1 S2 S3 S4 S5 S6 S1 S2 S3 S4 S5 S6 S1 S2 S3 S4 S5 S6 S1 S2 S3 S4 S5 S6 S1 TO 1 Release Commitment and TO 2 Option TO 2 Release Commitment and TO 2 Option Release Commitment and TO Option TO 3 17

18 Key Concept: Optional CLINs and Payments Line Item (opt.) 0003 (opt.) 0004 (opt.) 0005 (opt.) 0006 (opt.) 0007 (opt.) Description of Services R1 Planning POP Type Unit Price 3 Mos. T&M R1 Dev 3 Mos. FFP R2 Planning 3 Mos. T&M R2 Dev 3 Mos. FFP R3 Planning 3 Mos. T&M R3 Dev 3 Mos. FFP R1 Planning 3 Mos. T&M Vendor Proposed LCATs, Max Hours, & Rates $ Gold $, Silver $, Bronze $ Vendor Proposed LCATs, Max Hours, & Rates $ Gold $, Silver $, Bronze $ Vendor Proposed LCATs, Max Hours, & Rates $ Gold $, Silver $, Bronze $ Vendor Proposed LCATs, Max Hours, & Rates $ 18

19 Vendor Management The described approach requires government to move away from one-anddone contracting model. The process requires government to frequently and expeditiously issue and award product-based task orders and release plan-based tasks. This can overwhelm a contracting office. Some acquisition functions do not have the capacity to quickly prepare high-quality procurement packages. Some acquisition functions do not have the resources or all skills required to manage multiple, concurrent product development vendors. Where these challenges exist Government should centralize these responsibilities in a vendor management organization comprised of high-performing procurement and contracting staff with deep IT expertise and requisite, innovative acquisition skills. 19

20 Agile IT Product Management Focus on establishing innovative, user-centered product vision: user-centered visioning task flow analysis user scenario analysis customer journey maps application storyboarding proto-sketching Focus on delivering modernization roadmap that best serves mission: legacy target gap analysis modernization impact analysis decommissioning optimization modernization road mapping portfolio backlog prioritization Focus on incorporating userinformed product improvements: idea crowd sourcing idea governance and screening adoption/use analytics user needs analysis Focus on sprint / release plan execution and quality management practices: inspect and adapt metrics testing process improvement defect management improvement release management improvements Focus on user story quality, estimation and planning: feature Roadmapping story elaboration work and value estimation big room planning release planning 20

21 Questions

22 Agile Lessons Learned 22

23 Agile has been proven to be successful 3x Waterfall Agile is successful in the private and public sector: o o o o NASA's Mars Science Laboratory's Curiosity Rover Project $500+ million dollar legacy modernization in Insurance Industry COTS Project with distributed Agile teams in 7 countries FBI's Sentinel Case Mgmt System $600m (Waterfall) Vs $114m (Agile) 23

24 The 2016 State CIO Survey says "Agile is the Future" To the extent that Agile or incremental software development approaches have been followed on projects in your state, how would you characterize their success? Too early to tell not enough information to-date These approaches were superior in success to Waterfall software development These approaches were comparable in success to Waterfall software development These approaches did not work for our state % 31% 16% 8% 24

25 The 2016 State CIO Survey Key Themes Where you have employed Agile or incremental software development approaches on projects, what were the top three critical success factors? 2016 Picking the right type of projects on which to employ Agile 79% Customer involvement and commitment 64% Effective training of staff 48% Agile-specific project management methods and tools 46% Use of experienced Agile coaches 34% Use of supporting software tools to provide supporting data and metrics 9% Agile-specific procurement and contract management methods and tools 9% 25

26 Agile Lessons Learned Agile Transformation - be serious about adoption Agile for Big Projects - scaling to enterprise level Waterfall and Agile Can they co-exist? Agile Metrics - Can't measure, then can't manage How to build Agile workforce and culture? Power of Agile to combat common project management issues 26

27 Go beyond buzz words, be serious about adoption After the buzz is over, how should organizations adopt Agile Avoid half-hearted Agile implementation Adhere to Agile's principles and best practices Choose right tools for Agile transformation Engage coaches and experts 27

28 Agile scales to enterprise level and brings discipline Agile has matured over last two decades: Development of frameworks used to scale at the program and enterprise levels (i.e., SAFe / LeSS) Implementation and alignment of PMO efforts around Agile Incorporation of process changes around the full SDLC (e.g. DevOps) 28

29 Agile can and must coexist with other SDLC methodologies Large organizations or projects need best of the breed methodologies One division uses Agile, while others use Waterfall Agile used for product development phase, Waterfall for rollouts Blended methodologies can help when planned carefully on asneeded basis Which would you choose? 29

30 An Agile workforce is needed to implement Agile People will power your Agile success Internal Agile Training (core team) External Agile Training Procurement Executives and leadership Build Agile culture and work environment 30

31 Collect, measure data and course correct Agile provides a wealth of measurement data Core management measures productivity (velocity) predictability (sprint plan variance) unplanned work (defect density) integrity (test case coverage/execution) Can track real progress, not just selfreported status (i.e. Definition of Ready) Use metrics and root cause analysis to implement continuous improvement 31

32 Agile is not a panacea to solve all problems Pitfalls of large modernization projects still remain Business Process Reengineering (BPR) and Organizational Change Management (OCM) are still needed Project Management, Risk Management and Communication are important Requirements and Testing are still critical Why do projects fail? 32

33 Agile Lessons Learned - Key Takeaways Go beyond buzz words, be serious about adoption Agile can scale to enterprise level Agile will coexist with other methodologies Collect, measure data and course correct Build Agile workforce and embrace culture change Eliminate "dirty dozen" even if your are Agile 33

34 Grant Thornton Points of Contact Udghosh Bhambore Senior Manager T (direct) E udghosh.bhambore@us.gt.com W Scott Dalessio Senior Manager T (direct) E scott.dalessio@us.gt.com W Graeme Finley Managing Director T (direct) E graeme.finley@us.gt.com W 34

35 Questions and Consultation Period