ITP Techblog

Brought to you by IT Professionals NZ
« Back to Home

Is the Government RFP process broken?

Software vendor CEO. 31 May 2012, 4:03 pm
Is the Government RFP process broken?

In last week's Newsline Juha Saarinen discussed an article from TradeMe's Mike O'Donnell about the RFP process. We were contacted by a number of New Zealand vendors with similar concerns. This commentary outlines in detail some of the problems from the perspective of a CEO of a medium-sized company with a history of dealing with Government. For obvious reasons the author has chosen to remain anonymous.

I read and agree with both Juha and Mike O'Donnell's comments about the RFP process. I also believe that, while the problems aren't confined solely to government projects in their many forms, which are where much of the difficulty lies.

It isn't just a question of whether they're paying too much or getting value, it's also very much about whether they're getting the right solution - a point you made when referring to the number of smaller vendors who aren't prepared to jump through the many hoops to get to a sale.

Speaking as a small-medium vendor with many government clients, but not many new ones in the last two years, it isn't that we're lazy or can't be bothered. It's that we recognise the futility of playing that game. I suggest that the RFP model is broken and that it not only doesn't guarantee that a client will get the best product, vendor and value; it almost guarantees that they won't.

I won't bore you with tales of woe from a disappointed vendor that was found wanting by a robust process - I haven't got any.  I do have plenty of cautionary tales about the process government departments use to identify, evaluate and select technology solutions in our space; each of them represents a huge amount of wasted time and effort and in the majority of cases no solution was purchased or implemented.

In our business we now almost never choose to respond to an RFP, even when directly asked to and even when we can see that there's a really good fit between the stated requirements and our product.

We've seen a number where the consultant writing the RFP document almost certainly based their requirements on our product, and where we have a number of good reference clients with nice stories to tell and a clear value proposition.

Why don't we reply? Because it's a complete waste of time and effort, and now when my BDM suggests we respond to one that looks right in our sweet spot, I tell him to simply bang his head against the wall for half an hour, while cutting up $20 notes. It's invariably cheaper and the pain stops much sooner.

Enough grizzles - what's wrong with the RFP process?

Disconnect between user and consultant

In our particular sub-vertical, the business unit is almost never skilled or experienced enough to write its own RFPs. So, a consultant is employed, usually an external one but sometimes internal and in those cases almost always from IT.

The consultant invariably knows very little about the business unit's requirements, so the stated requirements are either far too general or far too detailed. The general ones contain a wish-list of everything they want and have ever dreamed of, the lists come out of the bottom drawers and you end up with a requirement that can be summarised in one word: everything.

The detailed ones show clearly that either there's an amateur BA in the business unit (or it's the consultant) that is designing the solution they want you to build, or else they want their new system to look and behave just like their old system. 

Process too long, unsuitable players enter and cause confusion

In many cases the consultant is unaware of the key players in the market, so they start with an EOI or RFI to identify who might have a solution. Often they will write the RFP based on what they've seen and think they like, rather than what the business unit needs.

This gets the process off on the wrong foot, and also lengthens it considerably. It also allows fringe players that troll through GETS and TenderLink every day, the opportunity to submit a response using an international solution that may not be fit for NZ use, or with no other or very few clients in this territory.


Big IT vendors (the ones that usually price-gouge) will have teams of MBAs and response writers to submit highly polished responses with graphs and charts and value propositions for Africa. Most times they will tell lies in the RFP response, playing the eternal game of bluff and double-bluff.

This game is where, at the product demonstration, the vendor really hopes the client doesn't refer to the RFP response and ask to see function points demonstrated that don't exist, even though they ticked Yes - fully complies.

Then, once the sale is made and the first workshop is about to start, the client really hopes the vendor doesn't refer to the client's RFP where it stated what they wanted - because what they really want is something else entirely.


Lack of commitment and follow-through by the client, caused by a range of things - laziness, inertia, incompetence, changing budgets or priorities, change of staff, change of circumstances, consultant got called off on something else, late intervention by IT who decide they can build it quicker and cheaper (ha!). I believe this is the most significant factor in the recent RFPs I've been involved in.


I agree that RFPs are becoming too prescriptive, even though a lot of them contain more boiler-plate terms and conditions than actual requirements. There are so many assumptions that a potential vendor has to make (and isn't allowed to seek clarification on) that any pricing is often a complete guess.

Because there is so much complexity (trust me, 88 pages is not long at all), vendors of all sizes have to perform a balancing act where they don't want to sell themselves short by pitching too low and getting stung when the workload turns out to be much higher, and they don't want to go too high and risk being eliminated on price.

The other problem with complexity is that it's just too hard to see the value. When you have 280 function points to respond to and another 100 or so non-functional requirements, how can the consultant or steering committee discern the value of one solution over another?


You're spot on when you say that clients want to be part of a big-budget long-term project, rather than a low-budget short-term one. They also often prefer to deal with big-name suppliers and products rather than the smaller guy.

They're less concerned about the right fit for the business and the best value than they are about backing the wrong horse or not getting to work with the latest technology.

What's the alternative? Amongst all the horror stories I have some success. A prospective client contacted me a while ago to get some information and indicative pricing for one of our products. I qualified them in the usual way and spent some time understanding their requirements before doing a high-level overview of the solution, triggering further positive discussions about how it might help their organisation in a range of different ways.

My heart sank when they emailed some time later to say that the information was very useful and would definitely help them to write the RFP which was expected to come out in several months' time. I took a punt and told them that running an RFP was a really bad idea and that I knew a much better way that would help them get to the point where they knew if they had the right vendor and product much earlier.

They asked what it was and I told them to run a pilot. Agree on the dates, timing and scope of the pilot, establish the desired outcomes and how they would be measured, and agree responsibilities and costs. The client is paying for the costs of the trial - we're supplying trial licences for free but charging for set-up, training and hosting costs for the two-month trial period. It makes so much more sense to identify a product and vendor that you feel comfortable working with, and then let the rubber hit the road.

There's no quicker way to find out if the product is going to meet your needs than to start using it.

Asking a consultant to write a long and complex RFP document (or EOI, RFI, RFT) and then having an arm's length evaluation where you're only seeing what the vendor wants you to see, and you're not putting your hands on the solution, produces the predictably poor results we've seen time and time again.

And don't get me started on the large percentage of government organisations that run these RFP projects and end up doing nothing. Sometimes on more than one occasion, as in the case of one government department which ran an almost-identical RFP process three times in six years and still did nothing.

Another large government department is on its second attempt to find a solution in six months, two other departments ran a huge combined RFP that went nowhere, and I still have the letter from a local authority advising that we have won the contract to supply them with our software just as soon as the full Council rubber-stamps it.

 The letter is over eight years old. The local authority still does not have a solution, but has wasted hundreds of thousands of dollars in the meantime trying to firstly adapt a solution totally unsuited for the purpose, then develop their own.

In the meantime the business unit struggles with the wrong tools to do their jobs, and the ratepayers foot the bills.

I seriously believe the RFP process is broken, wasteful and ineffective, and that much better alternatives exist. I'm not crying sour grapes because we missed out on the business - as long as the end users get the tools and systems they want then I don't mind who they buy them from (to a point, of course).

I firmly believe organisations end up with the systems they deserve.

Kind regards

Frustrated CEO (and tax-payer)

We'll continue to explore this issue next week, with an opinion piece from NZRise Co-Chair Don Christie.


You must be logged in in order to post comments. Log In

Perce Harpham 01 June 2012, 9:47 pm

In the Conference book "Return to tomorrow" I have made some refernce to the skulduggery surrounding the award of the software contracr for the Wanganui Computer System. It was a long time ago (1976) but the technical framework had much to commend it.

The RFP was an excellent specification of what the users wanted. Our proposals in response showed how we would meet those requirements and what we would deliver but stopped short of being a detailed specification.

We gave a fixed price for developing a detailed specification in a nine month time frame. State Services then had two weeks in which to accept or reject the specification (which they were given in installments anyway). If they chose to reject the specifcation, with particularity, then they paid us a fixed sum and we went away. They could then go to tender with that spec or however they chose to modify it . If the spec was acepted with our time frame then we would deliver for a fixed sum.

This system worked well. In some cases requested changes in the deliverables could be incorporated. Some were discussed and abandoned as undesirable or better left for later implementation but in other cases we gave costs in time and money for the requested changes. Changes were then almost always rejected.

As a result we delivered on time, on budget, exceeded the specification, made a profit and paid tax.

In spite of this success I do not know if any other Government procurement has ever followed this model.

I am, incidentally, continually bemused at the costs of Government systems, their overruns and inadquecacies in many cases.

Web Development by The Logic Studio