Price-based tendering to blame for Novopay?
Is a procurement process weighted too heavily towards the lowest price to blame for major IT project failures in Government? Can the problems we're now seeing with software projects like Novopay be traced right back to price-based tendering and if so, is there a better way? This week John Rusk explores an alternative approach to government tendering, where price is an afterthought but huge savings are made. Sound whacky? The US federal Government doesn't think so - they've been using it for engineering since 1972.
In the tender process for payroll in schools, we're all left wondering what price the losing bidders quoted. Was Talent2 the lowest bidder and was that the main reason they won? And if so, does the fact the project has now cost millions more, and all the other problems to date, prove that the procurement was a failure?
Until recently I worked as a software architect for various Wellington IT vendors. I was one of the geeks who came up with the prices; we'd estimate how many person-hours the project would require (using black arts which I can't possibly disclose here). Then we'd debate with Sales and Management to arrive at the final fixed price, propose it to the customer, and maybe win the work.
After 15 years as an insider, I can say one thing with certainty: awarding contracts to the lowest bidder is optimistic at best, and dangerous at worst.
So why do it? Why award software contracts based on price?
There are many reasons. To pick just one: decision makers believe it works in "real" engineering - making bridges, roads and buildings - so should work for software too. But it doesn't. Although it is widely used in engineering, it's not widely successful!
The Truth about Engineering
A friend used to give me her old copies of e.nz, the magazine of New Zealand's Institute of Professional Engineers, due to my strong interest in what was going on in "real" engineering (of the buildings and bridges kind). In 2005 I was struck by an article which stated that "the indiscriminate urge for lowest price" leads to "late and unsatisfactory completion, disputes and litigation"; It almost sounded like software and I've been thinking differently about this ever since.
The New Zealand Construction Industry Council said that "the lowest-bid approach is compromising design quality and integrity, health and safety, training, the environment… [Furthermore,] the lowest bid approach encourages unsustainable markets".
Discussing solutions to these problems, e.nz explained that: "A substantial culture change is involved in progressing towards best practice in procurement. All stakeholders must accept that they have a duty to collaborate towards a common objective: the full satisfaction of the project's objectives, in exchange for fair rewards for all who contributed."
Why is the Lowest Price Dangerous?
The lowest price is dangerous because you don't know why it's low. In the software industry a company may offer a low quote for any of the following reasons:
- They have misunderstood the difficulty of the task.
- They understand the task, however the estimate is low simply because software estimation is inherently difficult.
- They understand the task and are deliberately bidding low because they're eager (or desperate) for your business.
- They understand the task and have outstanding skills and technology which will allow them to complete it quickly.
Only the last reason is a good one. The others, to greater or lesser degrees, may all threaten your project. Yet in terms of price, they look the same.
So How Do You Tell the Difference?
You have to base your decision on assessments of the supplier's capability: the quality of their staff, the quality of their technology, their openness and honesty with customers and their overall track record.
Price tells you nothing about capability. A low price may signal superior capability (reason 4), inferior capability (reason 1), desperation (reason 3), or nothing (reason 2).
A Better "Real" Engineering Practice to Emulate
If we want to emulate "real" Engineering we would be better to take our lead from the US federal government. Since 1972, price-based selection for engineering services has been prohibited for federal government agencies, with selection being based on supplier quality instead. It should be pointed out that this only applies to design services in "hard" engineering. Interestingly, until the 90s software was specifically required to be price-based - in an attempt to break the monopoly IBM was perceived as having.
The non-price approach has proved highly successful and has been widely emulated by state governments in their own procurement of design services for buildings, bridges and other engineering works.
The name of this approach is "Qualifications-Based Selection" (QBS), because it's all about choosing the vendor who is best qualified (most capable) to perform the work.
QBS reflects an understanding of the risks noted above - that price tells you nothing about capability. It may also reflect an awareness of just how embarrassing price-based selection would be after a major engineering disaster.
Imagine a TV interview shortly after the collapse of a bridge:
Reporter: So how did you award the contract?
Official: We… errrr…chose the cheapest.
Indeed. It will certainly be interesting to see the answer to that question during the Novopay review. Not to point the finger at any individual of course, but to question the very process we use to award IT contracts in New Zealand.
Could We Use Qualifications-Based Selection (QBS) in NZ?
QBS is ideally suited to public sector procurement. The American Institute of Architects, California Council, says:
"[The] process is straightforward and easy to implement. It is objective and fair. It can be well documented, and it is open to public scrutiny."
QBS meets the public owner's primary concerns to get the best available professional services for the taxpayers' money and to conduct a fair and equitable selection process."
If this can be emulated, it certainly sounds like a good formula.
How does QBS work?
QBS can be summarised as follows.
- During the tender process the customer can ask any question they like… except price. They must choose the best, most competent supplier based entirely on non-price criteria.
- Once they have officially selected a preferred supplier, only then are they allowed to begin price negotiation with that supplier.
- If it proves impossible to reach agreement on price then, and only then, are they allowed to abandon their first choice and start discussing price with their second choice.
Procurement in New Zealand
To New Zealand ears, this all sounds a little odd. We like to think that making suppliers compete with each other on price is a major goal of the tender process. Make the vendors compete, then lock the winner into their quoted price. That's our recipe for success.
But it's a lie. After 15 years on the inside, I know it's a lie. In the industry, we all know. But we dare not say, because our sales and livelihoods depend on playing by the rules of the game; no matter how flawed that game might be.
But with Hon Steven Joyce now hinting at a review of how tendering works for software in Government, perhaps it's finally time for this to change.
Once in a while, we're lucky. We get a stark reminder that nailing a vendor down to a price does not guarantee (or even encourage) project success. Will the latest example of this prove to be Novopay? Time will tell.
If it does and we're really lucky, it might also be a catalyst for change.
John Rusk is a senior software professional based in Wellington.
You must be logged in in order to post comments. Log In