So you have decided to hire a development firm to build your next website, mobile app, or gizmo … great! Now what?
Now it is time to decide how to let them know what you want done. Sounds easy enough right? Not quite. Today we are going to talk about why….
Before we get into the nitty gritty, it is important to define what an RFP actually is. An RFP (Request for Proposal) is a document that outlines the specifications of a new system. It also, typically, includes a bit of background on the company, the motivations for the project, and the deadlines for said project. They are usually as action-packed as they sound.
While an RFP is simple in function the difficulties come in the execution.
The real problem with RFPs isn’t necessarily the document itself but rather the process that goes with it.
Here is a common example.
Company A has a need for a new workflow system. The CEO tasks Jim, the manager, to create an RFP that will describe the system. Jim goes out and creates a great one. He finds a few great firms that he thinks would do a great job and emails them to bid on the proposal. Jim also sets up a 2-week period where firms can ask questions, but only if they email him, and only him. Once all the questions are gathered up, he sends out an email to all the firms with the answers. The firms are given 2 more weeks to finish their proposals. No other contact with the company is allowed.
See the problem here? Communication is very limited and therefore the companies have to make assumptions, resulting in proposals that are not nearly as specific as they could be. This dilemma leads to some bad math:
Assumptions = Uncertainty
Uncertainty = Additional padding in the quote
The end result is a proposal that is more expensive than it needs to be and is often missing some key pieces.
No, absolutely not. The process of creating an RFP is invaluable because it requires the company to take the time to really think about what they need from the proposed project. The problem comes when the planners believes they have it all figured out.
If you hire an effective development firm, it is important to trust their experience and knowledge. A big part of that expertise is design. A great firm will have built something similar to the desired system (in terms of complexity), and therefore will be able to ask about variables you haven’t considered. These questions will usually result in a better and often cheaper finished product.
For instance … a lot of companies come to us with an RFP for an iPhone app. What the company doesn’t know is that it is often possible to create a web app that does the same thing across all mobile platforms. Furthermore, a cross-platform web app is often cheaper than one that only works on iOS. Sounds good, right? Well, if the company follows a strict RFP process like the one described above, then the bidding firms may not be able to present this possibility … no bueno.
The key to making a great RFP is to first create a solid document, and then develop an accompanying process that encourages the best ideas to come forth.
Step One: Decide if you actually need an RFP at all.
It may sound dumb, but if your app is relatively simple and straightforward you may be able to explain it over a phone call without an RFP at all. With that said … if you feel you might miss something, then it doesn’t hurt to write it down first.
Step Two: Choose the right writer.
Quick question … who would provide the more detailed story about a baseball game: an excited fan, the umpire, or someone who heard an account the next day?
The umpire, right? He is neck-deep in the game and really sees the ins and outs of what actually happened. Sadly, when it comes to an RFP, the writer is often more like the one who heard about the game secondhand.
In an ideal world, the person who writes an RFP is the one who will be the primary user or the one who will be most impacted by its implementation. Like the umpire in our little analogy, this person knows what the current system does and what the pretty new system should do. Often the ideal writer isn’t used, either due to a lack of inclination or time, in which case someone far removed from the project (such as an intern or secretary) is given the task. The end result is that the RFP doesn’t contain a crucial piece of the puzzle.
True story: not long ago a potential client sent us an RFP. It was over 15 pages and obviously took a lot of time and effort. We started to develop a proposal through careful research and conversations with the author (an intern). A few hours later we learned that the desired system was impossible because the programs currently in place were so old, they could not integrate with anything new. Hours on both sides were wasted because the person in charge of the RFP did not have the experience needed to do his due diligence.
Bottom line … if the ideal candidate can’t write the RFP, then at the very least, that person should be made available to the writer as often as possible.
Step Three: Describe what the current system does.
Unless you are a brand new company, whatever you want the system to do tomorrow is being done today in some fashion. Maybe you are using a spreadsheet, or an outdated piece of 3rd-party software, or maybe just a ton of sticky notes. However you do it, describing that process on a day-to-day basis will give a lot of insight as to what a new system should do and even how it should work.
Step Four: Dream about the new system.
Here is the fun part. Now that you have the old system laid out, how would you like to improve it? The key here is not to get lost in the details. Describing how a form should look and function isn’t the goal here. Instead, describe the outcomes you would like to achieve. A good developer will be able to fill in the blanks.
Step Five: Finishing touches.
At this point all the meat and potatoes are on the plate. All you need now are the finishing touches. Put in an estimated timeline. Also, if you can, draw up an approximate budget. A lot of companies are hesitant to do this part, but it starts the inevitable conversation about money with some actual figures to work with.
Step Six: Set it free and follow-up.
Now that the document is done, give it out to a few firms that you trust. Allow a week or so for them to look at it, and set up follow-up calls so that you can discuss the project in detail. This discussion is the key point in the whole exercise. Both parties have the document, they are educated about its contents, and they have taken the time to think through its implementation.
Great firms will start asking questions, drilling down into the design and outcomes that you want. Most clients know which firm they want to work with after this discussion. At this point it all comes down to budget. If you have put your budget into the RFP, then the conversations on this sticky subject can move a lot smoother.
So there you have it, easy steps on how to create an effective RFP.
If you are working on an RFP for a web or software project, look no further than Cii.
We work on application development projects across the globe. Contact us to get started; we can send you a proposal for a development project of almost any size.
Did you like this article or find it helpful? Help others by sharing it with them!