Public sector software procurement: why it’s still broken

First of all everybody knows that most big software projects fail.  It’s simple: the complexity is too big in relation to the rate of change (therefore unpredictability).  The other problem with big projects is that smaller vendors (i.e. most of the ones in NZ) tend to have very little chance of getting involved (in Europe they are waking up to this problem).  The answer is obvious to most people in the industry (hint: break up into small projects, as smart folks like Rod Drury and Ben Gracewood have explained recently).    

I don’t think the new rules help to address the project size problem however that’s probably a rant for another day.  So let’s focus on procurement for smaller software projects that should have a reasonable chance of succeeding (I’m thinking around $NZ40,000 - $NZ400,000).

This process works generally pretty well when the business is able to clearly define core requirements that roughly map to a number of popular, typically reasonably slow moving, commercial off-the-shelf products (COTS).  Examples are DMS, CRM, CMS, LMS, Accounting, (dare I say it Payroll but for lots of reasons clearly Novapay wasn’t COTS) systems etc.  

This generally implies that the purchaser wants a product that lots of other people are already using and is willing to adapt business requirements to how the product functions (both now and in the future).   

So we are talking about the sorts of software project which involves smart technology specialists (generally the vendor) and smart domain experts (generally the purchaser) putting their heads together to create a software solution that achieves some business outcomes.   

These projects require innovation / creativity, a “one team” approach and would typically follow an Agile / Lean Startup methodology that focuses on getting working software out to real users quickly to validate assumptions.  

Given the increasing rate of change in the web / mobile world, the now relatively short short lifetime of any solution and the rise of the “meta solution” that is made up of connected cloud based components (e.g. Google maps, Xero, Mailchimp etc) I believe that more and more software projects are falling into this category.

• Vendors who have lots of time on their hands respond (perhaps because they are not very good or they are new).

• Once the vendor has finally been selected the project is now setup to fail.  Purchaser and vendor straight away move into combat mode where each starts arguing over the detail of what was signed in the contract.  Often it’s the difficult to define non-functional requirements (e.g. usability, security, scalability etc) and the inevitable missed but vital functional requirements that cause the biggest conflicts.

So what’s the alternative?   

The current trend seems to be creating supplier panels which can help in some respects but also has a whole lot of problems which I won’t go into now.  I believe purchasers need to think differently: they’re not trying to buy something, they are trying to select a vendor partner who they can work with to achieve some outcomes (and build a long-term relationship).  In the procurement rules it clearly states that the purchaser must select a capable vendor that gives the “best value for money” or “lowest price”.   

This reinforces the message that the purchaser must get a fixed cost for a fixed scope of work (otherwise how could they assess value for money or lowest price from RFP responses).  At the heart of the problem is that the vendor cannot (and should not) give a fixed price and fixed scope at the RFP stage.  History shows us that if vendors are forced to do this then they make stuff up with often disastrous consequences.

So if we accept that fixing scope and cost is a really bad idea at RFP stage then how can we achieve a procurement process that ensures that the purchaser fairly selects the best vendor and gets the best value for money over the lifetime of the relationship with the vendor.  

There is obviously the housekeeping stuff like size of company, stability, skillsets offered etc but the most important part is speaking to actual current and previous clients.  For smaller vendors (under 30 people) will they let you talk to all their clients over the last couple of years (including the projects that haven’t gone so well).  For larger vendors it becomes more important to identify and speak to the current / previous clients of the team / department who the purchaser will be working with.

The reality is that no purchaser (especially a government agency) wants to give a vendor an open cheque book.  So if the vendor hasn’t committed to a fixed scope/cost before contracts are signed then how does the purchaser ensure that they are picking a vendor who will always give great value for money?  Well actually they can’t, however what they can to is to put in place strong incentives to do so (and a way out if they don’t).  At the heart of these incentives are contestability and risk-sharing.   

Contestability essentially means that the purchaser can replace the vendor at any time in the project.  

Nobody wants this to happen but it is vital that it can happen.  In order for this to happen there must be no IP or other contractual barriers (i.e. no lock-in by using proprietary or obscure technology) and there must be other vendors able to take over if necessary.  Modern Agile methodologies have a “sprint” cycle of between two to four weeks where working/tested software is created every cycle.  

With agreed conditions the purchaser should have the ability to switch vendors at the end of any sprint.  Having an independent expert to periodically ensure that the vendor isn’t gradually maneuvering things into a lock-in situation can be a good idea.  

• Short-listed vendors (between two and three) could be paid a fixed amount to undertake the first part of their process that focuses on scoping, ideation and sometimes prototyping (undertaken by the proposed team members).   This is the perfect opportunity to asses how the purchaser/vendor project team will work together, plus gives the team an opportunity to explore high level options and create realistic scope/cost estimates.  The purchaser will gain a huge amount of knowledge along the way (in some cases this knowledge will cause them to abort or radically change the project at that point - potentially saving a lot of money)

I would argue that public sector organisations owe it to the taxpayer to do better in this space due to the potential cost savings and improvements in online public sector services.  Government towns like Wellington can reap huge benefits if better partnerships between government agencies and software vendors can be built.  

If we can get this right and software vendors can be encouraged/helped to commercialise and export the intellectual property gained then it could have a major positive effect on the local and New Zealand economy.

Mark Pascall is the Director of 3months, a Wellington based web and mobile software development company. For over 20 years he has been involved in public and private sector software procurement processes as both a purchaser and vendor.