ITP Techblog

The IT industry has been asking for major changes to how Government procures software for some time. To address this, IITP has been working with MBIE on an innovative approach to software procurement for one particular project, and we're delighted that the RFP has just been released.

Yesterday the Ministry of Business, Innovation and Employment (MBIE) and the NZ Police launched a Request for Proposals for the development of an Emergency Response System - a mobile 111 app and related technology. But 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 this project. 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

The procurement process for the project is based on a variant of Qualifications-based Selection (QBS), which we've raised several times recently (such as here), following some initial research by John Rusk (some of the rationale outlined back in 2013 here).

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.

On paper, QBS is considered to be far 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.

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

Those reading the RFP will notice that the requirements of the final product aren't specified, 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.

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 up front. 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"

The selection process above ranks respondents based on set criteria. As mentioned above, these criteria are designed to find the most compatible partner who can show they can deliver results, rather than procuring a product or solution.

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 based on this, 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 will then negotiate 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

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.

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

While not unique to this RFP, strong emphasis has been put on the actual people who would be involved in delivering the outcome, including their track record, background, knowledge, qualifications and experience.

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 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.

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.

 

Summary

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. While this is a one-off of course, we're very happy to have helped make this happen and hope it will lead to broader changes over time.

Is the model perfect? Probably not. But it's a very real and solid 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 look closely at being a part of it, either on their own or in partnership with cloud, infrastructure or other providers.

And lastly, this innovation in procurement has been championed by Minister Amy Adams who should be absolutely congratulated for seeing it through, along with Minister Nikki Kaye. A big thanks to both Ministers for supporting this, and good on the New Zealand Government for giving it a go. We can't keep doing the same thing and expecting different results, and taking a traditional approach to software procurement simply ain't working well enough.

Let's see what a little innovation and kiwi ingenuity can achieve.

 

You can 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.