The eye-opener for me quite some years back was discovering that most of the RFPs we saw were the result of an evaluation like the one described, we were being asked to quote, blind, against the firm that had been paid to write the RFQ in the first place.
One tl;dr of this article could be, "Stop responding to RFPs written by your competition and look for opportunities to write the RFPs yourself."
Really for the big customers, the key to doing a project evaluation is to deliver independent value in the evaluation. The evaluation may come in handy even if they do not choose to close. So here you are bringing people in, you are finding out exactly what the problems are and why, and giving the customers tools to think about those problems. Who knows, the evaluation might even cause them to rethink the project direction entirely?
One key advantage to doing project evaluations and charging for them is that you are suddenly a lot more free to tell the customer "We are happy to do this for you, but in our estimate, you don't need a fancy new CMS system at this point. The first thing you need to do is get some more editors and work on your editorial processes. Once those are under control, we can talk about a CMS."
The RFP process optimizes for "not making a bad choice" vs "making the best choice", and is usually also done for transparency / accountability reasons as well.
We're building a new type of eSourcing tool to help make the RFx process faster and more streamlined for vendors / buyers / evaluators, so we've been digging deep into 'structured buying'. It's a lot more complicated than "this process sucks, let's change it".
In our opinion, the problem isn't the process itself (which is necessary for public sector and enterprise) but in how the process is conducted - i.e. the lack of communication, slow decisions, ill-defined evaluation criteria, etc.