As the person who authored the RFP, there’s nothing more frustrating than reading vendor responses that are all over the map, making you wonder if anyone even read your document. How could they have misunderstood so much? Why did they give you so little detail about the very thing you were asking for? Meanwhile for the respondent, sometimes what’s being asked is a mystery.
When it comes to how to write an RFP (Request for Proposal), or an RFI (Request for Information) or RFQ (Request for Quote), it’s as much about the art of communication as it is about the technical details.
1. What is it you need again? – Clearly define the vision for the RFP
While most RFPs have a section up front for vision and need, surprisingly few use it in a clear way. Unfortunately, that rarely leaves the reader prepared to absorb the rest of the document.
All too often, the stated vision and need are tangled together and written so vaguely, that they are a missed opportunity to provide context for everything else to come in the document. Even if the responding companies have experience with your organization, the person or team responding to the RFP may or may not need a refresher. Stating a vision is great, but don’t forget to state clearly what it is you need. It doesn’t matter if it’s a paragraph instead of a sentence, as long as it is clear.
Consider the typical example:
“Our aging customer portal provides self-service functionality. We are looking to apply lessons learned and expand our business.”
Versus a clearer:
“Our existing customer portal centers on self-service functionality (e.g. placing and tracking orders, logging support tickets). Its technology is coming to the end of life. We are seeking a replacement that provides more than like-for-like functionality. We will be incorporating lessons learned in terms of improved user flow, business processes, as well as offering three key new services: X, Y, Z.”
2. Understand What You Actually Completed – A Dive into Requirements Gathering
As much as possible, we all want to provide responders with enough information to help drive down project cost, risk, and timeline. In doing that, requirements gathering may be done internally, which can be quite helpful. However, all too often, project owners state in the RFP and firmly believe that the requirements gathering stage is complete. This misses a few key understandings; let’s quickly delve into a couple of them.
Building context and confirming needs
Even armed with the best internal requirements, the successful vendor will likely need to build context with the business to properly understand the requirements. One reason for this is building relationships between the vendor’s team and the business. However, what’s more important, is surfacing implied assumptions that can have a significant impact on complexity, risk, and the timeline.
Different Process, Different Mindset
RFPs are a vehicle for inviting responders to provide expertise in areas that we don’t specialize in. This means that vendors will likely ask different questions that align with their process, which helps reduce the chances of surprises later. Remove this time in the RFP, and you’ll find it secretly showing up in design or somewhere else.
If you’ve gone through a requirements gathering exercise, this advice isn’t about letting the vendor then redo the entire thing. Rather, expect the responding proposals to have adequate time in their proposal to review, clarify, and confirm what was internally discovered.
3. The Most Assumed Away Requirement of Them All – Secret to Controlling Costs
Last of the 3 classic pitfalls for this article is forgetting this one vital requirement in any software RFP. Many clients assume or think it is self-evident that this one functionality is needed, only to realize that the responders took it out of scope and out of cost. Worse yet, sometimes even when the functionality is clearly stated, responders wrap it up under assumptions. That requirement? Migration.
Replacing an existing system with a new one is never a simple task. However, it is easy to forget that moving content from a legacy system to the new application can dwarf the implementation cost if you’re not careful. Migrations are fraught with complexity and risk, which is why unless it’s explicitly called out, many responders will not put them in scope.
When you’re planning on putting in migration details, it’s worthwhile doing an exercise to help determine what’s the likely percentage of the content that’s needed. For example, consider if you need every file from 2009 onwards, or does your organization only use 10% of that? Do workflows need to be mapped form the old system to the new one? Or, will that work be closed out before migration? Answering these questions in an RFP can reduce complexity, add clarity, and help responders better evaluate the risks and costs.
The best advice above all others?
Write the draft of your RFP from your point of view, then revise it from the responders’ perspective.
Looking at it through their eyes will help you identify areas where you are missing context, hiding assumptions, and setting yourself up to get a response that isn’t exactly what you’re looking for.
Need help with building or replacing a software application? Discover how we help our clients leverage technology to meet business needs.