Published on the 19/06/2015 | Written by Paul Matthews
Recently, the MBIE and the NZ Police launched a Request for Proposals for the development of a a mobile 111 app and related technology. But, writes IITP CEO Paul Matthews, this was no ordinary RFP…
IITP has been working behind the scenes over the last few months helping MBIE develop a new approach to software procurement for a new project to develop an Emergency Response System, which will include an app and related technology. While this is a one-off and not technically a pilot or trial for the new approach outlined below, if the project is successful, we believe we’ll see further developments in this space and probable wider adoption. So what makes this procurement different? Qualifications-based selection On paper, QBS is considered to more compatible with Agile development than traditional procurement processes and has been highly successful in other industries overseas when dealing with complex and higher-risk projects, similar to the characteristics of bespoke software. The US federal government has used QBS for complex engineering projects for many years and in NZ, a variant of QBS (called the “Alliance Model”) is used for large and complex roading projects where innovation is needed and the detailed requirements are unknown at the start. Under QBS, the entire focus of the procurement is to find the best provider(s) to work as a partner on the collaborative development of a solution. Price isn’t considered, and in fact is explicitly excluded from consideration during the RFP phase. The only consideration is who would be best able to work with the client and deliver a solution, based on factors such as previous experience and proven results. Importantly, the client is procuring a partner to help develop a solution, not a product. The downside of QBS is that it favours providers with experience, thereby making it a little harder for those without a track record to be selected. However, given its use for complex or higher-risk projects (in this case, emergency service software), this ain’t a bad thing. Innovative providers without the breadth of necessary experience can still get a look-in however, with the RFP explicitly allowing consortia or alliances and the requirements being applied to a consortium accordingly. Outcomes-based collaborative approach As outlined above, the intention is to find the best partner or partners, and to then work with them on designing a potential solution. The clients can then harness the experience, ideas, and innovation of the industry, rather than killing innovation by attempting to specify exactly what the solution will look like upfront. There are also workshops planned where potential partners can explore possibilities and fairly freely discuss opportunities and options – prior to the RFP closing. By talking in terms of outcomes rather than specifications, potential partners are free to do something really special, without the restrictive bounds of traditional procurement. The hope is that this will lead to an outside the box solution, possibly quite different – and superior – to what the client might have been thinking initially. Proof-of-concept “bake-off” Via the QBS process, the 2-3 most compatible partners are selected and will then participate in a proof of concept “bake-off”. The client will work collaboratively and directly with each partner to start to put some ideas on paper, with the partner designing what the outcome and solution might look like as a concept. The partners will then present their proof of concept and one will be chosen to develop the solution. However all partners in the bake-off will be paid whether selected or not, assuming they see the process through and deliver on the proof-of-concept requirements, via a “grant” of $75,000 each. The client then negotiates the development terms, including cost, with the preferred partner. If terms can’t be reached, the client will likely commence negotiations with the next-placed provider and, assuming an agreement can be reached either way, development of the full solution will commence. Agile approach We know two things about Agile and procurement: (1) it generally leads to far better results in software development, for example with Standish finding it leads to 1/3 of the project failures of traditional waterfall-based methodologies, and (2) genuine Agile is not particularly compatible with traditional “price and specs up front” procurement. We also know that when price-up-front is mandated, it almost never equals the cost of a project at completion, especially for complex projects. So why do we continue to use it as a selection criteria in software procurement? We believe the evidence shows we’re far more likely to see good results by worrying about cost only once we actually know what the solution is really going to look like, with providers focused on innovating rather than selling during at least the initial phases. Focus on the people delivering solutions From IITP’s perspective, it has to be about the people; people and teams deliver solutions, not brands. We’re very pleased to see this focus and while there isn’t a requirement for Chartered IT Professional NZ accreditation from respondents, we would certainly hope to see people at that level involved in leading the project. Intellectual Property The long and short is that rather than it being seen as a one-off, our hope is that the project will turn into something far larger and contribute to the development and growth of the NZ industry. A major step forward Is the model perfect? Probably not. But it’s a real and serious step towards addressing many of the well-documented problems with software procurement by government. We see this as a real opportunity for our industry and strongly encourage innovative app developers to seriously look at being a part of it, either on their own or in partnership with cloud, infrastructure or other providers. View the summary on GETS here. IMPORTANT NOTE: This article is for information only, and should be considered good faith opinion only. IITP is commenting on the process contained in the RFP released yesterday, and is not procuring the solution – that’s MBIE and NZ Police. Thus, where anything written here differs from the detail in the Request for Proposal, please consider the RFP correct. ABOUT PAUL MATTHEWS//
The procurement process for the project is based on a variant of Qualifications-based Selection.
The requirements of the final product aren’t specified in the RFP other than in fairly general terms including a couple of bottom-line features and outcomes. The intention is to take an outcomes-based approach; MBIE and NZ Police don’t have a monopoly on good ideas, and the whole structure is designed to support and encourage innovative thinking from potential partners.
The selection process ranks respondents based on set criteria designed to find the most compatible partner which can show it can deliver results, rather than procuring a product or solution.
Compatibility with Agile development is implicit in the design of the process, and while Agile is certainly not mandatory, compatibility has been considered at every stage of the RFP and development process.
While not unique to this RFP, strong emphasis has been put on the actual people who will be involved in delivering the outcome, including their track record, background, knowledge, qualifications and experience.
The government will be granted a permanent license to use any IP generated during development, however the resulting IP will be owned by the partner. This means the partner can freely turn it into a broader product or service and go forth and export – sell it to other Governments, bundle it into other offerings, evolve it into something else, or even open-source it if they’d prefer.
We believe the approach taken is a major step forward in the procurement of software in New Zealand, and we’re seriously impressed with the collaborative approach and focus on industry-supported innovative procurement from MBIE.
Paul Matthews is chief executive of the Institute of IT
