RFP FTW – Kicking the Traditional RFP into Touch
Who here hates RFPs? Have you ever considered that there may be some a good reason for that hatred? Those who request an RFP know what the traditional RFP process requires, but have to be super patient during the process and those who respond to it are very aware that it’s pretty much like playing the lottery. Your chances of getting all the answers right in the way that the requesters asked for is low. It’s a process with broken tools for communicating requirements. Yet you have to try to be in with a chance to be picked.
My view. RFPs (at least the sort of RFP some purists are likely to endorse) are old school and very, very, sadly ineffectual. But why? Well the process can be explained on paper. Neatly. However, get the team to sit through a set of detailed requirements and everyone I know start thinking of matches for eyelids. To put a finer point to it – the process leads people to press through masses of boring work which induces lethargy and as a result means that suboptimal decision making occurs.
And then there is the small matter of a waterfall process (go on…argue that the traditional RFP is not waterfall process). It takes too long to ratify requirements (assuming even that is valid due to all sorts of issues…e.g. when last did you effectively challenge the validity of a business requirement? Have you considered how much money is wasted on non-essential business requirements?). And then in today’s rapidly adapting business world, if you dare do waterfall you are likely to be saddled with a solution that was relevant 6-12 months ago. Exactly!
Alternative? Check. I recently ran what I’d call an agile RFP. Maybe I should write a book and sell it. Title it AgileRFP. It probably is taken already…well, forget about that for a moment!
Here’s how ours went:
- Identified a team of business experts with a vested interest in us getting it right.
- Drew up a scope statement – effectively a high-level requirements document. Quite high level.
- Verified this with the business experts. Verify strategic fit.
- Then declared the intend to pick only a cloud service. OK, some may call this cheating, but it was a generic business domain which is typically not rocket science.
- Gathered a population of options from Gartner, Forrester and Capterra. And Google search. And personal experiences. Starting population was 16.
- Then we reviewed the population’s available brochureware as per their websites for a fit to scope. In this instance whittled down a population of 16 down to 4. Two were added at this point due to executive insight on the one hand and expert personal rating on the other hand.
- Looped back to the business experts. Got their blessing.
- Then went straight to short demonstrations to the business experts with us as moderators. Cramped the available time to present, but it was amazing how well this brought the good systems right to the fore. The overly complex, old systems just couldn’t do it.
- Progress for each demonstration was tracked/marked against the original scope statement. Business experts discussing business fit dominated discussion.
- We were prepared for 2 favourites that would then require in-depth review by the business experts. We had one. The business experts were in love and engaged! We did a deep dive into functional requirements with the business experts on the preferred selection.
- We performed an IT due diligence/hygiene check to ensure the claims of the vendor stacks up.
- We were ready to implement within 6 weeks effort from getting the instruction to get the system.
In a world where waterfall process is no longer useful this approach works well. Paretto principle applies. But it works wonders to do it this way. And the result is a very happy business team. Happy accountants. Happy techies. Happy auditors. Some happy purists…
Call us if you have questions or want us to help kick your waterfall “inna nuts”!