Hack-a-Bid: A Solution to the Wasteful RFP Process

The RFP process is expensive, wasteful, and frustrating for both the bidders and the client - often stretching over a year (often including an RFI phase), burning expensive man-months on both sides, and involving long stretches of waiting time. In the end, bidders are still left to estimate on vague or bloated requirements that are still certain to change after the project has started, and the client is still left unsure which vendor will deliver at the right cost. And even after such a long and expensive process, projects fail, or costs and timelines balloon, and people are left angry and crushed.

"Just go Agile" is not a solution for many large organizations, that are still bound by rigid annual budgeting cycles and audit processes. And even organizations that "went Agile" still get poor results, often arising from either choosing the wrong vendor, being unprepared with the business requirements, or both.

So here's my proposed solution - the Hack-a-Bid - an hackathon for project bidding. Both vendors and client set aside two weeks - this sounds like a lot, but much more time is wasted in the RFI/RFP process. They stay in the same location. Each vendor is provided with its own source code repository. Vendors cannot see each other's repos, but the client has read access to all repos. A forum site will be provided which will have the initial project requirements, and will allow everyone to post questions and get answers.

The event kicks off with the client representatives talking about the business needs, constraints, and any defined requirements, followed by an open forum. The teams then break off to start working on their designs and coding away at their solutions. The client representatives remain so that teams can set ad hoc meetings with them. Somebody should be in charge of documenting these meetings so that information that is relevant to all teams (not implementation-specific information) will be posted in the forums.

At the end of the first week, teams are randomly assigned hour-long time slots to present their work privately to the client team and gain feedback. Discussions should include rough estimates to build each of the client's requirements, so that the client team can better assess which requirements are worth building vis-a-vis the costs. The client team takes learnings from the discussions, and uses those learnings to revise and reprioritize requirements for the second week.

The second week is pretty much the same. By the end of the second week, both parties have a better idea of requirements, priorities, costs. The client also better understands the capabilities of each vendor, and vendors better understand how easy or difficult it will be to work with the client, which they can factor into their costs.

Afterwards, the client can proceed with a traditional RFP process, but this time which much better requirements as well as a better idea of the right budget. Or, the client can opt for an "Agile" approach, but this time with a better idea of which vendor to partner with, and with clear requirements to start off.

One thing to note is the composition and authority of the client team. The client team must have authority to revise or create most project requirements, without needing to ask permission from higher authorities. They must of course be knowledgeable of  the needs of the business. And there must be a representative from the company's IT department that can answer technical concerns (e.g. allowable platforms, integration points, etc.).