Why Reverse Engineering Requirements Beats the RFP

 In All Things Productivity, Blog


RFP v Pilot Value Comparison


Back in a time when vendors only released a new version every 3 years the RFP approach to buying software made a lot of sense. Everything was defined up front, documented in the RFP, and then handed over to the vendors. Vendors responded with proposals. The software was selected and implemented. The RFP requirements, vendor selection criteria, and even the vendor’s development model all followed a Waterfall methodology.

However, this traditional RFP-driven vendor selection process is now considered heavyweight and often has undesirable outcomes:

  1. The RFP process is time and resource consuming. Kate Leggett from Forrester estimates that vendor selection projects take 12 to 18 months to complete. The effort involved to compile detailed requirements often produces something resembling a programming specification rather than a concise statement of business process needs. The internal cost to produce a RFP with detailed requirements can run above $1,350,000 in enterprises today.
  2. Outcomes are often undesirable. The more onerous the RFP process, the more likely it is that nothing will be done and the status quo remains. Well-known CEB research states that customers are already 57% through the purchase process before they approach a supplier. But what happens in the first 57%? Buyers spend a huge amount of time struggling to identify and define the problems they need to solve and they are trying to align themselves and their priorities with their colleagues in order to reach common ground and execute on ideas. The fact is that most projects die even before a vendor is brought into the conversation.
  3. Failure to differentiate among mature products or identify innovators. A holdover from the Waterfall days. RFPs only include requirements that buyers can envision now and generally look quite similar to capabilities that vendors can deliver in current releases rather than more visionary features that don’t exist in many products today. Chris Doig at CIO Magazine says that unknown requirements are those that the software buyer doesn’t know they need. They usually surface as problems during software implementation, where workarounds can cause delays and cost overruns and outright failures.

This is just the beginning. Budget overruns, stumbling blocks, and unhappy buyers are rife in the RFP process. The RFP process increases the likelihood of a bad business outcome and these issues have been well documented and I recommend 18 enterprise software selection risks and how to avoid them and Why the Waterfall RFP Kills Most IT Projects if you want to read more.

RFP v Reverse Engineering Opportunity Costs

The costs associated with the RFP process can far outweigh a pilot program. When you consider the time each member of your team will have to invest in a lengthy RFP process and factor in implementation, roll out and opportunity costs, the risk/reward of the project becomes a serious business matter.


Move Learning Earlier in the Selection Process

build-measure-learnThe world has changed and long drawn out selection processes, just like long drawn out development cycles, are no longer useful. The world just moves too fast for this way of doing business. Because 60% of initial requirements change throughout an average development project, being flexible to change is key to making sure a project is successful in meeting your customer’s needs.

Companies pilot and try out software before embarking on big expensive projects. Piloting software surfaces unknown user requirements and helps project leads reverse engineering their real user requirements. Unlike the Waterfall methodology where you are required to go through each phase only after finishing the prior phase, an iterative pilot model allows you to come back to previous phase(s) whenever you need to, revamp anything that needs revamping and it allows you to catch and fix mistakes early on.

Increase the probability of a good business outcome by moving learning earlier in the software selection process, move it to before the purchase. A pilot gets you better requirements in less time, it gives your user base the opportunity to ask better questions, real life questions based on their experience with a solution. Whenever new requirements are discovered they can be added to the system. Project managers get real world feedback and are forced to think through issues which otherwise would have been overlooked in an RFP.


Recent Posts

Start typing and press Enter to search