Software and Procurement. Paul Matthews, IITP Chief Executive

Transcription

1 Software and Procurement Paul Matthews, IITP Chief Executive

2 This is not A Procurement Presentation

3 Detailed review of international research + Survey of 534 New Zealand software and procurement professionals

4 What s the problem? Why software projects fail Context of traditional procurement Is there another way?

5 What s the problem?

6 IT Project success and failure 21% 42% 37% Major cost/time/functionality issues Canceled before completion Success Source: The Chaos Report 2012

7 Project success over time 60% 50% 40% 30% 20% 10% Successful Failed Challenged 0% Source: The Chaos Reports and Manfesto

8 Other software project stats: McKinsey (2012) Average cost overrun: 66% Average time overrun: 33% Limited functionality: 17% Gartner (2012) Project failure: 20-28% Heavily reliant on project size McKinsey. (2012). Delivering large-scale IT projects on time, on budget, and on value. Gartner. (2012). Survey Shows Why Projects Fail. In L. Mieritz (Ed.): Gartner.

9 Fact 1: Too many software projects fail. Few would argue that something isn t wrong software projects are failing at an alarming rate.

10 But why?

11 Why projects fail 27% 23% 4% 42% Leadership Organisation & Culture People Issues Technology Source: Organisation Dynamics / Jim Markowsky

12 Success vs Failure: 5 Characteristics Size Complexity Methodology (eg Agile vs Waterfall) Cost Estimation Team culture

13 Results by project size 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 71% Under $900k 38% $900k to $3.6M 19% $3.6M to $12M More than $12M 2% Failure Success Converted to NZD - Source: The Chaos Report 2010

14 Fact 2: Big, complex projects usually fail. Another context: Our current approach to large and complex software projects doesn t work.

15 Cost estimation

16 How often is price estimation right? 70% 60% 50% 40% 30% 20% 10% 0% Never Sometimes Usually Always Small Large Source: IITP Software and Procurement Survey (2014)

17 How often is price estimation right? 70% 60% 50% 40% 30% 20% 10% 0% Never Sometimes Usually Always Large Source: IITP Software and Procurement Survey (2014)

18 Vendor reaction to price overrun 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Do Nothing Renegotiate Cut corners Inflate costs Withdraw Small Large Source: IITP Software and Procurement Survey (2014)

19 Fact 3: We generally can t predict the cost of [complex] software up front. So Why do we use cost as a criteria?

20 Agile Methodologies

21 Project success over time 60% 50% 40% 30% 20% 10% Successful Failed Challenged 0% Source: The Chaos Reports and Manfesto

22 Project success over time 60% 50% 40% 30% 20% 10% 0% 2% of all 5% of new 9% of all 22% of new Successful Failed Challenged Source: The Chaos Reports and Manfesto

23 Source: The Chaos Manfesto 2012

24 Agile and NZ Procurement Compatibility 80% 70% 60% 50% 40% 30% 20% 10% 0% Not compatible Reasonably Very Source: Those with Agile experience from IITP Software and Procurement Survey (2014)

25 Fact 4: Agile works better for software. Agile succeeds 3x as often as Waterfall, but isn t very compatible with how we [currently] procure software.

26 To summarise

27 Too many software projects fail. Big, complex projects usually fail. We generally can t predict the cost of [complex] software up front. Agile works better for software.

28 Software Procurement in NZ Mandated competitive cost-based approach for larger projects.

29 Agile and NZ Procurement Compatibility 80% 70% 60% 50% 40% 30% 20% 10% 0% Not compatible Reasonably Very Source: Those with Agile experience from IITP Software and Procurement Survey (2014)

30 How often is price estimation right? Never Sometimes Usually Always Large Source: IITP Software and Procurement Survey (2014)

31 Vendor reaction to price overrun 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Do Nothing Renegotiate Cut corners Inflate costs Withdraw Small Large Source: IITP Software and Procurement Survey (2014)

32 Urk!

33 Qualifications-Based Selection(QBS) Find a partner, not a solution Qualification approach No price discussions Then pricing *terms* discussed

34 Qualifications Based Selection Completely compatible with Agile Deals with cost estimation issues Deals with scope changes Ideal for large and complex projects

35 Usage

36 NZ Roading Projects High Risk and Complex Alliance Model (= QBS) Risk and Complexity Risk and Innovation Design and Build Low Risk Traditional Procurement

37 Fact 5: QBS is a credible alternative Qualifications-Based Selection is proven successful in high-complexity scenarios, and deals with the big 5.

38 QBS in the Alliance Model has a 100% success rate in the NZ roading sector

39 Questions

40

41 Thanks!