Software and Procurement Paul Matthews, IITP Chief Executive
This is not A Procurement Presentation
Detailed review of international research + Survey of 534 New Zealand software and procurement professionals
What s the problem? Why software projects fail Context of traditional procurement Is there another way?
What s the problem?
IT Project success and failure 21% 42% 37% Major cost/time/functionality issues Canceled before completion Success Source: The Chaos Report 2012
Project success over time 60% 50% 40% 30% 20% 10% Successful Failed Challenged 0% 1994 1996 1998 2000 2004 2006 2008 2010 2012 Source: The Chaos Reports and Manfesto 1995-2013
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.
Fact 1: Too many software projects fail. Few would argue that something isn t wrong software projects are failing at an alarming rate.
But why?
Why projects fail 27% 23% 4% 42% Leadership Organisation & Culture People Issues Technology Source: Organisation Dynamics / Jim Markowsky
Success vs Failure: 5 Characteristics Size Complexity Methodology (eg Agile vs Waterfall) Cost Estimation Team culture
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
Fact 2: Big, complex projects usually fail. Another context: Our current approach to large and complex software projects doesn t work.
Cost estimation
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)
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)
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)
Fact 3: We generally can t predict the cost of [complex] software up front. So Why do we use cost as a criteria?
Agile Methodologies
Project success over time 60% 50% 40% 30% 20% 10% Successful Failed Challenged 0% 1994 1996 1998 2000 2004 2006 2008 2010 2012 Source: The Chaos Reports and Manfesto 1995-2013
Project success over time 60% 50% 40% 30% 20% 10% 0% 2% of all 5% of new 9% of all 22% of new 1994 1996 1998 2000 2004 2006 2008 2010 2012 Successful Failed Challenged Source: The Chaos Reports and Manfesto 1995-2013
Source: The Chaos Manfesto 2012
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)
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.
To summarise
1 2 3 4 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.
Software Procurement in NZ Mandated competitive cost-based approach for larger projects.
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)
How often is price estimation right? 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 Never Sometimes Usually Always Large Source: IITP Software and Procurement Survey (2014)
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)
Urk!
Qualifications-Based Selection(QBS) Find a partner, not a solution Qualification approach No price discussions Then pricing *terms* discussed
Qualifications Based Selection Completely compatible with Agile Deals with cost estimation issues Deals with scope changes Ideal for large and complex projects
Usage
NZ Roading Projects High Risk and Complex Alliance Model (= QBS) Risk and Complexity Risk and Innovation Design and Build Low Risk Traditional Procurement
Fact 5: QBS is a credible alternative Qualifications-Based Selection is proven successful in high-complexity scenarios, and deals with the big 5.
QBS in the Alliance Model has a 100% success rate in the NZ roading sector
Questions
Thanks! ceo@iitp.org.nz @nzpaulm www.iitp.org.nz
Thanks!