RFP is the first step towards your contact initiation and strategic partnership. Indivisual freelancers generally do not understand the the RFP, RFI and proposal lifecycles. It is a very assessment tool that you can leverage to find the right partner (or vendor or outsourcing company) for your fulfillment.

If you working with designers and individual developers it usually easier to start with Quotes/Bid than RFP. RFPs can be elaborate.

A great example of an what an RFP can include is at
http://www.entrepreneur.com/formnet/form/1173

Now, this is rough framework. You can tailor it as needed. When you go with RFP, you will receive proposals or RFI. There are tools and techniques to address that too.

Let's say you get 10 proposals. Each company with different rates, company size, geography, delivery schedules, milestones, development shop infrastructures etc... it is a daunting task to pick the right one and negotiate a contract.

Hey, if you feel like talking to me on this. Let me know..

Some of things a details RFP should have
Checkout this slideshare.
http://www.slideshare.net/profwaynesmith/how-to-write-an-rfp-16123708

There are tons of templates available for fee or free. If you need help identifying how to tailor it, let me know..

I've worked on writing, reviewing and submitting hundreds of Technical RFPs over the past 8 years and know it can be an exciting (but daunting) task. I've sat in every conceivable role (client, vendor, consultant, project manager etc) and seen great documents lead to excellent result for everyone involved, and of course poorly written documents that let one or all parties down ultimately. That being said, there are a few other points I would consider making sure you include:

- a clear and concise outline of how questions should be submitted and will be responded to.
- any quantifiable metrics which will help self-eliminate unqualified candidates from taking up time/resources in the review process (i.e. a firm target budget/timeline.)
- include (to whatever extent possible) and in-person interview porition to be completed prior to making a final selection
- make sure to include a request for them to articulate how ongoing support will (or won't) be offered. Ask for EXAMPLES of what ongoing support looks like for their organization in terms of maintaining and updating the application.
- ask how prioritization of resources (devs, designers etc) will occur both during and after the project.
- ask for an organization chart so you can understand the hierarchy of the company and an org chart for the implementation team supporting your rollout.
- request a copy of their primary service agreement
- request examples of comparable projects and clients as well as to share references which you can connect with.
- for mobile work, make sure to highlight whether or not you are requiring native mobile development, or open to considering non-native (wrap app/phone gap etc) solutions as well.
- ask about their testing processes and which platforms they use to deliver incremental version updates during and after the final build process so you and key stakeholders can be aware of progress.

Again, the RFP crafting process is (and should be) an investment of time on your part. The journey you are about to embark on will only get less organized and potentially convoluted as time goes on - so staying very organized and detail-focused now will give you the best chance to attract, vet and then select the qualified partner you need to make your project painlessly come to life.

I would be happy to set up some time to chat more and answer any other questions/provide any commentary that may help as you start or wrap up this process (and even beyond if needed in the selection process.)

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.

I recently completed an RFP process for a mobile app related to the insurance industry. I know, not a super existing industry, although our market is cycling, so that's the exciting part and we're looking to shake things up a bit :)

We had a number of different types of companies respond including -

-large US-based development companies

-freelancers from Elance/Upwork and

-a couple of overseas, smaller development houses

So you'll see that we kind of covered the entire spectrum here.

I've participated in a good number of RFP processes, from both sides of the table, and tried to put what I learned into practice with this RFP process.

Here are a few key points that I found helpful in this specific RFP and that I find to be helpful generally when soliciting RFP responses -

1 - Show examples, if possible.

In our case, there were a couple of well-reviewed insurance apps out there, that we felt we could use to model our more niche-specific app. We provided these examples in the RFP. If full-blown app examples aren't available, give examples of designs you like, specific functions or other components that may be available.

2 - Communicate goals, not methods.

Communicate what you'd like to accomplish. Let the person/company responding tell you how they'll get you there. This gives you great insight into how the person/company responding thinks and solves problems.

3 - Ask for previous work samples

This probably doesn't require much of an explanation. If the person/company responding has done relatable work, they'll be able to show you. If they haven't, they won't.

If the person/company responding "has worked on" a project or product, ask them what their specific role was and request examples of the specific work they contributed to the project.

4 - Don't ask for questions that are easy to answer "Yes" to ;)

These are questions like -

"Can you do X..."

"Do you have Y capability?"

"Can you meet Z deadline?

Anyone who is going to respond to your RFP will answer "Yes" to all of these questions. As a result, they don't help you differentiate among your options.

Again, for these types of questions, asking "how" rather than "if", should give you more insightful feedback into whether or not the person/company responding will deliver what you need and deliver it well.

Best of luck and always happy to discuss further on a call!