As a developer of websites and mobile applications, there is no single format that I have found that works perfect, however, I do prefer receiving as much detail as possible in RFPs or scope of work documents. Often, we encounter documents written by people that make assumptions and those assumptions can have massive time/cost impact for those estimating.

A few example from a recent RFP that we declined to respond to:

5. The application should have common social sharing features in all locations.
14. Must include a photo upload with dozens of Instagram like filtering options.
21. All users should have a profile and members should have a detailed profile.
33. The application should allow users to create an account or sign-in using social media.

These are a few points out of a long bulleted list of items. To me, this list says that the person writing the RFP doesn’t really know what they’re doing or what they want. They haven’t taken time to truly plan out the application and they are fishing and wasting people’s time. As a developer I expect to lead the charge in making recommendations on functionality to customers during the project, however, I need enough information to understand what is really desired before I can see if it is a good fit. Each of the items listed is incredibly ambiguous. As a developer trying to guess what “common” social sharing features are, or what a “detailed” profile looks like, it is extremely difficult. If I had to put a cost estimate to something like this I am going to need to imagine what the worst case scenario might be and then double it to cover my bases when “dozens” turns into “hundreds” and “common” turns into “impossible”. If I don’t, I will end up subsidizing the client’s application or having to cut out large portion of the desired functionality to meet the budget. In this instance, the RFP was so poorly written we didn’t even bother providing an estimate even though the client indicated we were the favorite to get the project.

Imagine if we rewrote one of the examples from above to include more detail. It could look something like this:

The application should include social sharing functionality:
We would like to include the ability to share each event on Facebook, Twitter, and Pinterest. When sharing we would like the share dialog to automatically include the event photo, date/time, and event title.

In the grand scheme of things adding this detail doesn’t take that much more work but it gives a lot better idea of what to expect. Each social network integration takes a certain amount of work, so we have provided a complete list of the ones we want to target. Each social network has constraints and rules for sharing so we have provided the information that we want to share to allow the developer to understand what is entailed. Most importantly, we have indicated what “all locations” means, by listing that we are sharing each event. With this simple bit of additional detail, a developer can now make a much more accurate assumption of how long this task will take.

Many times, I have had people tell me they are vague in the RFP to keep the cost down. THIS DOESN’T WORK. Don’t try to scam your future partner by being ambiguous or purposefully leaving out functionality. In the end, you are going attract an unskilled provider or an enormous amount of change orders, either-way it is likely to be a frustrating engagement for both parties. Your project will go much smoother and turn out much better if you provide the detail necessary to accurately estimate the true project cost up-front.