It’s time for another adventure into the world of Business Analysis (I know you’re excited). In this blog I’m going to be discussing the process for developing a RFP, which you probably know stands for “Request for Proposal.” I often interact with RFPs both in terms of creating them and responding to them. RFPs are utilized to solicit potential vendors for the purchase of a good or service. For instance, if your organization needed a new computer system for payroll, you would write an RFP to solicit vendors capable of completing the task.
One reason it can be so difficult to write a RFP is that the information in the RFP does not explain how the system will function, but rather what the system needs to do. (See What Does Your System Require? for defining how a system will function.) Now I know how your curious minds work Dear Readers, you are wondering:
- Who? needs to be involved in helping you write the RFP
- How? you should approach writing the RFP
The Who?
If you have been charged in writing a RFP, one of the first questions you ask yourself is who else needs to be involved? Well the first people you need are the stakeholders, and not just management, but those people who will be using the new system. As a Business Analyst it has been my experience that when members of an organization are tasked with writing a RFP, they can find it difficult. The reason is that deriving this information can become complicated if there are many stakeholders involved. In those instances, everyone wants to make sure their needs are voiced and met. So who else might need to be involved? The answer is an objective third party. Bringing in an objective third party can be of great assistance in this process since they are neutral and have no reason to put one stakeholder’s needs over another’s.
The How?
How do you start to write a RFP? Meet with all the stakeholders, both separate and en mass. Sitting down and allowing everyone to express their needs and desires (and documenting them), provides a basis for writing the RFP. As more and more details are voiced and explained, a clearer picture of the needs of the system begins to emerge. The next step involves sifting through all the information to define what the system will need to do at launch, what aspects are “must haves” and what other aspects are “nice to haves.” For example if you were writing a RFP to purchase a new coffee maker, you would not want to include that it should fry eggs. But you might want to include that it have an automatic timer. Can you still make coffee without the timer, yes, but it would be “nice to have” a timer. Both must haves and nice to haves can be included in the RFP, but making a clear delineation helps create a concise, well thought out design (scope of the project) and can help to contain the cost.
So now you are ready for your own RFP adventure, but if you need a guide, please give me a call.

Posted by Dawn Bott 








